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

[Adam Barth]

I've had good luck with the click-to-play feature in Chrome.  It might
be worth giving it a try on sites that are causing you trouble to see
whether it handles them well or poorly.

One thing that's helpful w.r.t. script errors is the observation that
sites need to wait for plug-ins to load asynchronously.  If a plug-in
that's awaiting a click acts like a plug-in that's still loading from
the network, there's a good chance that the script on the page will
wait for the user to activate the plug-in before attempting to
communicate with it.

We have had some complaints along the lines you describe, but
interestingly mostly from web site operators, not from users.  (Users,
myself included, seem quite happy with the feature.)  One thing we
recommend is that web site operators give plugins some height and
width until they're loaded.  That way users have something to click on
to activate them.

Adam


On Mon, Jun 11, 2012 at 11:40 PM, Josh Aas <joshmoz at gmail.com> wrote:
> 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 at 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 at 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