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

[Glenn Maynard]

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.

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.

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.

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.

-- 
Glenn Maynard