[whatwg] Full Screen API Feedback

[Jer Noble]

On May 12, 2011, at 12:31 AM, Boris Zbarsky wrote:

> On 5/12/11 3:24 AM, Jer Noble wrote:
>> A) If an author calls requestFullScreen(), at some point in the future they will receive either a "fullscreenchanged" event or a "fullscreendenied" event.
>> B) If an author calls requestFullScreen(), at some point in the future they may receive a "fullscreenchanged" event, or not.
>> 
>> I'd argue that A) is easier to grasp.
> 
> (A) is easier to grasp incorrectly to.  In practice, "at some point in the future" means "maybe you'll get it, or maybe you won't", because for any finite time period the future may not have arrived yet.
> 
> (B) just makes that explicit so authors don't get confused.

No, that still doesn't make sense.  At the time when the user decides to allow or deny full screen access, either a "fullscreenchanged" or a "fullscreendenied" event is fired.  Saying that "fullscreendenied" will confuse users is akin to saying that "fullscreenchanged" will confuse them as well.

>>> I don't necessarily agree with that part of the geolocation API :-).
>> 
>> Fair enough.  But it is an API in relatively wide use now.  Have authors complained that the timing of the error handler is too confusing?
> 
> Yes. http://stackoverflow.com/questions/5947637/function-fail-never-called-not-if-user-declines-to-share-geolocation-in-firefox for example (where the author misunderstood the difference between "denied" and "hasn't decided yet").

That doesn't seem like a confusion about the API, but with Firefox's UI.  Note that they are not confused by Chrome's behavior.  I don't believe that Firefox's UI decisions should justify removing what would otherwise be a useful piece of API.

So far, neither you nor Roc have been able to articulate why this event should be omitted beyond vague handwaving about developer confusion.  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

>> True, without the "fullscreendenied" event, authors will be forced to "pre-fallback" to a full-window mode.  But with the "fullscreendenied" event, they can decide whether to do that, or a more traditional post-denial full-window mode.
> 
> 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? 

To be quite honest, the way Firefox implements this feature seems like a usability nightmare.  Surely there's a way to achieve the security benefits you're hoping for without requiring intentionally obtuse API?

-Jer