This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
For requestFullscreen() and exitFullscreen(), the current spec requires UAs to execute the async steps "as part of the next animation frame task". I propose that UAs should be allowed to decide when to run those steps, instead of being forced to run them in the next animation frame. This change would allow UA to have some transition before putting the page into fullscreen state (e.g. fade the screen to black) In addition, UAs may need to do some extra work to put its window into fullscreen (which could be async because of API of OS), hence at exactly the next frame, it is possible that the window hasn't been in fullscreen yet, which means a page may need to rely on the following resize event to correct some dimensions it uses instead of only the fullscreenchange event. It seems that, what is "the next animation frame task" has no definition yet. With this change, we will not need to define that anymore.
I think in terms of timing the events should still synchronize with an animation frame and not happen at some random point. Otherwise we'd make it harder for developers to hit 60FPS.
This change, though, could raise a problem that, what should UAs do if requestFullscreen()/exitFullscreen() is called before they put the page into the fullscreen state (and trigger the event). A possible solution could be canceling any pending request, and execute only the new one.
(In reply to Anne from comment #1) > I think in terms of timing the events should still synchronize with an > animation frame and not happen at some random point. Otherwise we'd make it > harder for developers to hit 60FPS. But not the *next* animation frame. Actually, why do we need to care the frame loss on fullscreen change? It shouldn't happen frequently.
(In reply to Xidorn Quan from comment #3) > But not the *next* animation frame. Sure. We can change "next" to "earliest convenient" or some such. (I wish I had some better words here.) > Actually, why do we need to care the frame loss on fullscreen change? It > shouldn't happen frequently. The timing of fullscreen events relative to other "animation frame" events is still important.
(In reply to Anne from comment #4) > (In reply to Xidorn Quan from comment #3) > > But not the *next* animation frame. > > Sure. We can change "next" to "earliest convenient" or some such. (I wish I > had some better words here.) > "the first animation frame after the browser UI has fully entered fullscreen mode"? (it is a different issue that we start to have so much stuff happening around animation frame that calling all the callbacks may end up postponing painting.)
Everying after step 4 in https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen is async and can take any amount of time, so the only way I can read the spec is that the event dispatch etc. should run on the first animation frame after the resize is complete, no matter how long it takes to resize. If some transition is used, which would really be nice, it would have to be invisible to Web content, i.e. scripts can't be allowed to observe anything in between the last animation frame in windowed mode and the first animation frame in fullscreen. If we want the page itself to participate in the transition the precise model for that needs to be defined, which, again, would be nice.
Yeah, Philip is correct. Resize can already take any amount of time.