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

Reply via email to