subject:"Re\: \[whatwg\] Full Screen API Feedback"


On 5/12/11 2:25 AM, Robert O'Callahan wrote:

On Thu, May 12, 2011 at 4:45 PM, Jer Noblejer.no...@apple.com  wrote:

And your geolocation example actually argues the other way: the existing
geolocation API includes an asynchronous error handler that is explicitly
called when a request is denied.  This would be a similar if not identical
use case.


I don't necessarily agree with that part of the geolocation API :-).


One note here:  The denied handler for geolocation is not fired as often 
as you might think.  For example, Firefox only fires it if you select 
never for this site.  If you select not now or just click the 
notification away, or if you do nothing, of course, nothing is fired, 
because the user has not actually made a decision (you can reopen the 
notification and decide any time you want).


 It's also pretty bad if some passive UI

appears, the user ignores it, then later notices it and dismisses it, and
the video suddenly fills the window!


The right solution _if_ one goes this way is for the dismissal to just 
not notify the page at all, as in the geolocation behavior above.


I agree that it's a suboptimal behavior either way, though.  I prefer 
your proposal of maximizing within the window and effectively asking the 
user to maximize the window.


-Boris

Re: [whatwg] Full Screen API Feedback


On May 11, 2011, at 11:25 PM, Robert O'Callahan wrote:

 On Thu, May 12, 2011 at 4:45 PM, Jer Noble jer.no...@apple.com wrote:
 
  2. Animating into and out of full screen.
 
  WebKit's current video full-screen support will animate an element between 
  its full-screen and non-full-screen states.  This has both security and 
  user experience benefits.  However, with the current z-index-based 
  rendering technique recommended by the proposed Full Screen API, animating 
  the full-screen transition is extremely difficult.
 
  Proposal: The full-screen element should create a new view, separate from 
  its parent document's view.  This would allow the UA to resize and animate 
  the view separate from the parent document's view. This would also solve 
  issue 1 above.
 
  I'm not sure what you mean exactly by a new view. Depending on what you 
  mean, that could create all kinds of implementation and spec issues. For 
  example, if an element can have different style or layout in the two views, 
  DOM APIs that return those things become ambiguous. I would strongly object 
  to that.
 
 I'm not suggesting that the element exists in two views simultaneously, but 
 rather that it becomes the root of a new viewport.
 
 What does that mean in CSS terms?
 
 Does the element cease to exist in the old viewport? If so, what would that 
 mean in CSS terms?

I would imagine that, yes, the element ceases to exist in the old viewport.  
I'm not sure what that would mean in terms of CSS.

 Having elements in the same document be in different viewports still creates 
 all kinds of spec and implementation issues :-(.

It very well might.  The current proposal has issues of it's own though. :)

  It seems to me you could animate the transition without having multiple 
  concurent views. For example, freeze the rendering of the document in its 
  browser window, put the document into the fullscreen state, and display it 
  in a popup window that starts off matching the geometry of the fullscreen 
  element and zooms out to cover the screen.
 
 That is much more difficult than it sounds.  :)
 
 Freezing the non-full-screen content is already undesirable.  The animation 
 can take an arbitrary amount of time to complete,
 
 Really? Why? It shouldn't take more than a second to complete, surely?

This is hypothetical, but imagine a touch-based UI where the user can pinch 
to enter and exit full-screen.  In this UI, the full-screen animation is under 
direct control of the user, and so can take as long as the user wants it to 
take.  

  4. A lack of rejection.
 
  The current proposal provides no notification to authors that a request to 
  enter full screen has been denied.  From an UA implementor's perspective, 
  it makes writing test cases much more difficult.  From an author's 
  perspective it makes failing over to another full screen technique (such as 
  a full-window substitute mode) impossible.
 
  Proposal: add a fullscreenrequestdenied event and require it to be 
  dispatched when and if the UA denies a full-screen request.
 
  My main concern is that with some UI scenarios there might not be a good 
  time to fire the denied event. For example, in Firefox 4 when an 
  application requests geolocation a popup appears, and if the user clicks 
  anywhere outside the popup the popup disappears but there is still UI 
  allowing the user to grant the request later. If we used the same approach 
  for fullscreen, I think we wouldn't want to fire the denied event unless 
  the user actually selects no in the popup. (It would seem confusing to 
  deny the request and then grant it later.) I'm wary of authors writing code 
  that assumes a denied event will fire and breaks when it doesn't, or when 
  it fires later than they expect.
 
 
 
 The current API already requires that authors listen for events that may 
 occur in the far future.  I don't see how this event would be any different.
 
 You mean fullscreenchanged?
 
 I'm confident authors will understand that fullscreenchanged might fire 
 late or never and will encounter that during testing. I'm less confident it 
 will be obvious to authors that both fullscreenchanged and 
 fullscreendenied might never fire and will encounter that during testing.

