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

[Ilya Sherman]

On Mon, Jun 11, 2012 at 11:47 PM, Adam Barth <w3c at adambarth.com> wrote:

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

FWIW, a contrasting user perspective: I tried using Chrome's click-to-play
feature for several months, and eventually gave up on it because it broke
too many websites, both due to timing issues and UI issues.  I now instead
keep plugins disabled, and temporarily enable individual ones when a
website I'm using requires 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
>