449188 - improve plugin finder service

Status: RESOLVED WONTFIX

Description

[Alexander Sack]

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.

Comment 1

[Zibi Braniecki [:gandalf][:zibi]]

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

Comment 2

[Arzhel Younsi [:XioNoX]]

Created attachment 332331 [details] [diff] [review]
A PoC for improving the plugin finder service

Comment 3

[Arzhel Younsi [:XioNoX]]

Created attachment 332333 [details]
Overview screenshot

Comment 4

[Dave Townsend [:mossop]]

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

Comment 5

[Arzhel Younsi [:XioNoX]]

Created attachment 332334 [details]
Same dialog through Tools menu

Comment 6

[Zibi Braniecki [:gandalf][:zibi]]

Dave: We're writing those.

I understand your concern, we'll try to shape out the plan and then get review from stakeholders.

Comment 7

[Alexander Sack]

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.

Comment 8

[cmtalbert]

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

[Alexander Sack]

(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?

Comment 10

[Alexander Sack]

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.

Comment 11

[Alexander Sack]

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.

Comment 12

[Michael Kohler [:mkohler]]

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.

Comment 13

[Justin Dolske [:Dolske]]

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.)