You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The spec currently supports fullscreen companion windows (Explainer) through the use of element.requestFullscreen() and window.open() supported by a transient user activation allowance.
As currently defined in the spec, the transient activation allowance is activated for the frame containing the element that is going fullscreen. Therefore, it's not possible for another frame (ie a child iframe) to call element.requestFullscreen() on an element in a parent iframe, and then call window.open().
<iframeid="parentFrame"><divid="fullscreenElement"></div><iframeid="childFrame"><script>// Assume some user activation occurred (ie. button click).awaitwindow.parent.fullscreenElement.requestFullscreen(...);// Window may be blocked since the user activation has been consumed in "childFrame".// The additional transient activation was applied to the parent frame.// Changing this to parent.window.open(...) works around the problem.window.open(...);</script></iframe></iframe>
In the above example:
Some user activation occurs
element.requestFullscreen(..) is called in childFrame for an element in parentFrame.
As per the spec, an additional user activation signal is maintained in parentFrame to allow window.open()
childFrame calls window.open()
Browser may block the popup, since additional user activation signal was not granted to childFrame
Calling parent.window.open(..) would work as expected since parentFrame was granted the additional user activation.
While the spec technically defines which frame is granted an extra user activation for the purposes of a popup, it would be beneficial to call this behavior out in a summary, more "plain english" type note. I may create a PR for this enhancement pending any feedback here.
There has been at least one request from a developer to enhance this behavior to remove the need to call window.open() in the same frame as the fullscreened element. However, given how easy it is to workaround, and the overall complexity/engineering cost to change, I think it would be beneficial to strengthen the need for this change based on other feedback or use cases. I'm using this bug as a general discussion forum for this possible enhancement to the spec.
For reference, the relevant part of the spec describing this behavior is pasted below:
Take options["screen"] into account when moving and resizing pendingDoc’s top-level browsing context’s active document’s viewport. The viewport may be moved to the specified screen as part of this modified method step.
Background
The spec currently supports fullscreen companion windows (Explainer) through the use of
element.requestFullscreen()
andwindow.open()
supported by a transient user activation allowance.As currently defined in the spec, the transient activation allowance is activated for the frame containing the element that is going fullscreen. Therefore, it's not possible for another frame (ie a child
iframe
) to callelement.requestFullscreen()
on an element in a parent iframe, and then callwindow.open()
.In the above example:
childFrame
for an element inparentFrame
.parentFrame
to allowwindow.open()
childFrame
callswindow.open()
childFrame
parent.window.open(..)
would work as expected sinceparentFrame
was granted the additional user activation.A more thorough example of this is on https://glow-versed-jaborosa.glitch.me
Inquiry
For reference, the relevant part of the spec describing this behavior is pasted below:
3.5.1. Element.requestFullscreen() method definition changes
The Element.requestFullscreen() method steps are updated to optionally:
Take options["screen"] into account when moving and resizing pendingDoc’s top-level browsing context’s active document’s viewport. The viewport may be moved to the specified screen as part of this modified method step.
Set the this.[[targetScreenFullscreen]] internal slot to the current high resolution time if options["screen"] specifies a recognized ScreenDetailed object with a value of true for isExtended.
3.2.3. Window.open() method definition changes
The Window.open() method steps, and the steps of methods invoked therein, are updated to optionally:
Waive the transient activation state requirement when the current high resolution time of the relevant global object is greater than or equal to this.[[targetScreenFullscreen]], and less than this.[[targetScreenFullscreen]] plus the transient activation duration.
Set this.[[targetScreenFullscreen]] to negative infinity immediately after following the steps to consume user activation.
The text was updated successfully, but these errors were encountered: