26440 2014-07-28 09:06:04 +0000 Allow fullscreenchange events to be synchronized with animation frames 2015-07-28 07:32:52 +0000 1 1 1 Unclassified WebAppsWG Fullscreen unspecified PC Linux RESOLVED MOVED P2 normal --- 28001 26516 27674 28614 1 philipj annevk bbirtles cam cpearce eoconnor ian jackalmage jamesr jer.noble mike plh public-webapps roc zcorpan public-webapps-bugzilla oldest_to_newest 109341 0 philipj 2014-07-28 09:06:04 +0000 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. 109343 1 annevk 2014-07-28 09:13:17 +0000 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? 109344 2 philipj 2014-07-28 09:16:47 +0000 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? 109345 3 roc 2014-07-28 09:17:33 +0000 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. 109349 4 philipj 2014-07-28 09:28:01 +0000 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. 109353 5 annevk 2014-07-28 09:55:03 +0000 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? 109438 6 bbirtles 2014-07-28 23:22:10 +0000 (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. 109566 7 annevk 2014-07-30 12:59:34 +0000 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 109631 8 annevk 2014-07-31 08:32:22 +0000 http://lists.w3.org/Archives/Public/www-style/2014Jul/0586.html has a plan for animation frame tasks btw. 109713 9 philipj 2014-07-31 22:06:25 +0000 Looks good, let's hope someone bites. 109738 10 philipj 2014-08-01 07:12:16 +0000 exitFullscreen() still needs some work: http://krijnhoetmer.nl/irc-logs/whatwg/20140801#l-194 109740 11 philipj 2014-08-01 07:33:09 +0000 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? 109743 12 annevk 2014-08-01 10:03:05 +0000 https://github.com/whatwg/fullscreen/commit/d8b9e4474cbef536fee6daaa5885eed8e73fc5de 109748 13 philipj 2014-08-01 10:59:38 +0000 (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? 109749 14 philipj 2014-08-01 11:07:21 +0000 It looks like topDoc is used uninitialized, I guess "Remove the top element from topDoc's fullscreen element stack" was meant to be conditional. 109752 15 annevk 2014-08-01 12:18:58 +0000 https://github.com/whatwg/fullscreen/commit/0e4ac69d37903289d7633e393ab104325c6e5cfd https://github.com/whatwg/fullscreen/commit/4e930868afa0d1b67a569087155ddab85ec19b49 109811 16 philipj 2014-08-03 21:04:57 +0000 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. 109812 17 philipj 2014-08-03 21:13:15 +0000 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. 109813 18 annevk 2014-08-04 07:39:18 +0000 (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. 109816 19 philipj 2014-08-04 08:38:53 +0000 (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"... 114957 20 ian 2014-11-14 23:59:16 +0000 Do we want to support animating from non-full-screen to full-screen? 114965 21 annevk 2014-11-15 11:52:20 +0000 Yes. 116230 22 annevk 2014-12-12 17:58:33 +0000 Study http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Dec/0039.html while fixing this. 118048 23 philipj 2015-02-20 09:46:14 +0000 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? 118049 24 annevk 2015-02-20 09:57:14 +0000 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. 118051 25 philipj 2015-02-20 10:04:07 +0000 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. 122062 26 philipj 2015-07-15 12:56:01 +0000 This has been fixed, are there any remaining issues? 122065 27 annevk 2015-07-15 13:29:09 +0000 Well, the dependency listed is an integration issue with HTML. That needs to be sorted somehow. 122067 28 philipj 2015-07-15 13:45:57 +0000 Ah, sorry for the noise then :) 122305 29 annevk 2015-07-28 07:32:52 +0000 Let's close this in favor of https://github.com/whatwg/fullscreen/issues/16 Any new issues should be filed on GitHub.