[whatwg] Feedback on the Mozilla FullScreen API proposal

[Robert O'Callahan]

On Fri, Aug 6, 2010 at 1:37 PM, Simon Fraser <smfr at me.com> wrote:

> On Aug 5, 2010, at 5:56 PM, Robert O'Callahan wrote:
>
> On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser <smfr at me.com> wrote:
>
>
> >  * void cancelFullScreen()
>>
>> I think "exit" would be better than "cancel".
>>
>
> 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.
>
>
> 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.
>

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.


> Why don't requestFullScreen()/requestFullScreenWithKeys() return
>> a boolean value indicating whether the UA will allow the request
>> to proceed? The author has no information about whether fullscreen
>> is going to happen after making this call, and UAs will certainly
>> want to deny fullscreen in various situations.
>>
>
> 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.
>
>
> 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).
>

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.


> I'd like to see the proposal fleshed out to address the following
>> scenarios:
>>
>> * the document is fullscreen, and navigation happens
>>
> * the document is fullscreen, and the content calls requestFullScreen()
>
>>  again (possibly with a different element, possibly inside an iframe).
>>
>
> 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?
>

The spec says that the fullscreen element is changed.


>
> * the document is fullscreen, and the fullscreen element is removed
>>  from the DOM
>>
>
> In this case I think you'd either exit fullscreen, or update the
> pseudostyles to make the document element the new fullscreen element.
>

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.


> * the document is fullscreen, and the fullscreen element has
>>  display:none set on it.
>>
>
> I guess the window just goes blank in this case?
>

No, you'll see the page laid out in the viewport.


>
> * consideration of whether the fullscreen API can be called at
>>  any time (risk of "drive-by-fullscreening").
>>
>
> 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.
>

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.


> 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.
>
>
> 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:
> <
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024897.html
> >
>

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.

Rob
-- 
"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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100806/6922435b/attachment-0002.htm>