- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 18 Oct 2011 08:17:05 +0900
On Tue, 18 Oct 2011 07:55:33 +0900, Darin Fisher <darin at chromium.org> wrote: > Thanks for working on this spec! I have more questions, but I'll just > start with one. If enterFullscreen() is called when the browsing > context is > already being displayed fullscreen, what should happen? (It looks like > Safari 5.1 ignores the second call to webkitRequestFullScreen.) Chris is suggesting this should move the "current fullscreen element" around. A use case I can think of is where you have YouTube fullscreen while browsing through videos and then want to highlight a particular video. It does however generate quite a bit of complexity in edge cases where you have a tree of Documents. In that case you need to find the common ancestor of the current fullscreen element and the new fullscreen element, make changes to the Documents on that path from current to new, and dispatch events. > I also find it curious that there is a bit of a dead-time between the > request to enter fullscreen and the fullscreenchange event (nit: > "fullscreenchange" instead of "fullscreenchanged" to be consistent, > right?). Agreed that it should be ending in "change". > It appears that JS cannot request to cancel out of fullscreen mode until > the fullscreenchange event is generated (i.e., until the fullscreen flag > is set). It could cause pain for developers if there is no guaranteed > response to enterFullscreen(). Did my request succeed, did it fail? > What happened? The idea is to have an event, also asynchronous, that is dispatched when the invocation did not succeed. Naming ideas so far: "fullscreendeny" and "fullscreenerror". -- Anne van Kesteren http://annevankesteren.nl/
Received on Monday, 17 October 2011 16:17:05 UTC