If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

improve plugin finder service



Toolkit Graveyard
Plugin Finder Service
9 years ago
3 years ago


(Reporter: Alexander Sack, Unassigned)




(2 attachments, 3 obsolete attachments)



9 years ago
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.


9 years ago
Severity: normal → enhancement
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
Severity: enhancement → normal
Summary: improve plugin finder service for 1.9.1 → improve plugin finder service
Created attachment 332331 [details] [diff] [review]
A PoC for improving the plugin finder service


9 years ago
Assignee: nobody → xionox


9 years ago


9 years ago
Created attachment 332333 [details]
Overview screenshot
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
Created attachment 332334 [details]
Same dialog through Tools menu
Dave: We're writing those.

I understand your concern, we'll try to shape out the plan and then get review from stakeholders.
Attachment #332333 - Attachment is obsolete: true

Comment 7

9 years ago
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 
  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.
Version: unspecified → Trunk

Comment 8

9 years ago
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.

Comment 9

9 years ago
(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

arent those good enough?

Comment 10

9 years ago
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.
Attachment #332331 - Attachment is obsolete: true
Attachment #332334 - Attachment is obsolete: true


9 years ago
Attachment #350097 - Attachment is patch: false
Attachment #350097 - Attachment mime type: text/plain → image/png

Comment 11

9 years ago
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.
Assignee: ayounsi → nobody
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.)
Last Resolved: 3 years ago
Resolution: --- → WONTFIX


3 years ago
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.