Status of click-to-play plugins in Firefox 24/26

Benjamin Smedberg benjamin at
Mon Nov 4 15:58:56 UTC 2013

Here is the current status of this feature:


* Doorhanger icon disappearing when the page navigates a subframe 
(testcase - bug 915951 fixed for Saturday's 
nightly and already has aurora/beta approval already
* UI changes to make the in-content UI look more clickable: bug 932446, 
landed for today's nightly and I just requested aurora/beta uplift
* Plugins removed immediately after being added and scripted don't 
trigger the notification - bug 745187 landed for today's nightly and I 
just requested aurora/beta uplift
* Bug 932786 - after you choose to enable or disable a plugin via the 
notification, the notification doesn't update the UI to the new state - 
minor regression from bug 926605, landed for today's nightly and 
aurora/beta uplift requested

With this series of patches, all sites that I know about now show the 
notification icon and work correctly when the user enables plugins via 
the notification. A reload may be required for a few sites.

I'm going to post the approval details here, rather than spread across 
the bugs:

Testing completed: manual testing on as well as the sites which 
were broken. In the 4-Nov nightly for general testing. Paul Silaghi has 
been doing focused verifications as well.
Risk assessment: the patches here are unlikely to affect anything other 
than click-to-activate plugins. They are all fairly small, but together 
there is some risk of regression in this feature. I believe we should 
take them in early betas and do focused testing and feedback analysis.
No string or IDL changes.


We have decided to implement a notification bar to make hidden plugins 
explicitly visible, but the exact interaction and visual appearance of 
the notification is not yet resolved. Here are the 
wireframes/screenshots that were being discussed in IRC:


In this design, the "More Options" button would open the notification 
panel. The "Continue Blocking" button would permanently dismiss the 
notification bar for that site. Clicking the "X" would close the 
notification for the current page but it would reopen if other pages on 
the site use hidden plugins.

I would also need the no-entry icon in a 16x16 size.


my own prototype:

I'm a little unhappy with the options that have a one-click Allow 
button. In general, I think we should require two clicks to activate all 

There has not been a clear decision on which of these options to 
implement. I'm also a little worried about having to invent new button 
styling to implement shorlander's UI mockups, since I don't think there 
are already button styles for the blue/highlighted options. What I 
propose that I implement something like shorlander's mockup with the 
followup changes:

* use standard OS styles for all the buttons
* use the "Continue Blocking" and "More Options" buttons for both the 
insecure-plugin and unknown-plugin cases
* Because we don't have a "More Options" string, just use "Options"

I am also tracking the following issues, but I do not consider them 
release blockers:

* - Can't click on 
the click-to-play UI if the site overlays the element with an element in 
another subtree. This primarily affects the apple movie trailers site. 
We may be able to work around this by using the hidden-plugin 
doorhanger. We cannot fix this with z-ordering because of the way DOM 
subtrees and z-ordering work.
* - Click to play 
doesn't work for pages with generated POST data (primarily a problem for 
PDF docs and acrobat).
* - Disable running 
plugins on the page when the user blocks them. Right now the option only 
takes effect on reload, which can be slightly confusing.


More information about the firefox-dev mailing list