This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
https://fullscreen.spec.whatwg.org/#model What happens when: * you remove an ancestor of an element that's fullscreen? * you remove the iframe browsing context container of the browsing context of an element that's fullscreen? * you navigate an ancestor browsing context of the browsing context of an element's that fullscreen? Should I be speccing some of these?
* the document that the fullscreen element is in has its document.open() method invoked, causing the Document to be recycled but the element to go away? * window.close() is called?
> you remove an ancestor of an element that's fullscreen? https://github.com/whatwg/fullscreen/commit/b9f36a4db4f298004463062f19f903a3117629bb > you remove the iframe browsing context container of the browsing context of an element that's fullscreen? That's also covered by the above. An iframe would itself be on a stack. > you navigate an ancestor browsing context of the browsing context of an element's that fullscreen? This one is up to HTML to define I think. > the document that the fullscreen element is in has its document.open() method invoked, causing the Document to be recycled but the element to go away? I hate document.open() and have no good suggestions at the moment. I suspect we'd want this to exit fullscreen. > window.close() is called? Seems the same as if you hit (x) in the browser, probably exits fullscreen?
Any idea how I should phrase this in the HTML spec?
Just invoke the fully exit fullscreen algorithm from those places? Perhaps Philip can help out. He's been fixing Fullscreen bugs since forever.
Won't calling "fully exit" cause it to exit even if the condition isn't exactly met? I mean, for example, if document.open() is called on the Doc of an iframe descendant of the element that's full screen, you wouldn't want to leave full-screen, surely.
Yeah, I guess you could first check if document's fullscreen element stack is non-empty.
Would it be possible for you to provide a hook that does this? Something where I hand you a Document that I know is going away, and you take care of determining if that is a problem and exiting full-screen if it is? Note that this would be called from such deep and ugly algorithms as "discard a browsing context" and the "unload" steps, so you don't want to be firing events or queueing tasks or anything if you can help it.
Can we do it the other way around? Document lifetime hooks seem like a good idea to have in general. I might need them for a revamp to notifications as well.
Sure. There are "unloading document cleanup steps" and "unloading document visibility change steps" already; I'm happy to also add a hook to the history traversal and document discard algorithms, if that would help.
(Reassign to me if you want me to add something.)
Thanks. I'll wait for Philip to get back to work on this so we can figure out the appropriate model and then assign as appropriate.
Consider me back at work, at least as far as reading and replying to fullscreen bug mail is concerned. These three seem to be unresolved: > * you navigate an ancestor browsing context of the browsing context of an > element's that fullscreen? That ancestor must then have an iframe which is the fullscreen element, so there shouldn't be anything special about this. Is the standard case of navigating a document with a fullscreen element handled well, spec-wise? > * the document that the fullscreen element is in has its document.open() > method invoked, causing the Document to be recycled but the element to go > away? Does this not indirectly invoke the "Whenever the removing steps run with an oldNode, run these steps" bit in the Fullscreen spec? > * window.close() is called? Uh... "fully exit fullscreen" seems appropriate.
https://github.com/whatwg/html/pull/230