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

On Mon, Jun 11, 2012 at 5:29 PM, Josh Aas <joshmoz@gmail.com> wrote:

> In order for click-to-play to be a viable feature we'll probably need
> to allow pages with complex plugin usage (i.e. scripting) to query for
> click-to-play state.
>

The advice we (Chromium team) give developers is to check navigator.plugins
to see whether the plugin is available at all.  (Users without the plugin
installed, or with it completely disabled, will not have an entry there.)
 If the plugin is available, go ahead and attempt to construct it and
script it.  (The best UX is if this instance can, at least initially, get
some visible region of the page, so that click-to-play users would see the
placeholder content there.  This is not always feasible or desirable, but
it can be done a large percentage of the time.)  If this fails, assume
click-to-play is enabled, and show whatever fallback UI is necessary.  This
avoids the need for extra DOM properties.

Separately, the browser should also indicate to users when a page has
blocked plugins, and give the user the ability to temporarily or
permanently control this restriction.  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.

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

PK

Received on Tuesday, 12 June 2012 18:24:15 UTC