Click-to-play plugins: rollup of current status and work

There are a bunch of different teams working on the current 
click-to-play (CtP) plugins effort, and there are a bunch of small-group 
email threads going around. I would like to consolidate all of this work 
to a single discussion forum, and I've asked everyone I know who is part 
of this effort to carry on their design discussions here in 
dev-apps-firefox.

Note: please reply/follow up to mozilla.dev.apps.firefox only!

For information on the teams, as well as some summary information and 
bug queries, see this wiki page: 
https://wiki.mozilla.org/Firefox/Click_To_Play

Talking about click-to-play has been complicated, because we have 
several parallel goals and efforts:

* Make users more secure by blocking known-unsafe version of plugins
* Give users control by having them opt in to "new" plugins that are 
found on their machine
* Make Firefox faster and less crashy by reducing the number of plugin 
instances that users see

SECURITY-BLOCKED PLUGINS

Up to now, we have been focusing primarily on the first of these goals, 
"security click-to-play". We have long wanted to be able to block 
known-insecure versions of common plugins. This has been hard because 
some users (especially those in enterprise and education settings) 
cannot upgrade, and in other cases there are poorly constructed sites 
that only work with specific versions of plugins (especially Java). 
click-to-play blocking of plugins allows us to strike a balance between 
protecting users from "drive by" plugin exploits and allowing them to 
accomplish work that requires plugins.

Another issue with the current UI is that because the click-to-play UI 
is in-content, it is relatively easy to construct a website which 
"clickjacks" the user into activating a plugin even if they didn't mean 
to. The security team has proposed that when a plugin is known to be 
insecure, we should not simply accept a single click on a plugin 
instance, but instead the user should activate the plugin from the 
doorhanger UI instead (which is not clickjackable). This is covered in 
bug 832481. Larissa Co from UX is currently in the process of 
understanding the interaction model here and coming up with the best design.

One goal of the UI is allowing users to enable a plugin "always for this 
site". We've discovered that in the current UI, it's hard to discover 
that you *can* whitelist a plugin to always activate for a particular 
site, even though that is the desired solution for sites that a user 
visits regularly. We are not yet certain how to solve this problem, but 
are going to test one possible solution in bug 834749. This problem may 
be moot for "security blocked" plugins if the doorhanger solution above 
is implemented. The security team has also raised concerns that "always 
for this site" should not be *forever* when a plugin is insecure, but 
should only last for a period of time, so that the user is reminded that 
they have an insecure plugin.

Some websites are poorly written; they try to use plugins immediately 
after they are created, and even if the user clicks to display the 
plugin later, the website will not work correctly. One potential 
solution is to choose "always for this site" and reload; this should 
cause plugins to behave normally. We are also considering a less 
"permanent" solution like "reload with plugins enabled" which would 
enable plugins either for only one reload, or only for the current 
session, or some intermediate period of time.

In enterprise and education deployments, there has been significant 
desire to be able to automatically deploy per-site whitelists for 
plugins even if they are known to be insecure. This allows 
administrators to keep intranet sites from breaking for users. We are 
currently investigating writing a small addon which would use a 
preconfigured whitelist to bypass the normal protections for specific 
domains.

The last issue that has come up is how we deal with small or hidden 
plugin instances. This is mostly a problem with Flash, because invisible 
Flash instances are commonly used by websites for various reasons, 
including playing music (Pandora), playing noises (Chat), fancy 
file-upload controls (facebook/wordpress), and advertising trackers 
(many big news sites). Striking the right UI balance here has been very 
difficult. Users always have the option of enabling all Flash on a page 
by clicking the plugin icon in the location bar. But most users don't 
notice this UI, and even if they do they don't know what it's for. For a 
while, we tried popping up the plugin doorhanger on every page that had 
a hidden plugin. But we quickly discovered that this totally annoys 
users because many pages with advertising trackers have hidden Flash, 
and they didn't understand why Firefox was interrupting their web 
browsing on news sites. Our current compromise solution in Firefox 18 is 
that each time you run Firefox, we will show the doorhanger notification 
*once*, and after that we won't show it again; the theory is that if we 
show the relationship between the doorhanger and the plugin icon in the 
location bar, that users will know where to look. But comments from 
users in our support site show that this solution is still unpopular 
with many users who don't understand when the doorhanger will show and 
when it won't. Other options that were considered include a notification 
bar (the yellow bar at the top of the window), but that solution has 
additional problems as duplicating the doorhanger UI, and not 
reinforcing the plugin icon in the location bar. I believe that our 
current solution is only barely good enough, and we will need to 
continue experimentation and design to find the correct balance in this UI.

