[whatwg] Full Screen API Feedback

On 5/12/11 12:48 PM, Jer Noble wrote:
>> 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.

The problem is not "for" any particular event.  The problem is in 
creating an author expectation that one of the two events will 
definitely be called.  This expectation is incorrect.

If there is only one event, then there can be no such expectation, for 
obvious reasons: the behavior when full screen is denied is that there 
is no event, so authors have to handle the case of no event in a sane way.

>> 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'm saying that the fact that such developer confusion is possible with 
perfectly reasonable browser UI choices is a bug in the API that we 
should not duplicate.

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

The API is designed in such a way that developers have no good 
indication that they have to handle "user has not decided" situations.

At the same time, such situations are clearly considered beneficial by 
multiple UAs, and I think you will have a hard time finding a UI 
designer who thinks that actually forcing the user to decide in this 
case (i.e. forcing a modal dialog on them) is a good idea.

In other words, the API is designed to fail when any reasonable UI is 
used for the permissions system.  It really is an API bug.  I'm not sure 
how to make that clearer.

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

I believe you have _completely_ misunderstood what I said.  I'm 
describing a problem in the geolocation API as it stands.  You're .... 
talking about something else.  Unfortunately, I'm not quite sure how you 
got there from here.

I think we really need to get this complete failure of communication 
sorted out for the rest of this discussion to be productive.  :(

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

How?  I'd love an example of how you would code a web page to do these 
things if both the success and error events might never come.

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

I would think yes.  That's what happens with geolocation, as you could 
have tested trivially.

> 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

Hold on.  We're talking about geolocation here and whether it's a good 
model to follow, no?  I'm not presuming to design UI for the full-screen 
case, and I have no indication that this would be the UI used for 
full-screen.

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

What does that event get us at that point?  Keep in mind that the "user 
denies" case is very likely to be a _rare_ case.  The common cases would 
be "user accepts" and "user defers".

-Boris

Received on Thursday, 12 May 2011 11:24:10 UTC