This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26676 - Non-fullscreen documents can end up with non-empty fullscreen element stacks
Summary: Non-fullscreen documents can end up with non-empty fullscreen element stacks
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Fullscreen (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on: 27865
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-26 21:49 UTC by Philip Jägenstedt
Modified: 2015-07-21 13:37 UTC (History)
2 users (show)

See Also:


Attachments

Description Philip Jägenstedt 2014-08-26 21:49:24 UTC
Splitting this from https://www.w3.org/Bugs/Public/show_bug.cgi?id=26673#c0 as I don't think the root problem is tied to topDoc.

The problem is that it's possible to end up with a document with a non-empty fullscreen element stack that is no longer displayed in fullscreen. The easiest way to do it currently is to remove or move an iframe which has fullscreen elements in it. exitFullscreen() will be invoked on the document that contained the iframe element, but the iframe's document won't be in descendantDocs later.

One fix would be to check if oldNode is an iframe, and if so also invoke exitDocument() on iframe.contentDocument.

Another fix would be to change how descendantDocs is populated to instead follow iframe elements in the fullscreen element stack, regardless of how where those iframes are now.

Either fix can still leave you with an untruthful document.fullscreen while waiting for the next animation frame. I'm not sure that's a problem or not.

Since node removal is the only way to (temporarily) end up with an inconsistent fullscreen element stack, it's also worth considering instead modifying the fullscreen element stack synchronously (and recursively) upon node removal. But that may have other consequences.
Comment 1 Anne 2014-09-06 15:31:03 UTC
I don't really have a good answer here. Other than that the whole nesting thing made this so much more complicated :-(
Comment 2 Philip Jägenstedt 2015-02-20 10:00:49 UTC
Is there any chance that issue 27865 would make this and similar problems go away?

If not, "follow iframe elements in the fullscreen element stack, regardless of how where those iframes are now" seems fairly simple to spec at least.
Comment 3 Anne 2015-07-15 10:49:33 UTC
Is this still a problem?
Comment 4 Philip Jägenstedt 2015-07-15 13:04:09 UTC
I think the problem still remains, here:

"Let descendantDocs be an ordered set consisting of doc's descendant browsing contexts' documents whose fullscreen element is non-null, if any, in reverse tree order."

The definition of "descendant browsing contexts" is defined in terms of HTML's "parent browsing context":
https://html.spec.whatwg.org/multipage/browsers.html#parent-browsing-context

AFAICT, that's defined in terms of an <iframe> actually being in a document, so it ought to be the case still that just removing an iframe with fullscreen elements inside will leave those elements believing that they are in fullscreen, and if it's later re-inserted somewhere the results will be strange.

Perhaps this can be solved inside "Whenever the removing steps run with an oldNode, run these steps." If that exits fullscreen on any element that's removed while it's in the top layer stack, even if not at the top, it ought to be fine.
Comment 5 Anne 2015-07-18 06:22:14 UTC
Wait, if an <iframe> is removed, it's browsing context is discarded, which in turn discards its document. HTML should probably exit fullscreen for discarded documents.
Comment 6 Philip Jägenstedt 2015-07-18 07:19:39 UTC
OK, that's https://html.spec.whatwg.org/#discard-a-document

It looks like the Fullscreen spec can define more "unloading document cleanup steps" to make this work:
https://html.spec.whatwg.org/#unloading-document-cleanup-steps
Comment 8 Philip Jägenstedt 2015-07-21 13:37:45 UTC
Looks good, just clears all state without bothering to fire any events.