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

Richard Bateman richard at
Thu Sep 5 16:47:16 UTC 2013

On Sep 5, 2013, at 9:53 , Benjamin Smedberg <benjamin at> wrote:

> 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:
> This could be a bug. Is the plugin actually supposed to be visible at that location?

The plugin object *is* visible at that location, it just isn’t drawing anything. I would certainly call it a bug, and it makes a bad situation already worse. If I refresh the page (it’s a single page app) then the CtP UI does show up, which does at least help.

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

The functionality of the hidden plugin in this case responds to a keypress (configurable by the user, usually one of the “F” function keys) so that they can trigger it from another application (the gradebook).  (before you ask, yes, we’ve been very careful to make sure that functionality cannot be abused by a malicious third party to make it useful for other applications).  Because of that, if the plugin doesn’t load then we don’t know that it’s needed until it pops up.  I’m sure we can find some way of dealing with this on detecting that the plugin isn’t loading, but currently if the plugin starts hidden the CtP UI doesn’t show up when you make it visible anyway (see above bug).

That would at least help in our case; what makes it much less attractive is the fact that all of our partners who are using our plugin will also have to implement a similar measure.  So far we’ve taken care of the install process for them by providing our own install page (at but with this we’ll have to either come up with a way to build good enough UI into our javascript library to fix the problem for them or we’ll have to educate each of our partners on how to implement such a thing themselves.  Either way will be a lot of work and a lot of annoyed business partners. Either way will cause a lot of support calls and cost a lot of money.

In addition, this is just our case — part of the reason that I am so frustrated with this issue is that I feel like your strategy is based on a perception that I completely disagree with.  The only way that your strategy for handling hidden plugins makes sense is if we take as true the idea that most hidden plugins are not needed, useless, and/or malicious in nature.  It requires enough work to get a plugin installed on a user’s machine that I don’t believe that is usually the case.  I realize that some plugins are automatically included in the installer for another application that the user has installed, but even so there are a great many plugins out there — I would expect even most of them — that are only there and only used because they are needed for the functionality of the page.  The difficulty of handling drawing on all three platforms (not to mention all the different NPAPI browsers) means that it is often much easier to build a hidden plugin that uses javascript and an HTML interface than it is to make a visible plugin, and the vast majority of the plugins people talk to me about with FireBreath are in fact hidden plugins.

What I keep coming back to is this:

When the average user goes to a website that requires a plugin, that website’s plugin *will not load* and in most cases that user *will not have any idea why*.  Even the brief popup idea that Larissa is discussing will almost certainly (in our experience) not be seen by users.

This means that anybody that relies on plugins that uses a hidden plugin is going to have to go to elaborate lengths to educate their users on how to work around this problem.

My counter-suggestion is simply that you make a persistent notification that appears when this is the case (top bar, popup that needs to be dismissed, etc) that lets the user decide if they should show the plugin.  Make it default with a checkbox that says “never show again for this plugin” if you want; make it default to block, make it clear that if they don’t trust the plugin that they should keep it blocked.  I don’t care! But *please please please* do not leave the current situation where pages will suddenly be broken with no obvious reason to the user as to why it’s broken.  I beg of you — I know you hate plugins, but please do not shoot us all in the foot like that. I utterly reject the idea that the minor inconvenience of seeing a notification once is going to be more annoying than the alternative.

Whitelisting our plugin in Firefox 26 would be very kind of you. It would also solve the problem for us, but not for everyone else who will have the same issue — and indeed most of the FireBreath users that I know of are actually using entirely hidden plugins and thus will have an even bigger problem than we will. The sad fact that all web developers have to deal with is that if you have a bug or problem in even one version of a major browser then the code to workaround it can essentially never be removed from the codebase.  If you release Firefox 26 with this “feature” in it everyone who has to deal with it will have to build hackish workarounds that they will be stuck with for years at the very least.

Hidden plugins are not all viruses; there are a *huge* number of plugins that I know of (and that’s just the ones I hear about) that are hidden plugins that are completely legitimate.  They include things like USB interfaces to capture x-ray information, camera interfaces (like ours), complex processing such as GPG encpryption or image processing (like ours), interfaces with authentication devices, hardware control stuff, serial port interfaces, and much more.  Those are just the ones I thought of off the top of my head — if you need, I can find more.

Please do not ship this on in Firefox 26; please let us find a better solution.  Please.  I cannot even express to you how frustrated I am with the direction this is going — if plugins are a problem, work with other browsers and find a way to fix them, but don’t take them away entirely.  I have yet to see a plan that stands a remote chance of solving the problems that *I* have that require plugins to solve, and I am just one person.

Thanks for your consideration,

Lone plugin advocate

More information about the firefox-dev mailing list