[whatwg] Fullscreen and event dispatch

[João Eiras]

Hi.

The requestFullscreen steps tells to dispatch a fullscreenchange event on  
the context object, and all containing objects (frames).


First, there should be a better clarification of 'context object'. While  
is remarked that it is the object used for the last requestFullScreen call  
which was allowed, it should also refer that for ancestor browsing  
contexts, it should be the containing frame. This way, fullscreening a  
contained document will work just as fine as any other kind of element  
reusing the same css, while for the containing document, it's transparent.


Second, the requestFullscreen steps do not cope well if there is already a  
previous fullscreen element, either in the same document, or in a  
descendant, ancestor or sibling document. The steps tell to loop all the  
way up to the top level document and dispatch fullscreenchange events.


I would suggest dispatching it *only* for elements and documents where  
there was a fullscreen change, so if we have a top level document A and a  
child B, B has two elements, a' and b'. Changing fullscreen from a' to b'  
would result in two fullscreenchange events, one for each element, inside  
B, while A should not get a event. I have some doubts if the spec allows  
this use case though, because the steps for requestFullscreen also mention  
that if an ancestor browsing context has a non-null fullscreen element,  
then it should not be allowed to proceed, but this restriction does not  
apply, again, to sibling elements, or sibling/descendant documents.


Third, perhaps fullscreenchange should be split into fullscreenon and  
fullscreenoff events ?

Re: [whatwg] Fullscreen and event dispatch

[Anne van Kesteren]

On Mon, 24 Oct 2011 20:42:18 +0900, João Eiras jo...@opera.com wrote:
The requestFullscreen steps tells to dispatch a fullscreenchange event  
on the context object, and all containing objects (frames).


Actually, it says on the context object and all ancestor browsing  
context's documents. We could change it to always dispatch on the  
fullscreen element, I guess that might be better.



First, there should be a better clarification of 'context object'. While  
is remarked that it is the object used for the last requestFullScreen  
call which was allowed, it should also refer that for ancestor browsing  
contexts, it should be the containing frame. This way, fullscreening a  
contained document will work just as fine as any other kind of element  
reusing the same css, while for the containing document, it's  
transparent.


No, context object is the object on which the method is called. The others  
objects are defined separately.



Second, the requestFullscreen steps do not cope well if there is already  
a previous fullscreen element, either in the same document, or in a  
descendant, ancestor or sibling document. The steps tell to loop all the  
way up to the top level document and dispatch fullscreenchange events.


Actually, if there a fullscreen element already you will get a  
fullscreenerror event.



I would suggest dispatching it *only* for elements and documents where  
there was a fullscreen change, so if we have a top level document A and  
a child B, B has two elements, a' and b'. Changing fullscreen from a' to  
b' would result in two fullscreenchange events, one for each element,  
inside B, while A should not get a event. I have some doubts if the spec  
allows this use case though, because the steps for requestFullscreen  
also mention that if an ancestor browsing context has a non-null  
fullscreen element, then it should not be allowed to proceed, but this  
restriction does not apply, again, to sibling elements, or  
sibling/descendant documents.


Why would it not? The top-level browsing context will always have a  
non-null fullscreen element if something is fullscreen.



Third, perhaps fullscreenchange should be split into fullscreenon and  
fullscreenoff events?


What are the use cases to distinguish them?


--
Anne van Kesteren
http://annevankesteren.nl/