Last Comment Bug 339056 - provide mechanism to allow users to list, enable, disable plugins in primary UI
: provide mechanism to allow users to list, enable, disable plugins in primary UI
Status: VERIFIED FIXED
[sg:want P3]
:
Product: Toolkit
Classification: Components
Component: Add-ons Manager (show other bugs)
: Trunk
: All All
: P1 enhancement with 8 votes (vote)
: mozilla1.9alpha8
Assigned To: Michael Wu [:mwu]
:
:
Mentors:
: 338672 353510 356461 372359 385372 404960 (view as bug list)
Depends on: 382367 420280
Blocks: 275668 344638 356458 391625 391730 391820
  Show dependency treegraph
 
Reported: 2006-05-23 22:27 PDT by Mike Beltzner [:beltzner, not reading bugmail]
Modified: 2010-08-09 17:02 PDT (History)
52 users (show)
mconnor: blocking1.9+
dveditz: wanted1.8.1.x-
stephen.donner: in‑litmus+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screenshot of plugins list (56.81 KB, image/png)
2007-06-28 18:29 PDT, Michael Wu [:mwu]
no flags Details
List plugins in addons manager, v1 (10.83 KB, patch)
2007-06-29 15:27 PDT, Michael Wu [:mwu]
no flags Details | Diff | Splinter Review
List plugins in addons manager, v2 (11.21 KB, patch)
2007-07-19 12:06 PDT, Michael Wu [:mwu]
robert.strong.bugs: review+
Details | Diff | Splinter Review
As checked in (11.08 KB, patch)
2007-08-09 19:50 PDT, Michael Wu [:mwu]
no flags Details | Diff | Splinter Review
Screen shot (77.87 KB, image/jpeg)
2007-08-09 20:59 PDT, pal-moz
no flags Details

Description Mike Beltzner [:beltzner, not reading bugmail] 2006-05-23 22:27:27 PDT
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] 2006-05-23 22:29:39 PDT
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 2006-05-24 01:49:41 PDT
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 2006-07-25 11:28:58 PDT
*** Bug 338672 has been marked as a duplicate of this bug. ***
Comment 4 Alfred Kayser 2006-08-01 22:28:02 PDT
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 [:rstrong] (use needinfo to contact me) 2006-08-07 19:18:13 PDT
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] 2006-09-20 10:39:09 PDT
(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 [:rstrong] (use needinfo to contact me) 2006-09-20 12:09:36 PDT
(In reply to comment #6)
See Bug 330511
Comment 8 Adam Guthrie 2006-09-20 12:22:14 PDT
*** Bug 353510 has been marked as a duplicate of this bug. ***
Comment 9 Ed Avis 2006-10-16 06:49:42 PDT
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 2006-10-16 09:03:37 PDT
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 11 Jo Hermans 2007-03-02 02:18:29 PST
*** Bug 372359 has been marked as a duplicate of this bug. ***
Comment 12 Thomas Schumm 2007-05-14 12:44:51 PDT
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 13 Michael Wu [:mwu] 2007-06-21 14:32:07 PDT
*** Bug 385372 has been marked as a duplicate of this bug. ***
Comment 14 Michael Wu [:mwu] 2007-06-28 18:29:03 PDT
Created attachment 270263 [details]
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] 2007-06-29 02:07:49 PDT
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] 2007-06-29 15:27:22 PDT
Created attachment 270380 [details] [diff] [review]
List plugins in addons manager, v1
Comment 17 Robert Strong [:rstrong] (use needinfo to contact me) 2007-07-02 20:43:29 PDT
Comment on attachment 270380 [details] [diff] [review]
List plugins in addons manager, v1

clearing review per discussion with mwu
Comment 18 Michael Wu [:mwu] 2007-07-19 12:06:09 PDT
Created attachment 273003 [details] [diff] [review]
List plugins in addons manager, v2

This version eliminates html tags where possible and also reports blocklisting.
Comment 19 Dave Townsend [:mossop] 2007-07-22 10:56:12 PDT
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 2007-07-22 17:05:10 PDT
(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] 2007-07-23 03:14:28 PDT
(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] 2007-07-26 08:37:10 PDT
Missing the freeze, moving out.
Comment 23 Alfred Kayser 2007-08-08 10:36:53 PDT
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 [:rstrong] (use needinfo to contact me) 2007-08-09 13:26:25 PDT
Please file followup bugs for the remaining issues you and I have talked about. Thanks
Comment 25 Michael Wu [:mwu] 2007-08-09 19:48:25 PDT
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] 2007-08-09 19:50:26 PDT
Created attachment 276069 [details] [diff] [review]
As checked in
Comment 27 pal-moz 2007-08-09 20:59:55 PDT
Created attachment 276077 [details]
Screen shot

plugins are listed many times.
intended or bug?
Comment 28 Robert Strong [:rstrong] (use needinfo to contact me) 2007-08-09 21:05:38 PDT
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 2007-08-10 02:53:22 PDT
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] 2007-08-10 03:18:50 PDT
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 2007-08-11 08:28:49 PDT
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] 2007-08-11 10:18:49 PDT
please see https://bugzilla.mozilla.org/show_bug.cgi?id=391820#c6
Comment 33 pd 2007-08-13 07:54:10 PDT
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 [:rstrong] (use needinfo to contact me) 2007-08-13 12:58:24 PDT
Filed bug 392084 for the request in comment #33.

If yu find bugs please file new bugs and make them block bug 391730
Comment 35 Robert Strong [:rstrong] (use needinfo to contact me) 2007-08-18 21:47:33 PDT
*** Bug 356461 has been marked as a duplicate of this bug. ***
Comment 36 Tony Chung [:tchung] 2007-09-06 15:32:26 PDT
marked the wrong flag.  should be in-litmus?
Comment 37 Stephen Donner [:stephend] 2007-09-06 17:20:18 PDT
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] 2007-10-05 15:46:16 PDT
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 39 Dave Townsend [:mossop] 2007-11-22 04:49:46 PST
*** Bug 404960 has been marked as a duplicate of this bug. ***
Comment 40 S. Ali Tokmen 2007-11-22 05:05:27 PST
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/

Note You need to log in before you can comment on or make changes to this bug.