26366 2014-07-17 08:57:09 +0000 It's possible to go fullscreen with an element not in the document 2014-07-31 20:12:17 +0000 1 1 1 Unclassified WebAppsWG Fullscreen unspecified PC Linux RESOLVED FIXED P2 normal --- 1 philipj annevk cpearce mike philipj public-webapps roc public-webapps-bugzilla oldest_to_newest 109043 0 philipj 2014-07-17 08:57:09 +0000 This is one example of a class of problems caused by the checks made synchronously in requestFullscreen() not necessarily holding when the rest of the function runs async. To go fullscreen with an element not in the document: element.requestFullscreen(); element.parentNode.removeChild(element); To end up with a fullscreen element stack with siblings are put on the stack: element.requestFullscreen(); element.nextSibling.requestFullscreen(); I'm not sure what bad things can result, but it seems silly to make checks that aren't actually guaranteed to hold. 109348 1 philipj 2014-07-28 09:22:10 +0000 I did some ad-hoc testing on calling requestFullscreen() and exitFullscreen() multiple times in the same script and found that there wasn't great interoperability even when one doesn't try to circumvent the checks. The basic problem is that the script-visible fullscreen element stack shouldn't be updated until one has actually entered/exited fullscreen, and there's no script-invisible state available to do these checks. I can see a few options: 1. Have a script-invisible stack of pending requests which is pushed to the script-visible stack before the fullscreenchange event is fired. 2. Have a single pending element which is replaced by successive calls to requestFullscreen(). 3. Make requestFullscreen() and exitFullscreen() do nothing if there's already a pending change. 109351 2 annevk 2014-07-28 09:47:17 +0000 3 seems to be how we generally do this. Introduce a document-wide "fullscreen flag" and clear it once either algorithm terminates? And just make the methods no-ops if the flag is set? 109352 3 annevk 2014-07-28 09:53:00 +0000 Although I guess we don't really want to block exitFullscreen(). Especially for things such as navigation. A document-wide pending element could work. exitFullscreen() would just clear the element and return. And the queued task from requestFullscreen would become a no-op. Does that make sense? 109354 4 roc 2014-07-28 09:57:24 +0000 I think so. 109356 5 philipj 2014-07-28 11:04:45 +0000 (In reply to Anne from comment #3) > Although I guess we don't really want to block exitFullscreen(). Especially > for things such as navigation. > > A document-wide pending element could work. exitFullscreen() would just > clear the element and return. And the queued task from requestFullscreen > would become a no-op. Does that make sense? This depends on what the internal state is. If the window resize has already been requested, simply clearing the pending element would lead to something strange when the resize is completed. One could immediately exit fullscreen in that case, but should that cause an additional fullscreenchange event to be fired? 109357 6 annevk 2014-07-28 13:08:17 +0000 requestFullscreen() - sets pending element - queues a task to run these steps 1) if pending element is unset, return 2) push pending element to stack 3) unset pending element 4) animate (async?) exitFullscreen() - queues a task to run these steps 1) if pending element is set, unset it and return 2) pop stack 3) animate (async?) Since they're separate tasks, there should be no problem, right? They can happen quite shortly after each other. Making that animate smoothly would be up to the implementation. 109363 7 philipj 2014-07-28 13:31:06 +0000 That doesn't seem quite right... we can't manipulate the fullscreen element stack from a task posted by requestFullscreen() or exitFullscreen() if it's to be synchronized with animation frames as per bug 26440. 109372 8 annevk 2014-07-28 15:06:29 +0000 More problems: the checks requestFullscreen() does are crossing origin boundaries and therefore need to be asynchronous somehow. As the event is already dispatched from a task, that may be feasible. 109374 9 philipj 2014-07-28 15:10:05 +0000 Maybe the checks can just be done async before the resize, that way they can take however long they want. What about race conditions, what happens when two frames request fullscreen at the same time and passes the checks, which would be violated if the timing were different? 109379 10 annevk 2014-07-28 15:26:08 +0000 Yes, we need to account for the resizing process to fail. 109567 11 annevk 2014-07-30 12:59:54 +0000 This should bring us a lot closer. Please review! https://github.com/whatwg/fullscreen/commit/5187282e5fd24a1c4ff0164d444e1bfc2bdf44ef 109701 12 annevk 2014-07-31 20:12:17 +0000 New bugs for new issues I guess. Thanks all!