I'm not sure I get the distinction.  In fact, it seems to me to be the 
opposite. 

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.

 And your geolocation example actually argues the other way: the existing 
 geolocation API includes an asynchronous error handler that is explicitly 
 called when a request is denied.  This would be a similar if not identical 
 use case.
 
 I don't necessarily agree with that part of the geolocation API :-).

Fair enough.  But

Re: [whatwg] Full Screen API Feedback


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.


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



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?


-Boris

Re: [whatwg] Full Screen API Feedback

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

Re: [whatwg] Full Screen API Feedback


On May 12, 2011, at 12:54 AM, Jer Noble wrote:

 Surely there's a way to achieve the security benefits you're hoping for 
 without requiring intentionally obtuse API?

Okay, here's another proposal that should work with Firefox's passive 
permission system:

Proposal:  

- Add a new boolean Element property canRequestFullScreen.  This would map to 
Firefox's Never permission choice.
- Add the fullscreendenied event.  This would map to Firefox's Not now 
permission choice.

Use case/Scenario:

A video player would first query canRequestFullScreen to decide whether to 
display the full screen button in its UI.  If the user hadn't previously 
decided to never allow this site to enter full screen, this property would 
return true (or perhaps maybe).  Upon clicking the full screen button, the 
user would be presented with a notification.  If the user chooses Never, a 
fullscreendenied event is dispatched at the requesting element, and 
subsequent calls to canRequestFullScreen would return false (or perhaps an 
empty string).  In this situation, the video player would hide their 
full-screen button. If the user chooses Not now, a fullscreendenied event 
is dispatched at the requesting element, but subsequent calls to 
canRequestFullScreen would still return true/maybe.

Alternative:

The canRequestFullScreen property could be replaced with a function which 
takes the same flags as requestFullScreen.

-Jer

Re: [whatwg] Full Screen API Feedback

2011-05-12 Thread timeless

On Thu, May 12, 2011 at 11:12 AM, Jer Noble jer.no...@apple.com wrote:
 Okay, here's another proposal that should work with Firefox's passive 
 permission system:

 Proposal:

 - Add a new boolean Element property canRequestFullScreen.  This would map 
 to Firefox's Never permission choice.
 - Add the fullscreendenied event.  This would map to Firefox's Not now 
 permission choice.

Your proposal makes it fairly easy for sites to stick up annoying full
content blocking you must change your settings to proceed elements.

This is the wrong path.

Re: [whatwg] Full Screen API Feedback

2011-05-12 Thread James May

Why can't the browser just do the fullscreen in a window behaviour
until/if the user approves?

No need for new events even, although a fullscreen lost, sourced eg. from
some browser UI or loss of focus, might be useful.

I don't see why it would make a difference from the page's perspective
whether it would was actually taking up an entire screen or just all of a
certain window/tab. If the user wants the fullscreen ui without actually
being fullscreen, why stop them or allow pages to force them?


On 12 May 2011 18:42, timeless timel...@gmail.com wrote:

 On Thu, May 12, 2011 at 11:12 AM, Jer Noble jer.no...@apple.com wrote:
  Okay, here's another proposal that should work with Firefox's passive
 permission system:
 
  Proposal:
 
  - Add a new boolean Element property canRequestFullScreen.  This would
 map to Firefox's Never permission choice.
  - Add the fullscreendenied event.  This would map to Firefox's Not
 now permission choice.

 Your proposal makes it fairly easy for sites to stick up annoying full
 content blocking you must change your settings to proceed elements.

 This is the wrong path.




-- 
-- James May

Re: [whatwg] Full Screen API Feedback

2011-05-12 Thread timeless

