339056 - provide mechanism to allow users to list, enable, disable plugins in primary UI

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, enhancement, P1)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

This might actually belong in the Extension/Theme Manager component, but I'm not sure that's the design we want. Here's the problem statement:

Firefox users browse the web with 1..n plugins installed, yet there's no primary UI mechanism for them to see details (version, date of install, vendor) of those plugins, nor for them to enable/disable them should they want to. The about:plugins function is a flat listing (not very interesting for the type of task that a user wants) and the old SeaMonkey plugin prefs UI is a little too heavyweight.

What we want is a UI, perhaps in the EM/TM style, which allows users to:

  - list
  - configure (if that's possible/relevant)
  - enable
  - disable
  - uninstall (if that's possible/relevant)

Related: bug 19118 (Plugin Manager design, looks kinda heavyweight to me), and bug 277677 (add nsICategoryManager for plugins)

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

BTW, I'm not totally convinced that there's a significant use-case here, although plugin problems (specifically Adobe Acrobat) have been at the core of a lot of performance issues, and it's a vector for spyware, so it might be worth considering some primary UI that lets us have a better story for protecting a user from their own installed software. Dunno if we can actually *do* the enable/disable/uninstall thing, though.

Comment 2

[Jo Hermans]

about:plugins is not accessible in the GUI on purpose, see bug 184178 and bug 269118.

But now that we have an 'Add-Ons' entry in the Tools menu for extensions, themes and search-engines, maybe we can add plug-ins too ? It's already difficult enough to tell people what the difference is between a plug-in and an extension. As you remarked, this GUI would be much easier to use that the current flat listing.

Comment 3

[Brian Polidoro]

*** Bug 338672 has been marked as a duplicate of this bug. ***

Comment 4

[Alfred Kayser]

This bug should have been dup'ed to bug 338672, as that one is older than this one. Also the title of bug of 338672 is more clear on its purpose.

Comment 5

[Robert Strong (they/them - no direct email)]

In regards to uninstall it is only appropriate for us to uninstall plug-ins we have installed as in Extension Manager managed plugins. For the others providing a mechanism for enable / disable should be sufficient though we *may* want to provide uninstall for plugins that install themselves into our appdir/plugins directory.

Comment 6

[Pavel Cvrcek [:JasnaPaka]]

(In reply to comment #0)
>   - list
>   - configure (if that's possible/relevant)
>   - enable
>   - disable
>   - uninstall (if that's possible/relevant)

And what a notification if some plugin is outdated (security bug etc.)? Some like http://wiki.mozilla.org/Extension_Blocklisting. Just a idea.

Comment 7

[Robert Strong (they/them - no direct email)]

(In reply to comment #6)
See Bug 330511

Comment 8

[Adam Guthrie]

*** Bug 353510 has been marked as a duplicate of this bug. ***

Comment 9

[Ed Avis]

At the moment Firefox can automatically install plugins but not remove them.  This ought to be considered a security risk.  If $random_plugin turns out to be exploitable, there is no way for a user to remove it from their Firefox installation.

Comment 10

[Jesse Ruderman]

Good point.  Giving power users a discoverable way to disable a plugin (if they read on Slashdot that a plugin is vulnerable) would improve their security, so I'm adding "[sg:want P3]" to the status whiteboard.  Bug 271559 is even more important for security, though, because it would protect many more users most of the time.

Comment 12

[Thomas Schumm]

Another problem is simply having the user's desires obeyed.  Often, some piece of malware like Quicktime or Acrobat installs a browser plugin behind the user's back.  All of a sudden, the browser is opening mp3 files and videos in an embedded plugin that never works instead of being played in the external player they prefer.  The user is left doubly confused because they look at their helper application settings which are being simply ignored.  Even if the user identifies the plugin interloper, there's no way to disable or remove the plugin, and even if they figure out how to hatchet it out by hand, there's no way to prevent it from being installed behind their back again in the future.

Comment 14

[Michael Wu [:mwu]]

Attachment: Screenshot of plugins list

Well, this is basically what it looks like. Not too fond of the puzzle piece icon on the left.. I guess we'll need to get small plugin icons.

Comment 15

[Dave Townsend [:mossop]]

Looking good. Can we turn those urls in the description into the home page link somehow? Doesn't look like they all follow hte same form so might be tough.

Comment 16

[Michael Wu [:mwu]]

Attachment: List plugins in addons manager, v1

Comment 17

[Robert Strong (they/them - no direct email)]

Comment on attachment 270380 [details] [diff] [review]
List plugins in addons manager, v1

clearing review per discussion with mwu

Comment 18

[Michael Wu [:mwu]]

Attachment: List plugins in addons manager, v2

This version eliminates html tags where possible and also reports blocklisting.

Comment 19

[Dave Townsend [:mossop]]

I wonder if Extensions and Plugins are names that are too similar for a user to be able to distinguish which pane to go to for what. Would it be worth thinking about merging the two lists into Extensions (probably horrendous for the implementation), or simply renaming one or both, maybe "Content Viewers" for plugins, or are we too stuck with the current naming?

Comment 20

[Hermann Schwab]

(In reply to comment #19)
> I wonder if Extensions and Plugins are names that are too similar for a user to
> be able to distinguish which pane to go to for what. Would it be worth thinking
> about merging the two lists into Extensions (probably horrendous for the
> implementation), or simply renaming one or both, maybe "Content Viewers" for
> plugins, or are we too stuck with the current naming?

Plugins are external program parts "plugged in" with a proprietary interface, and extensions are external program parts "plugged in" with some other proprietary interface, and themes are external UI data "plugged in" with another proprietary interface.

Plugins are working on many browsers, Extensions don't even work on different Firefoxes.

Joe Sixpack is calling both plugins and extensions simply 'plugin', Jane Sixpack is calling both plugins and extensions simply 'extension', neither will recognize ""Content Viewers" at first glance. 
Yet another UI Change? There are lots of people not updating because they don't  want run a changing system.

Comment 21

[Dave Townsend [:mossop]]

(In reply to comment #20)
> Joe Sixpack is calling both plugins and extensions simply 'plugin', Jane
> Sixpack is calling both plugins and extensions simply 'extension', neither will
> recognize ""Content Viewers" at first glance. 
> Yet another UI Change? There are lots of people not updating because they don't
>  want run a changing system.

Yes this is my fear also. Madhava, do you have any thoughts?

Comment 22

[Mike Connor [:mconnor]]

Missing the freeze, moving out.

Comment 23

[Alfred Kayser]

Right now the plugins are hidden in 'about:plugins', so the move to the 'Addons' window is still a good step.
Regarding: Extensions, Themes and Plugins: for Joe and Jane these will always be confusing, but as long as we stick to these consistenty (and provide a right description for each) (may be below the panel selector above the list a one-liner like:
'Extensions are addons that extend firefox functionality'
'Themes are addons that provide a new look&feel'
'Plugins are addons that enable other types of content to be displayed in the page'

Comment 24

[Robert Strong (they/them - no direct email)]

Please file followup bugs for the remaining issues you and I have talked about. Thanks

Comment 25

[Michael Wu [:mwu]]

Checking in toolkit/mozapps/extensions/content/extensions.js;
/cvsroot/mozilla/toolkit/mozapps/extensions/content/extensions.js,v  <--  extensions.js
new revision: 1.132; previous revision: 1.131
done

Comment 26

[Michael Wu [:mwu]]

Attachment: As checked in

Comment 27

[pal-moz]

Attachment: Screen shot

plugins are listed many times.
intended or bug?

Comment 28

[Robert Strong (they/them - no direct email)]

Some plugin vendors provide multiple plugins for what the user thinks of as a single plugin. Not sure what if anything we can do about this except to possibly special case certain plugins... possible ways to handle this will definitely be discussed.

Comment 29

[Timwi]

I think the best way to handle this would be to display a piece of information right there in the list which distinguishes the plugins. The handled MIME type perhaps?

Alternatively you could just display only one list item for each unique plugin name; in other words, collapse several plugins with the same name into one list item. Then you could have a checkbox underneath the list labeled "Display plugins with the same name separately" which turns it back into the list we have now.

I think I would most prefer to have both :)

Comment 30

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

maybe to distinguish you could add plugin file name near plugin name like:

Java(TM) Platform SE 6 U2 (npjava14.dll)
Java Plug-in 1.6.0_02 for Netscape Navigator (DLL Helper)

Also some way to view mime-types / extensions served would be great, maybe in secondary UI (context menu)

Comment 31

[Thomas Schade]

As the Extension Manager has stopped working completely in Thunderbird trunk, see bug https://bugzilla.mozilla.org/show_bug.cgi?id=391820, might this be related to this bug here?

Comment 32

[Joe Sabash [:JoeS1]]

please see https://bugzilla.mozilla.org/show_bug.cgi?id=391820#c6

Comment 33

[pd]

There is a consistency issue where the Plugins 'tab' is missing a "Get Plugins" link at the bottom centre of the UI. Both the Extensions and Themes 'tabs' have this link.

Comment 34

[Robert Strong (they/them - no direct email)]

Filed bug 392084 for the request in comment #33.

If yu find bugs please file new bugs and make them block bug 391730

Comment 36

[Tony Chung [:tchung]]

marked the wrong flag.  should be in-litmus?

Comment 37

[Stephen Donner [:stephend] Not actively reading bugmail]

There are six specific testcases for the Plugins tab under http://litmus.mozilla.org/show_test.cgi?searchType=by_category&product_id=1&branch_id=15&testgroup_id=56&subgroup_id=793, prefixed with "Plugins tab:", and there are also shared test cases that cover the home pages, context menus, and enabling/disabling of extensions/themes/plugins, with the cases for each type broken out in each Litmus testcase).

I might split off the shared one into plugin-specific bugs, but as it stands (with the current UI), we have good coverage.  The UI is pretty straight-forward; let me know if anyone disagrees with the amount/type of tests.

Also, thanks to Tony for writing some good Plugin test cases on my behalf!

in-litmus+

Comment 38

[Tony Chung [:tchung]]

Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X; es-ES; rv:1.9a9pre) Gecko/2007100504 Minefield/3.0a9pre.  New UI and functionality for plugins in EM is present and working.

Comment 40

[S. Ali Tokmen]

I'm the one who wrote up the duplicate https://bugzilla.mozilla.org/show_bug.cgi?id=404960 and I've just tested the Plug-in Manager in Firefox 3 Beta 1.

I'm just sending you this message to tell that it works as a marvel in Windows 2000 SP4 and Windows XP SP2:

    1. It manages to list all plug-ins
    2. It seems to disable any plug-in without needing to restart Firefox (which is a vvvveeerrryyy nice progress compared to IE's manager)
    3. When disabled, neither Flash, Java or Quicktime seem to be able of re-enabling itself "behind my back" (I didn't try much, thought)
    4. Re-enabling a plug-in works, and exactly as with disabling it doesn't require me to restart Firefox

Thank you for this beautiful piece of work!

S. Ali Tokmen
http://ali.tokmen.com/