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

Benjamin Smedberg benjamin at
Sat Nov 9 19:18:22 UTC 2013

Here is the current status of this feature (9-November):


The following bugs have now all landed on nightly, aurora, and beta for 
FF26 beta 3:

* Doorhanger icon disappearing when the page navigates a subframe 
(testcase - bug 915951
* UI changes to make the in-content UI look more clickable: bug 932446
* Plugins removed immediately after being added and scripted don't 
trigger the notification - bug 745187
* 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

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.


In a meeting Thursday, Madhav coordinated the final decision on the UI 
behavior for the plugin infobar. Long-term, the infobar will have the 
following text and buttons:

known-unsafe plugins:
Nightly has prevented the unsafe plugin "Foo" from running on [Continue Blocking] [Allow...] [x]
The infobar will have the same dark stripy styling that we for 
in-content insecure plugins.

unknown plugins:
Allow to run "Foo"? [Continue Blocking] [Allow...] [x]
The infobar will have the default grey styling.

The "Continue Blocking" button will permanently prevent the infobar from 
re-showing on this site. "Allow..." will open the doorhanger. The close 
button will temporarily close the infobar; it may reshow on 
navigation/future visits.

On branch, neither of the strings "Continue Blocking" nor "Allow..." 
with an ellipsis are present. Therefore we are going to substitute the 
strings that already exist: "Block Plugin" and "Allow" (no ellipsis).

The patch to accomplish this change is in bug 932854.


Some sites will detect that plugins are not working and will present 
instructions for installing. There's not much we can do about this 
except contact the site in question.

A manual reload may be required for some sites.

On, using the Box editing plugin: the site detects that the 
plugin doesn't work and opens a popup window with instructions for 
installing the plugin. The plugin icon is present in the original 
window, but the popup makes it relatively confusing.

On Google earth, the site scripts the plugin and immediately removes it 
from the page if it doesn't work. Our doorhanger (and infobar, when it 
lands) correctly show, and after you click the "Allow" button our 
implementation auto-reloads the page.

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

* - 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. - Now has a patch.
* - 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).


More information about the firefox-dev mailing list