On Thu, May 12, 2011 at 1:46 PM, James May wha...@fowlsmurf.net wrote:
 Why can't the browser just do the fullscreen in a window behaviour
 until/if the user approves?

I don't see anything wrong with this offhand :)

 No need for new events even, although a fullscreen lost, sourced eg. from
 some browser UI or loss of focus, might be useful.

 I don't see why it would make a difference from the page's perspective
 whether it would was actually taking up an entire screen or just all of a
 certain window/tab. If the user wants the fullscreen ui without actually
 being fullscreen, why stop them or allow pages to force them?

:)

Re: [whatwg] Full Screen API Feedback


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

Re: [whatwg] Full Screen API Feedback


On 5/12/11 4:12 AM, Jer Noble wrote:

- Add a new boolean Element property canRequestFullScreen.  This would map to Firefox's 
Never permission choice.
- Add the fullscreendenied event.  This would map to Firefox's Not now 
permission choice.


So if the user just dismisses the notification without picking any of 
the choices then fullscreendenied would fire in this proposal?


What happens if the user then reopens the notification and selects Allow?

-Boris

Re: [whatwg] Full Screen API Feedback


On May 12, 2011, at 1:42 AM, timeless wrote:

 Your proposal makes it fairly easy for sites to stick up annoying full
 content blocking you must change your settings to proceed elements.

That ability exists in the current API as well.  A malicious website would just 
require the fullscreenchanged event before allowing the user to continue.

-Jer

 Jer Noble jer.no...@apple.com

Re: [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.no...@apple.com

Re: [whatwg] Full Screen API Feedback


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

 On 5/12/11 4:12 AM, Jer Noble wrote:
 - Add a new boolean Element property canRequestFullScreen.  This would map 
 to Firefox's Never permission choice.
 - Add the fullscreendenied event.  This would map to Firefox's Not now 
 permission choice.
 
 So if the user just dismisses the notification without picking any of the 
 choices then fullscreendenied would fire in this proposal?

I'm not trying to tell Firefox how to write their UI.  And I would never 
suggest requiring this behavior in a spec.  But, for the purposes of exploring 
this proposal, yes.

 What happens if the user then reopens the notification and selects Allow?


Assuming the targetted element still exists, and that the page hasn't issued a 
cancelFullScreen() request (or perhaps either of those conditions would cause 
the notification to disappear?) then the page enters full-screen mode and 
generates a fullscreenchange event.

Yeah, it's somewhat weird to get a fullscreenchange event after a 
fullscreendenial.  But the spec already specifies that The user agent may 
transition a Document into or out of the full-screen state at any time, whether 
or not script has requested it.  So the devoloper must already expect 
un-requested fullscreenchange events.

-Jer

 Jer Noble jer.no...@apple.com

Re: [whatwg] Full Screen API Feedback

2011-05-12 Thread Aryeh Gregor

On Thu, May 12, 2011 at 2:25 AM, Robert O'Callahan rob...@ocallahan.org wrote:
 It seems rational to me: click on fullscreen, the video fills the entire
 window (but not the screen), and some browser UI appears to suggest going
 the rest of the way.

This sounds really bad to me.  The user shouldn't have to be prompted.
 Just make sure that you only do it in response to user action (like
with window.open()), and hitting most keys will leave fullscreen mode,
and you display a message like Fullscreen mode, hit ESC to exit for
a couple of seconds at the top.  That's basically what Flash does,
right?  Does that cause problems?  I'm pretty sure we all agree that
prompting the user is horrible UI and should be avoided wherever
possible.

Re: [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. :(

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

Re: [whatwg] Full Screen API Feedback

On 5/12/11 1:16 PM, Jer Noble wrote:

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

On 5/12/11 4:12 AM, Jer Noble wrote:

- Add a new boolean Element property canRequestFullScreen. This would map to Firefox's
Never permission choice.
- Add the fullscreendenied event. This would map to Firefox's Not now
permission choice.

So if the user just dismisses the notification without picking any of the choices then
fullscreendenied would fire in this proposal?

I'm not trying to tell Firefox how to write their UI. And I would never
suggest requiring this behavior in a spec. But, for the purposes of exploring
this proposal, yes.

Sure; the question was about how this proposal could work in existing
permissions systems; not at all limited to Firefox.

What happens if the user then reopens the notification and selects Allow?

Assuming the targetted element still exists, and that the page hasn't issued a
cancelFullScreen() request (or perhaps either of those conditions would cause the
notification to disappear?) then the page enters full-screen mode and generates a
fullscreenchange event.

Yeah, it's somewhat weird to get a fullscreenchange event after a fullscreendenial. But the
spec already specifies that The user agent may transition a Document into or out of the full-screen state at any
time, whether or not script has requested it. So the devoloper must already expect un-requested
fullscreenchange events.

Ah, ok.

I could probably live with this. It still leaves weirdness in Chrome,
though, or other systems with a more persistent UI than Firefox's
current notification popus, if the user doesn't dismiss the notification
at all...

-Boris

Re: [whatwg] Full Screen API Feedback


On 5/12/11 1:43 PM, Aryeh Gregor wrote:

On Thu, May 12, 2011 at 2:25 AM, Robert O'Callahanrob...@ocallahan.org  wrote:

It seems rational to me: click on fullscreen, the video fills the entire
window (but not the screen), and some browser UI appears to suggest going
the rest of the way.


This sounds really bad to me.  The user shouldn't have to be prompted.
  Just make sure that you only do it in response to user action (like
with window.open()), and hitting most keys will leave fullscreen mode,
and you display a message like Fullscreen mode, hit ESC to exit for
a couple of seconds at the top.  That's basically what Flash does,
right?  Does that cause problems?  I'm pretty sure we all agree that
prompting the user is horrible UI and should be avoided wherever
possible.


To be clear, we are NOT designing the UI for this thing here.  I'm not a 
UI designer.  Robert is not a UI designer.  As far as I know, you are 
not a UI designer.


We are trying to design an API that could then have a variety of UIs 
built on top of it as needed.  The key is to design an API that does not 
overconstrain those UIs and does not generate mistaken web developer 
expectations due to them observing (or theorizing) some particular 
subset of possible UIs.


Discussion of possible UIs is only useful here insofar as it informs our 
decisions about what assumptions the API should allow web developers to 
make.


So let's try attacking the problem from that angle.  I posit that for 
web developers the following are bad assumptions and that the API should 
make it clear that they are bad assumptions:


1) Your page will automatically go into fullscreen when you ask it to
2) After you ask your page to go into fullscreen, you are guaranteed a
   response within time T (for some finite T) indicating whether this
   has happened.
3) You can figure out whether the user has decided that your site
   should never be able to go into fullscreen (exposing that
   information increases the fingerprintability of the browser, so
   I suspect at least some browsers would not want to expose it).

