The plugin finder service hasnt seen any improvements for quite some time. To get things started the following changes are proposed: + move plugin finder service UI to the Tools -> Addons dialog + allow a choice of plugins for a given mime-type + allow multiple install methods (e.g. xpi, apt, rpm ...) to be plugged such that distributors (like linux distros) are able to provide plugin binaries from their own archives.
I'm mentoring together with Alexander a project in Mozilla Europe which aims to improve that. We will try to get a consensus with others and get it into Mozilla. Arzhel is currently working on it, and WIP 1 patch should be uploaded soon
I'm a little concerned that you're diving straight into code here when as yet I haven't seen a good overall plan for how we expect the UI to behave for this. Are there any mockups of how this will look and what the user interactions will be? What sort of changes are expected to be necessary for the pfs service on AMO? See also bug 430853
Dave: We're writing those. I understand your concern, we'll try to shape out the plan and then get review from stakeholders.
OK, lets first discuss the suggested improvements to the user-experience. Once we agreed on that we can go into detail and outline the changes required for this on a technical/code/web-service level. Use-Case: Install missing mime-types ====================================== Visiting a site with mime-type that has no plugin, will trigger the missing plugin notification box - as its now. The only difference is that the install wizard will be implemented as a richlistbox in a addons dialog tab (Find Plugins); this improves user experience as it makes it more consistent and allows to provide a choice to the user. Use-Case: Plugins Management ============================== The Plugins-Management Tab will be improved to support per-mime-type selection of plugins. If you want a mockup, look at the Preferences -> Application tab. Likewise, in the left column you would see the mime-type and on the right hand side get the following options with 1) being the preselected value: 1) <current used plugin> 2a) <installed alternative 1> 2b) <installed alternative 2> 2c) ... 3) "disable" 4) "Other ..." Clicking on the search for alternative plugins will open the plugin finder wizard tab and present a list of alternative plugins available for that mime-type (minus what is already installed); installing one will automatically make the new plugin the default for that mime-type. Option 4) is only displayed if there are more results available. This is done by querying the plugin finder xml webservice. Use-Case: support 3rd party install methods ========================================================================= Vendors (like linux distributions) will have the ability to plug-in their own install methods and supplement the results of the plugin finder service with the results in their own database. For example, Ubuntu wants to provide a way to install plugins shipped in their archive by ".deb". From a user-experience perspective this will be completely transparent. An icon next to the result entry will indicate which vendor signed-off that package/plugin. Most distributions will want to keep the default provided by mozilla.com pfs preselected. The benefits the user gets are obviously: choice, competition and the ability to choose a plugin according to his personal preference.
I like this idea, but I don't think we want to expose mime types directly to the user if we can avoid it. For example, most users aren't going to realize that application/ogg is a video/audio container. So, perhaps as part of this we'll need a mapping of "common" mime types to something that users will recognize. That's my two cents at the moment, anyway.
(In reply to comment #8) > I like this idea, but I don't think we want to expose mime types directly to > the user if we can avoid it. For example, most users aren't going to realize > that application/ogg is a video/audio container. So, perhaps as part of this > we'll need a mapping of "common" mime types to something that users will > recognize. On linux in the "Preferences -> Application" panel the left hand side (mime-type) has a user-readable name, e.g. MPEG Video OGG Audio etc. arent those good enough?
Created attachment 350097 [details] PoC screen for a standalone plugin switcher/manager you can switch back and forth if you have multiple plugins installed or you can "Search ..." for other alternatives. As suggested above, this feature should (also) be integrated into the Preferences -> Applications panel.
Created attachment 350098 [details] [diff] [review] plugin for mime-type pref backend patch from ubuntu xulrunner (1.9). Backend code that allows to select a specific plugin when multiple plugins are installed that claim to support a given mime-type.
This is a mass change. Every comment has "assigned-to-new" in it. I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Bug 836415 has now removed the Plugin Finder Service (PFS) from Firefox. As a result, I'm closing all the remaining PFS bugs. If you're getting this bugmail for an ancient PFS bug, the basic summary of the world today is: * NPAPI plugins are a dying technology * PFS was already restricted to assisting with only the 4 most common plugins * Sites commonly provide their own UI for install a required plugin * Mozilla is generally focusing on improving the web platform so that proprietary plugins are not required. (Note that "plugins" are a completely separate from "browser extensions", such at those found on addons.mozilla.org. The latter are not going anywhere, and are not impacted by the removal of PFS.)