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

Larissa Co lco at
Thu Sep 5 04:10:41 UTC 2013

Hi Richard,

Thanks for the comments about the Click-to-Play UI. I know Matt's 
already addressed some of your points, but I wanted to add more info to 
let you know that we're actively trying to improve the UX.

> Note that in order to provide a fast user experience we instantiate our
> plugin essentially hidden and show it when it's needed.  Thus the black box
> with no click to play UI in it.  This could be *helped* if click to play
> would detect that the plugin moved and put the UI back in, but some of our
> functionality (the gradebook transfer) is used while the plugin is
> invisible, and this would still have the same problem.
We initially thought that we couldn't do this page reload, but I think 
we have the means to do this now. There's a similar bug which is solved 
by this mechanism:

So if there hasn't been a bug created for this particular use case, I 
can create one.
> I completely understand the reasoning behind click to play; I understand
> why you want to have it block plugins by default (though it still ticks me
> off that there are exceptions for flash but not for anyone else).
Note that we're not trying to play favorites in the long run. Flash will 
eventually suffer the same fate ;-) Our general stance is that we do 
want to Web to be robust enough that developers don't need to write and 
maintain plugins. I know you mention below that you don't think this is 
realistic. I can't fully answer that question, but I do hope that 
because part of Mozilla's mission is to make the Web a robust platform, 
we'll be quicker at addressing non-standard or novel use cases in the 

>   The thing that baffles me is that the whole issue could be rather easily
> solved by just having a more visible indication pop up *at least* the first
> time that a plugin is encountered on a page; maybe a popup, a top bar, or
> something.
Yes, as Matt explained, we're working on this. Improvements for 
invisible plugins are at the top of our list. The current UI is subtle 
because we need to strike a balance between annoyingness and 
helpfulness, since as you mentioned, there are a lot of plugins that are 
just noise. But we also understand that in the current state of the Web, 
people still use plugins, and we need to find ways to help them get 
their task done.

> Do you realize that you're showing more information when a popup is blocked
> than you do when a plugin is blocked?
:( I know, a lot of the work is going on to standardize UI. That's why 
some of the changes to the current CtP implementation are taking a while 
to get through.
> Finally, the fact that the well-hidden option to unblock a plugin only
> works on a per-site basis means that this whole thing is twice as big of a
> problem as it already because we do all of our installs on
> and then redirect the user back to the
> partner site that is using it.  First of all we'll have to somehow deal
> with walking the user through enabling the plugin, but then we're also
> going to have to have them do it again once they leave the sphere of our
> control and return to the calling site. I guess we could try to "talk" them
> through unblocking it through the add-on manager; that might be the only
> good option.
With the UI discoverability improvements we're planning on making, it 
will hopefully be less of a problem if you're trying to do this on 
multiple sites.

Hope this helps,

More information about the firefox-dev mailing list