848160 - Determine the set of plugins for which Firefox will help users download/install

Status: RESOLVED FIXED

(Toolkit Graveyard :: Plugin Finder Service, defect, P2)

Description

[Justin Dolske [:Dolske]]

Bug 836415 and others are making a major change in what Firefox does when visiting a page that wants a plugin that's not installed on the user's system. Currently we always show some UI about a "missing plugin", through which the user can get the plugin if it happens to be one of the few types of plugins that PFS knows about.

Plugins are a major source of stability and security issues, and are generally a bad thing for the web. We thus want to limit the kinds of plugins Firefox will offer to install to only the barest minimum. Ideally that will become "no plugins", but for today we need to balance that against the need to help users get a widely-used plugin (like Flash).

The current PFS code is https://github.com/mozilla/zamboni/blob/master/services/pfs.py The previous version, lest archaeology be interesting, was http://viewvc.svn.mozilla.org/vc/addons/trunk/site/app/webroot/services/pfs.php?view=markup

Currently we support (on at least one platform):

1) Adobe Flash
2) Adobe Shockwave
3) Real Player
4) Apple Quicktime
5) Java
6) Adobe Acrobat
7) Viewpoint Media Player
8) Windows Media Player
9) XStandard XHTML WYSIWYG Editor
10) DNL Reader ("digital web books")
11) VideoEgg Publisher
12) DivX Web Player

We've got data from server logs on existing PFS usage (bug 836428). More on that later, but the initial thought is that we can probably reduce this down to just Flash and Java.

Plugin types no recognized by Firefox/PFS will either show whatever fallback content the page has (which is usually something that tells people how to install the plugin) or a simple placeholder UI from Firefox (TBD, maybe something akin to attachment 705102 [details] with a different icon).

Filing this bug so if there are issues to discuss about which plugins should/shouldn't be on the list, we can do that here instead of the other bugs that are transforming this feature/UI.

Comment 1

[Justin Dolske [:Dolske]]

Are we able to make a decision here yet?

Comment 2

[Benjamin Smedberg]

Data from PFS:

[Flash] (64.57%)
[Java] (9.59%)
[Windows Media] (4.50%)
application/x-director (3.97%)
[QuickTime] (3.81%)
application/octet-stream (3.34%)
text/html (2.49%)
application/x-vlc-plugin (0.81%)
application/pdf (0.55%)
text/plain (0.46%)
application/vnd.unity (0.43%)
application/qvod-plugin (0.37%)
application/gas-ibh-abn (0.37%)
[Zylom Games] (0.23%)
[Silverlight] (0.20%)
[Skype] (0.20%)
video/divx (0.13%)
audio/x-mpegurl (0.13%)
application/x-hardwaredetection-plugin (0.13%)
application/mozilla-wat-scriptable-plugin-11 (0.12%)

The things that are surprising to me:
* WMP shows up pretty high. The WMP plugin is basically permanently broken, so we don't really have anything to offer people.
* Shockwave and Quicktime are both higher than I thought they would be
* PDF is smaller than I thought. But that's probably because it's seldom loaded in <object> but usually just gets downloaded.

Given this data, I'd like to start with the following (further iteration based on support data is likely):

* Flash - direct link to installers with hashes (windows) - https://get.adobe.com/flashplayer/ (Mac/Linux)
* Java - link to SUMO warning page
* Shockwave - link to https://get.adobe.com/shockwave/ (Win/Mac)
* Quicktime - link to https://www.apple.com/quicktime/download/ (Win) - SUMO troubleshooting (Mac) - SUMO -> VLC (Linux)

We shouldn't do anything for PDF, and I don't think there's anything we can do for WMP so we'll leave that out as well.