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

I'm somewhat skeptical whether adding such an DOM property will
actually solve the problem.  I would expect that many sites that use
hidden plug-ins won't update to use the new DOM property, which means
you'll need a solution that doesn't involve the web site changing its
code.  One approach is to provide a UI affordance for playing the
plug-in outside of the web page itself.

Adam


On Mon, Jun 11, 2012 at 5:29 PM, Josh Aas <joshmoz@gmail.com> wrote:
> Mozilla has been working on a click-to-play feature for plugins. The
> feature currently breaks a large number of sites because it interacts
> poorly with scripting and fallback schemes. For example, quite a bit
> of plugin usage doesn't involve user-visible content but rather plugin
> instances that exist for scripting alone. When instances aren't
> created as expected for script calls, the resulting exceptions cause
> problems.
>
> 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.
>
> This could be expressed via a Web IDL enum property on embed and
> object elements. The property could be called something like
> "pluginState". The states might be (with apologies for the rough
> names):
>
> - not-plugin (object/embed is some other type like image or document)
> - active (plugin instance created, running)
> - inactive (e.g. crashed)
> - no-handler (e.g. missing plugin)
> - click-to-play (click-to-play UI is diplayed, should become active upon click)
>
> Thoughts?
>
> --
> Josh Aas
> Mozilla Corporation

Received on Tuesday, 12 June 2012 05:50:02 UTC