- From: Chris Pearce <cpearce@mozilla.com>
- Date: Thu, 17 May 2012 18:06:22 +1200
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
On 17/05/2012 3:37 a.m., Anne van Kesteren wrote: > On Wed, May 16, 2012 at 2:33 AM, Chris Pearce<cpearce@mozilla.com> wrote: >> I think that the "fullscreenchange" even dispatch should be specified to be >> dispatched once the animation to transition to/from fullscreen has finished. > So queuing the task was not enough? I guess that makes sense. > > As for how to best define this in the specification. Should I just > create a list of objects the event is to be dispatched upon and then > after the animation steps start queuing tasks to dispatch them on the > objects in that list? > Actually after thinking a bit more on this I've changed my mind and I don't think it's ok to leave the fullscreenElement stack and :fullscreen state changes synchronous while delaying the dispatch of "fullscreenchange" events. If fullscreenElement stack and :fullscreen state changes could be observed before the fullscreen transition/animation is complete, script won't see consistent behaviour across platforms, i.e. on some (but not all) platforms there will be a period of time that document.fullscreenElement is true but document.fullscreenElement doesn't take up the entire screen. I think it would be best to simply make everything from Step 2 onwards of the requestFullscreen() algorithm spec asynchronous. So in the requestFullscreen specification, move Step 5 and Step 6 up to be inserted before Step 2. We should do the same with exitFullscreen(), i.e. move Step 6 and Step 7 of the exitFullscreen algorithm spec up to be inserted before Step 3. We should also specify that those state changes happen in synchronous sections, to keep the world sane. Thanks, Chris Pearce.
Received on Thursday, 17 May 2012 06:06:57 UTC