- From: Ilya Sherman <isherman@chromium.org>
- Date: Tue, 12 Jun 2012 13:11:21 -0700
- To: Adam Barth <w3c@adambarth.com>
- Cc: Josh Aas <joshmoz@gmail.com>, whatwg@whatwg.org
On Mon, Jun 11, 2012 at 11:47 PM, Adam Barth <w3c@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@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@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 20:12:30 UTC