Click to play, the next big problem for many smaller companies

Benjamin Smedberg benjamin at smedbergs.us
Thu Sep 5 15:53:43 UTC 2013


On 8/27/2013 5:43 PM, Richard Bateman wrote:
> Users of our website will see this when they go to scan an exam with 
> the plugin: http://cl.ly/image/0h343L0t221D

This could be a bug. Is the plugin actually supposed to be visible at 
that location?
>
> There is no discoverability at all because the plugin was instantiated 
> while it was hidden; further, some functionality of the plugin is 
> often used when the plugin is hidden, so even if you fixed what I 
> consider to be a bug in click to play that keeps it from noticing that 
> the object tag is now visible and show the "activate" icon it only 
> helps and doesn't fully solve the problem.

To separate the issues: it is certainly not intentional that the CtP UI 
is hidden when the plugin element itself is shown. That's a bug, and we 
should fix it. If we can't fix it in time for FF26, I'd certainly 
consider adding a temporary whitelist item for this particular plugin.

The other case, where you are using (scripting) an invisible plugin, the 
case is more difficult: in general we expect that when this happens, 
most commonly it's going to be a compromised ad network which is trying 
to attack users via vulnerable Java or other plugins. So I argue that in 
the common case, we don't want users to notice the icon if there's a 
hidden plugin, so that they won't be exposed to unnecessary risk.

I'm interested to know how you use the hidden plugin. In general, my 
recommendation for dealing with this in your product is to do the 
following: whenever you're trying to script the plugin but it's not 
responding (and therefore probably click-to-play), show the plugin 
element with a popup: this gives the user the opportunity to click the 
plugin element and choose "always allow" in the most natural manner.

--BDS




More information about the firefox-dev mailing list