Clarification and possible enhancement to frames which are allowed to open a popup after element.requestFullscreen().

[bradtriebwasser]

Background

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().

<iframe id="parentFrame">
<div id="fullscreenElement"></div>
<iframe id="childFrame">
 <script>
   // Assume some user activation occurred (ie. button click).
   await window.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:

1. Some user activation occurs
2. element.requestFullscreen(..) is called in childFrame for an element in parentFrame.
3. As per the spec, an additional user activation signal is maintained in parentFrame to allow window.open()
4. childFrame calls window.open()
5. Browser may block the popup, since additional user activation signal was not granted to childFrame
6. Calling parent.window.open(..) would work as expected since parentFrame was granted the additional user activation.

A more thorough example of this is on https://glow-versed-jaborosa.glitch.me

---

Inquiry

1. 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.
2. 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:

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.