USER CONTROL (or click-to-play by default)

The next step that my team is focusing on is making most plugins 
click-to-play by default. Many users do not realize that they have 
plugins installed, often plugins which are installed into the system by 
other software which is entirely unrelated to web browsing. We are 
trying to make it possible to not enable most plugins automatically, but 
rather to make them CtP by default and give the user the option to 
always enable them, enable them per-site, or completely disable them.

In general, the UI issues with making plugins CtP by default are very 
similar to a known-insecure plugin. However, we are planning on making 
the in-content UI much less "threatening" looking, and we want to allow 
single-click activation and do not plan to solve the "clickjacking" 
problem for this class of plugins. This work is covered in bug 831921, 
and the most recent visual design can be found at this screenshot: 
http://cl.ly/image/0N2y1C3B0R2G/o

In addition, we need to change the addon manager to expose a tri-state 
enabled/disabled/click-to-play setting switch for plugins (bug 549697). 
We also need to change the backend system for storing the 
enabled/disabled state of plugins: this state is currently stored by 
plugin name and path in pluginreg.dat, and because both plugin names and 
paths can change when they are upgraded, we need to switch to storing 
plugin state by MIME type. This work is covered in bug 832085. There is 
a lot of secondary UI which is still being completed. For example, there 
is currently no way to view or reset your choice after you have chosen 
"Always for this site". This is being added to the page info dialog, and 
we may also expose this information via options in the addons manager.

In this timeframe, we don't believe that we can make the most recent 
version of Flash click-to-play by default. Too many websites and users 
rely on Flash content for videos, games, and other features. We are 
continuing to work hard to make it possible to write websites that don't 
require Flash.

I am hopeful that we will have all this work completed in time for the 
Firefox 22 trains. I am tracking the set of bugs needed for this work 
with the "CtPDefault" whiteboard tag and this bugzilla query: 
https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr;status_whiteboard=CtpDefault%3AP;resolution=---;resolution=DUPLICATE;query_format=advanced

STABILITY

Plugins are the #1 cause of both crashes and pauses in Firefox. While we 
continue to work with Adobe to improve Flash stability, we would also 
like to investigate the possibility of making all plugins, including 
Flash, click-to-play by default. In order to see how this would affect 
users, we are going to be running a user research study later this 
month. In the custom build for this study, we are including the visual 
design enhancements, as well as some basic UX improvements to make 
"always for this site" more prominent. We are also aggressively 
instrumenting the build to see which pieces of UI are used, as well as 
what plugins users choose to activate. The study participants will be 
asked to write journal entries about their experience; whether Firefox 
felt faster, whether they were able to use all their websites, and their 
feelings about the new behavior. Mary Trombley has helped me design and 
implement this study along with the rest of the UR team.

I am tracking the set of bugs needed for the custom build using the 
"CtPUR" whiteboard tag and this bugzilla query: 
https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr;status_whiteboard=CtPUR%3A%2B;resolution=---;resolution=DUPLICATE;query_format=advanced

Finally, although this is not directly related to click-to-play, we are 
planning on removing the Plugin Finder Service (PFS) from Firefox. 
Previously when Firefox encountered web content which needed a plugin, 
it would prompt the user to install the plugin. Instead, we are now 
discouraging users from using browser plugins, and want to avoid this 
prompt.

HOW CAN I HELP?

For now, the best way you can help is by turning on the hidden pref 
"plugins.click_to_play". If you have specific websites that don't work, 
you should feel free to file bugs in the "Core:Plug-ins" component. 
Please be as specific as possible, including the following information:

* The exact URL of the page
* The plugin information from about:plugins
* Whether "always for this site" causes the site to work correctly

If you are capable, I'd love to have volunteers to help take these 
reports and create minimal testcases from them. It is possible that some 
websites are "unfixable" in normal conditions and require a feature like 
"reload with plugins enabled" to work properly, but in many cases we've 
found ways to fix common javascript or actionscript libraries to better 
support click-to-play, as well as making changes in Firefox itself to 
allow these websites to work. Bugmasters wanted!

Finally, if you have a suggestion for improving the user experience, 
especially the experience for hidden Flash plugins or the design of the 
doorhanger notification, please forward them to this list. It is 
probably not worth filing a bug until the design has been discussed.

--BDS