On Fri, Aug 6, 2010 at 1:37 PM, Simon Fraser <span dir="ltr"><<a href="mailto:smfr@me.com">smfr@me.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;"><div><div class="im"><div>On Aug 5, 2010, at 5:56 PM, Robert O'Callahan wrote:</div><br><blockquote type="cite">On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser <span dir="ltr"><<a href="mailto:smfr@me.com" target="_blank">smfr@me.com</a>></span> wrote:</blockquote>
</div></div><div><div class="im"><blockquote type="cite"><div class="gmail_quote"><div>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
>  * void cancelFullScreen()<br>
<br>
I think "exit" would be better than "cancel".<br></blockquote><div><br>The only problem with "exit" is that you might call it when you're not actually in fullscreen state, since requests are asynchronous. I think of it more as cancelling the request than actually forcing a change.<br>
</div></div></blockquote><div><br></div></div><div>That explains the method name, but I think the most common usage will be to exit fullscreen, rather than to cancel a recent request to enter fullscreen.</div></div></div>
</blockquote><div><br>Sure. But I still want to convey that this is a request, not a command. In Gecko I'd like to ensure that if a user activated fullscreen via browser UI, cancelFullScreen will be ignored.<br><br></div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><br><div><div class="im"><blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Why don't requestFullScreen()/requestFullScreenWithKeys() return<br>
a boolean value indicating whether the UA will allow the request<br>
to proceed? The author has no information about whether fullscreen<br>
is going to happen after making this call, and UAs will certainly<br>
want to deny fullscreen in various situations.<br></blockquote><div><br>The UA may not be able to make a decision synchronously. Permitting asynchronous decisions about whether to permit fullscreen was a key goal here. For example that gives UAs the option of presenting passive confirmation UI.<br>
</div></div></blockquote><div><br></div></div>Right. However, I think we need a "fullscreenDenied" event in that case, so the author is informed that their request failed for whatever reason. The most common cause of failure may be that the UA doesn't allow it (e.g. WebKit may make this opt-in for embedding applications, so calling this API in your RSS reader would result in a denied request).</div>
</div></blockquote><div><br>It's probably worth having such an event, but there will be times when neither fullscreendenied or fullscreenchanged are fired. I hope authors don't write apps that break in such cases.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><br><div><div class="im"><blockquote type="cite">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

I'd like to see the proposal fleshed out to address the following<br>
scenarios:<br>
<br>
* the document is fullscreen, and navigation happens<br></blockquote>* the document is fullscreen, and the content calls requestFullScreen()<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


  again (possibly with a different element, possibly inside an iframe).<br></blockquote></div></blockquote><div><br></div></div><div>I think the spec needs to at least say what happens here. Does the second call change the fullscreen element to the new element, or is it simply ignored?</div>
</div></div></blockquote><div><br>The spec says that the fullscreen element is changed.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;"><div><div class="im"><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

* the document is fullscreen, and the fullscreen element is removed<br>
  from the DOM<br></blockquote></div></blockquote><div><br></div></div>In this case I think you'd either exit fullscreen, or update the pseudostyles to make the document element the new fullscreen element.</div></div>
</blockquote><div><br>The spec currently says that in this case, no element gets the :fullscreen pseudostyle. I don't see any problem with that. This isn't something useful for authors to do, so I don't think it really matters what we do here as long as the result is well-defined and there aren't security issues.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div class="im"><br><blockquote type="cite">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
* the document is fullscreen, and the fullscreen element has<br>
  display:none set on it.<br></blockquote></div></blockquote><div><br></div></div>I guess the window just goes blank in this case?</div></div></blockquote><div><br>No, you'll see the page laid out in the viewport.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div class="im"><br><blockquote type="cite">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
* consideration of whether the fullscreen API can be called at<br>
  any time (risk of "drive-by-fullscreening").<br></blockquote></div></blockquote><div><br></div></div>We've talked before about limiting the API so fullscreen can only be entered in response to a user event, and I still think that's sensible.</div>
</div></blockquote><div><br>It is sensible, and we should recommend that behavior, but it may not make sense for some UAs/UIs so I don't think it should be a hard requirement. Do we specify popup blocking behavior anywhere? This is just like that.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><br><div class="im"><div><blockquote type="cite">
<div class="gmail_quote"><div>Done. In most of those cases, nothing special happens. That is intentional; for example, I think trying to special-case handling of display:none or focus would quickly add a lot of complexity.</div>
</div></blockquote></div><br></div><div>Are you saying that the spec should not prescribe these behaviors? I think  the UA should be permitted to exit fullscreen in certain scenarios if it deems that necessary for security reasons, as we've discussed before:</div>
<div><<a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024897.html" target="_blank">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024897.html</a>></div></div></blockquote>
<div> </div></div>The spec is completely clear that UAs are allowed to exit fullscreen at any time, for any of the reasons mentioned in your email or for any other reason.<br clear="all"><br>Rob<br>-- <br>"Now the Bereans were of more noble character than the 
Thessalonians, for they received the message with great eagerness and 
examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]<br>