Re: [whatwg/fullscreen] Remove from top layer synchronously for not connected elements (#128)

> For example, if the removed fullscreen element is an `<iframe>` element, its content would keep being in fullscreen state (it's not clear whether other approach can solve this natively but it might be something we can keep in mind?).

Removing an iframe triggers https://html.spec.whatwg.org/multipage/window-object.html#a-browsing-context-is-discarded. If you have a handle to the document within you can still look at `iframeDoc.fullscreenElement` and see that it doesn't change. A test for this in the style of https://github.com/w3c/web-platform-tests/pull/6302 should be possible. This is actually a funny thing that I don't think any solution to the "fullscreen element is removed" problem can get around. I think it already behaves as I described in Chromium.

> Also, if the document is a sub-document, and the `<iframe>` of its browsing context doesn't have iframe fullscreen flag set, the `<iframe>` should also exit fullscreen when the document gets unfullscreened.

Yes. I think removing the "Unfullscreen doc" step and just continuing to run is the fix for this. Because `document.fullscreenElement` already changed, this can lead to exiting a step further than would have happened when calling `document.exitFullscreen()` (and *not* removing the fullscreen element) but this is similar to calling `document.exitFullscreen()` twice. The only way to avoid this is one of:
1. Keeping track in the async part of "exit fullscreen" that the fullscreen element was removed and acting *as if* it were still in top layer at certain steps, to avoid exiting too much.
2. Setting *resize* to true so that removing the fullscreen element always consistently exits fully.

I'd be OK with either just leaving it a bit odd or setting *resize* to true. Keeping track of more state doesn't sound great.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fullscreen/pull/128#issuecomment-391389555

Received on Wednesday, 23 May 2018 15:27:01 UTC