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
