This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://fullscreen.spec.whatwg.org/#go-fullscreen Tasks are queued to resize the viewport and fire the fullscreenchange event. I would like to synchronize changes to the fullscreen element stack and the events with animation frames, so that any scripts will always see a perfectly consistent state. I wrote about this and other messy things on blink-dev recently: https://groups.google.com/a/chromium.org/d/msg/blink-dev/GLl6aWs9-EM/6Z0IkWgmWJsJ Unfortunately, the way the spec is phrased doesn't seem to allow for this. I propose that instead of using the user interaction task source, any script visible changes and events are tied into the requestAnimationFrame() machinery.
That machinery seems to be defined here https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html#processingmodel and is not extensible at the moment. This does seem like a good idea. Basically we should replace the "queue a task" bits with something that queues this to happen relative to that "samples all animations" task. How does web animations deal with this timing model?
http://dev.w3.org/fxtf/web-animations/#event-dispatch says: "Events are queued whenever sampling regularly occurs" It looks a bit weird though, because it doesn't say that the events are ever fired. Maybe the spec authors have treat "queue" as "fire" or something?
The idea sounds good. I don't know if Web Animations interacts with this. Gecko's "scroll" events are synchronized with animation frames in a similar way.
Blink also has a few things which are synchronized with animation frames already: scroll events, resize events, media query change listeners, events related to CSS Animations and the non-standard overflowchange event. If the spec hooks to make this work don't already exist, then at least there is something to reverse engineer.
Simon, Tab, Cameron, it seems this is largely your task to sort this out and define it, perhaps together with Ian. Can you guys file the appropriate bugs and make them block this bug?
(In reply to Philip Jägenstedt from comment #2) > http://dev.w3.org/fxtf/web-animations/#event-dispatch says: > "Events are queued whenever sampling regularly occurs" > > It looks a bit weird though, because it doesn't say that the events are ever > fired. Maybe the spec authors have treat "queue" as "fire" or something? That section of the spec is being completely rewritten. Events will be dropped. I still don't think Web Animations will address this yet but hopefully in the next few days it will get closer.
Animation frame tasks still need to be defined. Including the order of events and other code running within that task (are those microtasks again?). Meanwhile, I have brought Fullscreen a bit closer to them with this commit I hope: https://github.com/whatwg/fullscreen/commit/5187282e5fd24a1c4ff0164d444e1bfc2bdf44ef
http://lists.w3.org/Archives/Public/www-style/2014Jul/0586.html has a plan for animation frame tasks btw.
Looks good, let's hope someone bites.
exitFullscreen() still needs some work: http://krijnhoetmer.nl/irc-logs/whatwg/20140801#l-194
How about this: 1. Let exitDocuments be the set of documents with exactly 1 element on its stack. 2. Return and continue async. 3. If the top-level document is in exitDocuments, resize. 4. In the animation frame task, empty the stacks of all exitDocuments and pop one element from the next one up, if any. If anything is out-of-sync now, fully exit fullscreen. Kinda works?
https://github.com/whatwg/fullscreen/commit/d8b9e4474cbef536fee6daaa5885eed8e73fc5de
(In reply to Anne from comment #12) > https://github.com/whatwg/fullscreen/commit/ > d8b9e4474cbef536fee6daaa5885eed8e73fc5de This reversed the event order in exitFullscreen(). The events should be fired in the opposite order compared to requestFullscreen(), so that the deepest document gets it first and the top-level document last. Maybe not necessary for site compat, but why risk it?
It looks like topDoc is used uninitialized, I guess "Remove the top element from topDoc's fullscreen element stack" was meant to be conditional.
https://github.com/whatwg/fullscreen/commit/0e4ac69d37903289d7633e393ab104325c6e5cfd https://github.com/whatwg/fullscreen/commit/4e930868afa0d1b67a569087155ddab85ec19b49
With those changes I'm happy with requestFullscreen() or exitFullscreen(), they look ready to implement. When implementing exitFullscreen(), this is how I'd actually do it. 3. Let topLevelDoc be doc's top-level browsing context's document. 4. Set resize to true if topLevelDoc has a fullscreen element stack consisting of one element, and false otherwise. Since I like to paste the spec steps into the code it would be *nice* if it matched, if there's no particular reason for the parentDocs overhead.
Now that all events are fired in the same task, what happens when one event handler rearranges the document tree? It looks like it's all in order, but maybe for extra clarity a descendantDocs set could be populated and iterated in two separate steps? It would be easy to overlook when implementing step 9.4, and could in the worst case lead to documents with a non-empty fullscreen element stack being left behind.
(In reply to Philip Jägenstedt from comment #16) > 3. Let topLevelDoc be doc's top-level browsing context's document. > > 4. Set resize to true if topLevelDoc has a fullscreen element stack > consisting of one element, and false otherwise. If you have A > B with A being topLevelDoc. If B's fullscreen element stack contains two elements, A's stack will not be popped.
(In reply to Anne from comment #18) > (In reply to Philip Jägenstedt from comment #16) > > 3. Let topLevelDoc be doc's top-level browsing context's document. > > > > 4. Set resize to true if topLevelDoc has a fullscreen element stack > > consisting of one element, and false otherwise. > > If you have A > B with A being topLevelDoc. If B's fullscreen element stack > contains two elements, A's stack will not be popped. Um, right :) I'll make a note to test that case so that no one tries my "optimization"...
Do we want to support animating from non-full-screen to full-screen?
Yes.
Study http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Dec/0039.html while fixing this.
For animating between non-fullscreen and fullscreen, are we talking about making it possible for scripts to control every animation frame in that transition, or something else?
Do UAs hand out multiple animation frames for those transitions now? I would expect not... I would expect one before and one after or something like that. Perhaps with a future compositor API more detailed control can be given though there's some potential security issues with that too.
No, there's ideally just one animation frame before and one animation frame after. Note that on both desktop and mobile Chrome, however, there may be status bars and things that get animated away and actually the Web content is resized for every step of this animation. However, I consider this a bug to be fixed as it's very sluggish and it doesn't actually allow one to control the animation into and out of fullscreen.
This has been fixed, are there any remaining issues?
Well, the dependency listed is an integration issue with HTML. That needs to be sorted somehow.
Ah, sorry for the noise then :)
Let's close this in favor of https://github.com/whatwg/fullscreen/issues/16 Any new issues should be filed on GitHub.