Are there any other such assumptions we need to steer clear of?  Are 
there assumptions in the list above that people think are reasonable 
assumptions for web developers to make?  If so, please speak up; I think 
we'll have a better chance at getting somewhere in this discussion if we 
can at least agree on our premises!


-Boris

Re: [whatwg] Full Screen API Feedback

First things first:

On May 12, 2011, at 11:24 AM, Boris Zbarsky wrote:

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

and:

 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.

Ah, okay.  Sorry, I was under the opposite impression.  I had thought the 
permissions model and UI that Firefox was suggesting was identical to the 
Geolocation case.   If not, then you're right, I'm conflating the two issues.  
I'll try to limit my responses to the topic at hand. :)

As I'm not really looking to rehash or debate the geolocation API and browser's 
implementation of it, I'm going to leave off responding to some of the points 
raised below.  I'm not trying to be evasive in doing so, but just trying to 
focus in on the full-screen API.

Continuing...

On May 12, 2011, at 11:24 AM, Boris Zbarsky wrote:

 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.

I understand what you're saying.  By making the error case deliberately 
ambiguous, you're trying to force the author to behave in a certain way.  
However, I disagree that this is a) likely to work and b) likely to be less 
confusing than the alternative.

Of course, one solution to both confusion and incorrect expectations is 
documentation.  :-)  If it were made both clear and explicit that either of 
those events may never be dispatched after requestFullScreen() is called, 
shouldn't that suffice?

 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.

(skipping ahead)

 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.

I agree with the first statement.   However, I don't expect that user defers 
will actually be that common.  

If you look at the Suggested UA Policy portion of the spec, most cases are 
either implicitly accepted or denied without user prompting.

