Internal iframe fullscreen event missing?

[luwes]

Sorry if this issue is out of place but it seemed a very core issue and I couldn't find anything useful on this issue anywhere else.

I'm working on implementing fullscreen methods for the Vimeo player API, https://github.com/vimeo/player.js

The first obstacle was that playerElementInIframe.requestFullscreen() can't be called cross-site via postMessage from the website that embeds the player because it requires a short running task from a user gesture. postMessage took too long I guess.

This was solved by doing iframe.requestFullscreen(), so the website (parent) directly goes fullscreen via the iframe.

The question/concern that I had is why is there no fullscreenchange event fired on the iframe's document? The website (parent) does receive this event but I imagined the iframe would also get some information as it's made fullscreen.

Here is an example, https://jsfiddle.net/wgb1k0ma/

Pressing the fullscreen button makes the iframe go fullscreen but internally the player is not aware of its fullscreen state which is seen by the bottom right corner icon button which also doesn't work anymore.

Is this intended behavior?

Thank you for reading.
Related issue vimeo/player.js#592

[annevk]

It seems there would be a cross-origin leak otherwise, but I guess in this specific instance the iframe is also resized, so it might be okay. Can't you use the resize event?

[luwes]

thanks for the quick reply @annevk. you're probably right, I'll have try with the resize event.
comparing iframe size to the screen dimensions could work.

or maybe it's more explicit to also message the fullscreenchange event from parent to child.

and then the last piece would be to iframe.exitFullscreen() from a user action in the iframe (child), this would be cross-origin via postMessage from child -> parent. hopefully exiting is possible 🤔

[annevk]

I see, I suspect some this will be better once we switch Fullscreen to the new user activation framework, especially if you have some control over both origins. See #152 for some issues with that though.

[upsuper]

The first obstacle was that playerElementInIframe.requestFullscreen() can't be called cross-site via postMessage from the website that embeds the player because it requires a short running task from a user gesture. postMessage took too long I guess.

I believe it's simply because user gesture is not tracked through postMessage at all, and thus a handler of message event is not considered initiated from a user gesture even if the corresponding message was posted by one. The same was an issue for many other cases including resolving Promise, setTimeout, etc. I'm not sure whether it's possible to allow that, and what other restrictions we would need to avoid abusing it.

The question/concern that I had is why is there no fullscreenchange event fired on the iframe's document? The website (parent) does receive this event but I imagined the iframe would also get some information as it's made fullscreen.

The event is dispatched for the document which is entering the fullscreen state, which means not only resizing it to take the size of the whole screen, but also making requesting elements match :fullscreen pseudo-class and have document.fullscreenElement return fullscreen element, etc.

I don't think we would ever want to dispatch fullscreenchange to inner document when the fullscreen is requested by its parent.

But this seems to be a reasonable request, and probably being able to recognize user gesture / user activation across <iframe> boundary would be the right direction moving forward.

[foolip]

@upsuper is correct that there was never the intention of dispatching fullscreenchange on documents inside iframes in this scenario. This may be an oversight and something worth fixing, but at least not an accidental bug in the spec.

@luwes I've had a look at https://jsfiddle.net/wgb1k0ma/ but can you give some more detail on the UX you're trying to achieve? Is it that you want a button that's visually outside the iframe that would go fullscreen? Normally the fullscreen button is over the video itself.

If you have coordination between the two origins involved via postMessage, then you'll be able to make this work, but it does sound cumbersome. For exiting, I think you'll find that documentInIframe.exitFullscreen() won't work if nothing in that document is fullscreen, but asking the parent to exit fullscreen on its behalf should work.

cc @mustaqahmed as user activation is involved here. However, I think the platform changes to make user activation more rational will make this sort of thing harder if anything.

[luwes]

thanks for the replies. yes, it's primarily for a button outside the iframe that would make the player go fullscreen and exit fullscreen but there is a more edgy case where both flows would be used mixed.

For example a user goes fullscreen via an external button, the player goes fullscreen but then uses the internal Vimeo player UI to exit fullscreen which is a button in the iframe. Maybe another case the user goes fullscreen via the Vimeo player's internal fullscreen button but the developer wants that the player exits fullscreen on a specific time which would require an API call from outside the iframe into the player.

I think it works though with postMessaging the fullscreen state. yes, the exiting by sending a postmessage from child to parent seemed to work.
https://github.com/vimeo/player.js/blob/master/src/player.js#L132-L147

see it in action here: https://player.vimeo.com/api/demo

[mustaqahmed]

A few notes about user activation propagation/visibility, fyi @upsuper:

I believe it's simply because user gesture is not tracked through postMessage at all, and thus a handler of message event is not considered initiated from a user gesture even if the corresponding message was posted by one. The same was an issue for many other cases including resolving Promise, setTimeout, etc. I'm not sure whether it's possible to allow that, and what other restrictions we would need to avoid abusing it.

The new user activation model in the HTML spec eliminated this kind of tracking, through Window-wide states. So Promise, setTimeout, postMessage etc works without any tracking. Chrome shipped this early last year.

... probably being able to recognize user gesture / user activation across <iframe> boundary would be the right direction moving forward.

The new model precisely defines user activation visibility across frame boundaries: visible in parent from any child and not the the other way around. This visibility was chosen deliberately to prevent abusive calls from cross-origin frames. For example, it would be terrible if an ad frame can suddenly go fullscreen when the user interacted only with the main frame.

[upsuper]

Ha... I proposed something similar for Firefox in the past, but wasn't accepted...

But yeah, if it becomes a time-based model, it's probably dangerous to allow it go across the frame boundary automatically, but is it possible to have postMessage carry the activation when going across the boundary? I suppose it wouldn't be as bad in that case.