[whatwg] Full Screen API Feedback

[Boris Zbarsky]

On 5/12/11 3:54 AM, Jer Noble wrote:
> No, that still doesn't make sense.  At the time when the user decides to allow or deny full screen access

The point is this may be never.  They might just wake forever to make a 
decision.

>  Saying that "fullscreendenied" will confuse users is akin to saying that "fullscreenchanged" will confuse them as well.

I'm saying that if authors expect to get one or the other but then never 
do, that will confuse authors.

> That doesn't seem like a confusion about the API, but with Firefox's UI.

Firefox's UI simply allows a user to defer the decision.  There's no 
problem there.

> Note that they are not confused by Chrome's behavior.

Oh, really?  Try this:

1)  Open Chrome.
2)  Load http://www.mozilla.com/en-US/firefox/geolocation/#geo-demo
3)  Click the "Give it a try" link
4)  Click the "Where am I?" button that appears
5)  Click the [x] on the resulting notification bar in Chrome

Observe the fact that neither the success nor the error callback is invoked.

If you look at the behavior carefully, Chrome has three ways to interact 
with the notification:  1)  Click "Deny": this denies forever, 2) Click 
"Allow": this allows forever, 3) Click the [x]; this defers the 
decision.  Note that options 1 and 2 don't make it clear the decision is 
forever.

Firefox has the same three ways: 1) Select the "Never Share" option, 2) 
Select the "Always Share" option, 3) Select the "Not Now" option (or 
dismiss the notification).

All that happened is that the _developer_ (not a user!) got confused 
about the meaning of "Not Now".  It really does mean "I haven't decided 
yet", not "I'm not sharing".

>  I don't believe that Firefox's UI decisions should justify removing what would otherwise be a useful piece of API.

The piece of API is broken, as Chrome's behavior described above shows. 
  All it's doing is creating incorrect author expectations.

> So far, neither you nor Roc have been able to articulate why this event should be omitted beyond vague handwaving about developer confusion.

I'm not sure how "you can't depend on this event ever firing, so you 
have to code on the assumption that it won't fire, but the spec makes 
you think that it will fire" can be any clearer.

> On the contrary, there are real use cases for the denial event:
>
> - Failing over to a browser specific full screen mechanism (such as webkit's video element full screen mode)
> - Removing or disabling the full screen button from a web-app.
> - If a web app requested keyboard access, re-requesting with a no-keyboard full screen mode.
> - General user feedback

None of these work if the event can't be expected to fire on any set 
schedule!

>> And what do they do for the arbitrarily long time before getting any event at all?
>
> Display an indeterminate progress meter? Disable the full screen button?

That doesn't seem reasonable, honestly. Once a user clicks that [x] in 
Chrome, what happens?  They get stuck?

> To be quite honest, the way Firefox implements this feature seems like a usability nightmare.

It's just fine for the users.  The only problem in the geolocation case 
is that that the way the API is described creates unrealistic 
expectations on the part of _developers_.

> Surely there's a way to achieve the security benefits you're hoping for without requiring intentionally obtuse API?

Not if we want to allow users to actually take however long they want to 
make the decision.  Which we do.

-Boris