[whatwg] Full Screen API Feedback

On May 12, 2011, at 5:44 AM, Boris Zbarsky wrote:

> 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.

Again, I fail to see how this is a problem for the "denial" event but not for the "change" event.

>> 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.

Right, I'm saying the developer is confused about FIrefox's UI.  He (apparently) expects "Not now" to generate an error.

> 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".

Exactly.  I'm saying it's a UI confusion, and not one that justifies removing the error notification.

>> 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.

I strongly disagree.  Firefox's UI behavior is causing confusion, not the API.  This problem is not endemic to the geolocation feature, but rather to one (or two) implementations of that feature.

>> 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.

I can: by adding an explicit error event.

>> 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!

Sure they can!  Every single one of these can.

>>> 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?

Stuck?  They're already in full screen purgatory. :)  What would happen if they clicked on the full screen button again?  Would Firefox pop up another notification?

>> 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_.

I don't consider the following to be a "usable" UI:

- User clicks a full screen button
- Content resizes to occupy full window
- Browser pops up a permissions dialog
- User has to click the "Allow" button*
- Window then becomes full screen

* This line is especially egregious.  I can understand asking for permission if the original full screen request did not originate with a mouse click.  Heck, I'm fine with /requiring/ full screen to initiate with a mouse click.  But asking the user to confirm "did you really mean to do this?" for an easily reversable action is poor UI.  If the browser inadvertantly exposes the user's geolocation to a website, that's an action that can never be undone.  The same is not true for the full screen case.

Now, this UI might be necessary in order to fend off unwanted, full-screen, pop-under advertising or phishing attacks.  That doesn't make it good UI, but possibly a minimilaly bad UI.  All I'm saying is that there may be an even less bad UI which would provide the same benefits.

>> 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.


Thtat's fine.  But I still don't agree that this requires there to be no error event when the user eventually does make that decision.

-Jer

? Jer Noble <jer.noble at apple.com>

Received on Thursday, 12 May 2011 09:48:49 UTC