W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2011

[whatwg] Entering fullscreen when already in fullscreen mode [was: Fullscreen]

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 18 Oct 2011 08:17:05 +0900
Message-ID: <op.v3iqyraj64w2qv@annevk-macbookpro.local>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:37 UTC