[whatwg] Full Screen API Feedback

[Robert O'Callahan]

On Fri, May 13, 2011 at 10:15 AM, Jer Noble <jer.noble at 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]