I expect that, for the overwhelming majority of cases, full-screen requests 
will be either be implicitly accepted (for user-action driven, non-keyboard 
requests), or implicitly denied (non-user-action driven requests).   For the 
remainder (user-driven, keyboard-access requests), the requests will be 
overwhelmingly non-malicious, resulting in user accepts, and those that are 
spam/popups will result in user denies.

So I'd argue that the case where a page author would have to wait any 
appreciable amount of time before receiving a fullscreendenied event is 
actually quite rare.

-Jer

Re: [whatwg] Full Screen API Feedback

On Fri, May 13, 2011 at 10:15 AM, Jer Noble jer.no...@apple.com wrote:

 On May 12, 2011, at 11:24 AM, Boris Zbarsky wrote:

  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.


 I understand what you're saying.  By making the error case deliberately
 ambiguous, you're trying to force the author to behave in a certain way.
  However, I disagree that this is a) likely to work and b) likely to be less
 confusing than the alternative.


We want to merge the decision deferred case with the decision denied
case. It's a strictly simpler model. And by making them indistinguishable,
we force developers to treat them the same way, so it can't really fail to
work.

Of course, one solution to both confusion and incorrect expectations is
 documentation.  :-)  If it were made both clear and explicit that either of
 those events may never be dispatched after requestFullScreen() is called,
 shouldn't that suffice?


We can try that, but Web developers are notoriously resistant to
documentation, thanks to copy-paste coding, use of wrapper libraries, and
the spread of misinformation :-).

If you look at the Suggested UA Policy portion of the spec, most cases are
 either implicitly accepted or denied without user prompting.


 I expect that, for the overwhelming majority of cases, full-screen requests
 will be either be implicitly accepted (for user-action driven, non-keyboard
 requests), or implicitly denied (non-user-action driven requests).   For the
 remainder (user-driven, keyboard-access requests), the requests will be
 overwhelmingly non-malicious, resulting in user accepts, and those that
 are spam/popups will result in user denies.


I hope you're right, but we shouldn't design our API on that assumption. We
don't want to get into a situation like clickjacking or CSS history sniffing
where attack scenarios that we always knew about suddenly become popular
and we have made API decisions that mean we can't address those scenarios
without breaking content.

So I'd argue that the case where a page author would have to wait any
 appreciable amount of time before receiving a fullscreendenied event is
 actually quite rare.


For what my sample size of one is worth, when Firefox pops up its passive
This Web page tried to open a popup window UI, I usually ignore it rather
than dismiss it.

Rob
-- 
Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true. [Acts 17:11]

Re: [whatwg] Full Screen API Feedback

On Fri, May 13, 2011 at 4:48 AM, Jer Noble jer.no...@apple.com wrote:

 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.


It's easy to get a user to click in a page so requiring mouse clicks isn't a
lot of protection. The scenario people are worried about is that the user
clicks, the page goes full-screen and initiates some kind of spoofing
attack, the user doesn't realize what is going on and gets phished or
something like that --- and that is irreversible.

For this case, I think probably a better UI would be what Flash has, to
actually go full-screen immediately but temporarily show a message telling
the user they're in fullscreen mode and how to get out. But I still strongly
feel that the API should be constrained so that passive confirmation won't
break sites, in case that turns out to be necessary in the future.

Rob
-- 
Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true. [Acts 17:11]

Re: [whatwg] Full Screen API Feedback

[Re-CCing list, hope that's OK.]

On Fri, May 13, 2011 at 11:03 AM, Jer Noble jer.no...@apple.com wrote:

 On May 12, 2011, at 3:49 PM, Robert O'Callahan wrote:

 On Fri, May 13, 2011 at 10:15 AM, Jer Noble jer.no...@apple.com wrote:



 I understand what you're saying.  By making the error case deliberately
 ambiguous, you're trying to force the author to behave in a certain way.
  However, I disagree that this is a) likely to work and b) likely to be less
 confusing than the alternative.


 We want to merge the decision deferred case with the decision denied
 case. It's a strictly simpler model. And by making them indistinguishable,
 we force developers to treat them the same way, so it can't really fail to
 work.


 Okay.  What about merging those two cases at the point where the user
 defers the decision?

 I had previously proposed that, for the sake of argument, a browser could
 dispatch a denied event when the user deferred a decision.  Wouldn't this
 also force developers to treat denied and deferred cases the same?


