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

I haven't experimented much with out-of-content UI for click-to-play
myself, but (general UI issues aside) I suspect it'd still be pretty
problematic for scripting due to timing. Letting the instances
instantiate after relevant script has run and received unexpected
exceptions that it can't properly understand won't help in many cases.
Reloading the page after the user allows plugins to load is an option,
but not a very appealing one.

I'm also worried about uptake for any solution requiring code changes,
but I don't know that there is a better solution and we might be able
to get enough of the top sites to behave well that the feature isn't
too disruptive.

On Tue, Jun 12, 2012 at 1:48 AM, Adam Barth <w3c@adambarth.com> wrote:
> 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 06:40:36 UTC