[whatwg] communicating plugin state (primarily for click-to-play)

[Peter Kasting]

On Tue, Jun 12, 2012 at 1:07 PM, Glenn Maynard <glenn at zewt.org> wrote:

> On Tue, Jun 12, 2012 at 1:22 PM, Peter Kasting <pkasting at google.com>wrote:
>
>> The "temporary" implementation
>> should probably be along the lines of "reload the page, this time allowing
>> all plugins".  As noted already in this thread, simply allowing plugins
>> after script has already tried to start them and communicate simply won't
>> work a lot of the time.
>>
>
> Not according to the model Adam suggested: a plugin that hasn't yet
> received permission to start acts like a plugin that simply hasn't loaded
> yet.
>

It's important to distinguish solutions for authors versus solutions for
UAs.  Authors should try and code according to Adam's model.  However, for
pages which don't, UAs may still need to direct users to reload the page.

I don't support Glenn's suggestion to show a larger prompt when a plugin
>> instance isn't visible, for two reasons.  One is that determining
>> visibility it, in the limit, impossible.
>
>
> What matters is if the visibility detection is 1: web-compatible (matches
> up with what websites are doing with plugins that have in-page UI vs.
> script-only plugins) and 2: well-defined, not whether you can detect that a
> plugin is visible in every case.
>
> #1 may be impossible, though, especially if it's not known to the browser
> in advance whether the plugin has UI.  It's probably better to just always
> show a prompt bar.
>

Not only that, but your point 2 again is only accurate when speaking of
pages where the authors are trying to work with click-to-play and thus are
ware of the visibility rules and take them into account.  However, the
feature needs to also work well with other sites which don't take these
rules into account, meaning that for those pages, you're reduced to the
non-computable case.

The second is that the purpose of
>> this feature is generally to reduce annoyance; showing prompts atop the
>> window is annoying, especially if it happens frequently.
>>
>
> The entire purpose of those non-modal prompts is to be unintrusive and out
> of the way.  That style of prompting is designed exactly for this sort of
> thing.
>

As a member of Chrome's UI team I can assure you that getting an infobar on
every page that has a blocked plugin leads to fury in about ten minutes.
 This is why our indicators are icons that appear in the "page action" area
of the Chrome omnibox.  This is unobtrusive enough to not be annoying.
 Unfortunately it's also unobtrusive enough to leave less-expert users
baffled.

Also, pages should not be required to create placeholder areas inside pages
> to give the browser a place to prompt; it's the browser's job to do that
> for itself (again with prompt bars, doorhangers, and the like).  That's
> especially true because the page has no way of knowing whether the browser
> is actually going to prompt (it may not use confirmations for the plugin
> being used, or the user may have clicked "yes, always" on a previous
> session).  This belongs out-of-line.
>

It's often easy for a page to give the plugin a temporary visible location
and hide it once the plugin actually loads, without the user noticing
anything in the common case where permission has been implicitly or
explicitly granted.  As I said, this isn't always possible.

PK