That only works if the browser can detect a deferral. If the user simply
ignores the browser's UI, you wouldn't know when to fire the event. And
there's also the issue of a fullscreendenied being followed by a
fullscreenchange, which is weird, but I guess we could live with it if it
was the only issue.

Although, if the user simply ignores the browser's UI, maybe the browser
could fire the fullscreendenied event when there's next keyboard input or a
mouse click into the tab that requested fullscreen. But I just made that up
so I'll need to think about whether it's reasonable :-).


 So I'd argue that the case where a page author would have to wait any
 appreciable amount of time before receiving a fullscreendenied event is
 actually quite rare.


 For what my sample size of one is worth, when Firefox pops up its passive
 This Web page tried to open a popup window UI, I usually ignore it rather
 than dismiss it.


 Interesting.  Does Firefox display that message for non-user-action driven
 pop-ups?  Or are those blocked silently?


It displays that message for non-user-action driven pop-ups. Popups in mouse
click events are automatically allowed (and open a new tab).

Rob
-- 
Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true. [Acts 17:11]

Re: [whatwg] Full Screen API Feedback


On May 12, 2011, at 4:23 PM, Robert O'Callahan wrote:

 That only works if the browser can detect a deferral. If the user simply 
 ignores the browser's UI, you wouldn't know when to fire the event. And 
 there's also the issue of a fullscreendenied being followed by a 
 fullscreenchange, which is weird, but I guess we could live with it if it 
 was the only issue.
 
 Although, if the user simply ignores the browser's UI, maybe the browser 
 could fire the fullscreendenied event when there's next keyboard input or a 
 mouse click into the tab that requested fullscreen. But I just made that up 
 so I'll need to think about whether it's reasonable :-).

Of course.  I was really only talking about explicit user deferral actions; 
there might not be a good way to solve the problem of ignoring the 
notification.  If it's anything like the current Firefox Geolocation 
notification, wouldn't a click in the non-popup area dismiss the notification?

 
 So I'd argue that the case where a page author would have to wait any 
 appreciable amount of time before receiving a fullscreendenied event is 
 actually quite rare.
 
 For what my sample size of one is worth, when Firefox pops up its passive 
 This Web page tried to open a popup window UI, I usually ignore it rather 
 than dismiss it.
 
 
 Interesting.  Does Firefox display that message for non-user-action driven 
 pop-ups?  Or are those blocked silently?
 
 It displays that message for non-user-action driven pop-ups. Popups in mouse 
 click events are automatically allowed (and open a new tab).

Okay.  Assuming Firefox adopts the Suggested UA Policy portion of the API, 
equivalent full-screen window requests would be implicitly denied, so you would 
hopefully not be spammed by full-screen request notifications quite as 
frequently.

-Jer

Re: [whatwg] Full Screen API Feedback

2011-05-12 Thread Aryeh Gregor

On Thu, May 12, 2011 at 2:34 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 To be clear, we are NOT designing the UI for this thing here.  I'm not a UI
 designer.  Robert is not a UI designer.  As far as I know, you are not a UI
 designer.

Definitely correct on that last point.

 We are trying to design an API that could then have a variety of UIs built
 on top of it as needed.  The key is to design an API that does not
 overconstrain those UIs and does not generate mistaken web developer
 expectations due to them observing (or theorizing) some particular subset of
 possible UIs.

If we can figure out in advance what UIs browsers will want to use in
practice, though, that should inform what API we settle on.
Generality is not always good.  If it turns out no one wants to ask
the user before fullscreening, we don't want to design the API to
allow for that design decision, any more than we want to design the
API for canvas.toBlob() or any random function to allow for the
possibility of asking the user before allowing it to work.

So if the desired API will depend on the sort of UI browsers will want
to implement, I'd ask the UI people what UI they'd use before deciding
on the API.

 So let's try attacking the problem from that angle.  I posit that for web
 developers the following are bad assumptions and that the API should make it
 clear that they are bad assumptions:

 1) Your page will automatically go into fullscreen when you ask it to
 2) After you ask your page to go into fullscreen, you are guaranteed a
   response within time T (for some finite T) indicating whether this
   has happened.
 3) You can figure out whether the user has decided that your site
   should never be able to go into fullscreen (exposing that
   information increases the fingerprintability of the browser, so
   I suspect at least some browsers would not want to expose it).

Those all seem like reasonable things to avoid.  However, (3) is
probably impossible to avoid for some choices of UI.  If the UI is
like for popup windows, which seems reasonable, then either the
browser will go fullscreen right away or it won't, and you can tell by
timing.  Of course, browsers aren't obliged to maintain a per-site
blacklist on fullscreening if they don't want to.

On Thu, May 12, 2011 at 7:02 PM, Robert O'Callahan rob...@ocallahan.org wrote:
 For this case, I think probably a better UI would be what Flash has, to
 actually go full-screen immediately but temporarily show a message telling
 the user they're in fullscreen mode and how to get out. But I still strongly
 feel that the API should be constrained so that passive confirmation won't
 break sites, in case that turns out to be necessary in the future.

What possible future scenario are you envisioning where passive
confirmation might turn out to be necessary in the future?  In
particular, Flash has allowed this for years, with 95%+ penetration
rates, so we should already have a good idea of how this feature can
be exploited in practice.  (Or at least someone at Adobe should.
Maybe we could ask them?  They have people in the HTMLWG.)

Re: [whatwg] Full Screen API Feedback


On 5/12/11 6:15 PM, Jer Noble wrote:

I understand what you're saying.  By making the error case deliberately 
ambiguous, you're trying to force the author to behave in a certain way.


Not quite.  I think Robert handled this in his response to this mail, so 
I'll just stick to following that subthread.



However, I disagree that this is a) likely to work and b) likely to be less 
confusing than the alternative.


Yeah, I think that's where our disagreement lies.


Of course, one solution to both confusion and incorrect expectations is 
documentation.  :-)


See what Robert said.  Past performance is no guarantee of future 
behavior, etc, but my hopes are not high.  :(



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.


I agree with the first statement.   However, I don't expect that user defers 
will actually be that common.

If you look at the Suggested UA Policy portion of the spec, most cases are 
either implicitly accepted or denied without user prompting.


Hmm.  OK, but that does mean that the user defers case will probably 
just end up broken if sites never see it...  The only way I see to 
prevent such breakage is to not have rare cases.  Above I was arguing 
that we should merge the rare user denies case into the common user 
defers case, but if their rarity is reversed I still think they should 
be merged


-Boris

Re: [whatwg] Full Screen API Feedback


On 5/12/11 8:29 PM, Aryeh Gregor wrote:

If we can figure out in advance what UIs browsers will want to use in
practice, though, that should inform what API we settle on.
Generality is not always good.


Yes.


If it turns out no one wants to ask the user before fullscreening


I'm 99% sure that someone does.  This would be a pretty typical thing 
for NoScript to do, say.


If you have reasons to believe that there is really no one who would 
want to do so, I'd love to hear them.



So if the desired API will depend on the sort of UI browsers will want
to implement, I'd ask the UI people what UI they'd use before deciding
on the API.


Yes, that seems like a good idea too.


So let's try attacking the problem from that angle.  I posit that for web
developers the following are bad assumptions and that the API should make it
clear that they are bad assumptions:

1) Your page will automatically go into fullscreen when you ask it to
2) After you ask your page to go into fullscreen, you are guaranteed a
   response within time T (for some finite T) indicating whether this
   has happened.
3) You can figure out whether the user has decided that your site
   should never be able to go into fullscreen (exposing that
   information increases the fingerprintability of the browser, so
   I suspect at least some browsers would not want to expose it).


Those all seem like reasonable things to avoid.  However, (3) is
probably impossible to avoid for some choices of UI.


That's fine.  I'm not saying all browsers will care about 
fingerprinting.  But the ones who _do_ shouldn't have to violate this 
spec to deal with it when designing their UIs.



If the UI is
like for popup windows, which seems reasonable, then either the
browser will go fullscreen right away or it won't, and you can tell by
timing.  Of course, browsers aren't obliged to maintain a per-site
blacklist on fullscreening if they don't want to.


Indeed.  They're also not obligated to tell the site the truth about 
when they've made the fullscreen decision... unless the spec calls for 
it.  ;)


-Boris

Re: [whatwg] Full Screen API Feedback