Last Comment Bug 19118 - Plug-In Manager (ui for choosing mimetype-plugin associations)
: Plug-In Manager (ui for choosing mimetype-plugin associations)
Status: RESOLVED WONTFIX
:
Product: Firefox
Classification: Client Software
Component: Preferences (show other bugs)
: Trunk
: All All
: -- enhancement with 110 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 32380 57760 64040 66644 95646 96695 106700 115415 115588 119672 128272 129954 140394 143657 144372 146092 152583 162094 162264 164855 169191 172181 173488 173857 175561 178885 180149 180571 181131 198723 206304 207770 210220 210485 212226 212299 221798 227403 227639 233470 262257 275642 277055 286552 290232 326494 328227 342631 343572 414070 417600 436576 443686 457861 462680 475975 (view as bug list)
Depends on: 54940 44973 144263
Blocks: 147866 168889 191546 useragent 90062 104166 169985 grouper 411980
  Show dependency treegraph
 
Reported: 1999-11-17 14:58 PST by mws
Modified: 2015-02-26 08:18 PST (History)
152 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch to use external helper app service (5.57 KB, patch)
2002-02-05 16:16 PST, Peter Lubczynski
no flags Details | Diff | Review
slight change (5.60 KB, patch)
2002-02-05 16:24 PST, Peter Lubczynski
no flags Details | Diff | Review
Skeleton implementation of pref GUI to plugin module connection (15.49 KB, patch)
2002-10-24 18:11 PDT, av (gone)
no flags Details | Diff | Review
xul template for prefs ui (13.33 KB, patch)
2002-11-01 18:36 PST, serge (gone)
no flags Details | Diff | Review
main prefs screen shot (example) (15.94 KB, image/png)
2002-11-04 12:40 PST, serge (gone)
no flags Details
proposal patch (74.24 KB, patch)
2004-01-19 22:50 PST, Robin Lu
no flags Details | Diff | Review
screenshot (15.15 KB, image/png)
2004-01-19 23:51 PST, Robin Lu
no flags Details
proposal patch 2 (55.48 KB, patch)
2004-02-24 02:09 PST, Robin Lu
no flags Details | Diff | Review
GIF Image of SeaMonkey Download Preferences (24.02 KB, image/gif)
2006-06-26 15:43 PDT, James B. Higgs
no flags Details

Description mws 1999-11-17 14:58:26 PST
I would really like a plug-in manager for my browser that allows me to choose
which mime types are controlled by which plug-ins.
In the browser preferences window there should be a plug-in manager with all
available mime types listed. Under each mime type there should be a list of
installed plug-ins that can handle that mime type.  Radio buttons can be used to
select the plug-in the user prefers for that mime type.

For example

 audio/midi
    O LiveAudio
    O LiveUpdate Crescendo version 4.02
    O QuickTime Plug-in 4.0.3
 audio/aiff
    O LiveAudio
    O QuickTime Plug-in 4.0.3
Comment 1 Eli Goldberg 1999-12-08 09:27:59 PST
Shrirang is now QA owner for Plug-ins; QA assigning all of my Plug-ins bugs over
to him.
Comment 2 ekrock's old account (dead) 2000-05-05 19:33:05 PDT
<tough_decision>This is a nice idea for a "nice to have" enhancement. However,
we did not have this functionality in Nav4, and Netscape is now out of time for
making new enhancements beyond Nav4 functionality for FCS. Therefore,
reassigning to nobody@mozilla.org, marking helpwanted, and setting milestone to
FUTURE.</tough_decision>
Comment 3 Peter ``jag'' Annema 2000-05-06 08:04:44 PDT
*** Bug 32380 has been marked as a duplicate of this bug. ***
Comment 4 Braden 2000-11-16 09:27:21 PST
*** Bug 57760 has been marked as a duplicate of this bug. ***
Comment 5 Peter Lubczynski 2000-11-22 11:40:20 PST
Could about:plugins be re-written to do this?
Comment 6 Braden 2000-11-22 13:23:03 PST
Probably. But unless there are plans in the works to move the rest of the
preferences into the browser window, that would be awfully inconsistent.

In general, I don't think putting preferences in the browser window is a good
idea. Too much modality. But in any event, the UI associated with this RFE
belongs with that for the rest of the browser preferences.
Comment 7 Peter Lubczynski 2001-02-08 08:47:13 PST
*** Bug 64040 has been marked as a duplicate of this bug. ***
Comment 8 J Luh 2001-02-21 14:54:34 PST
Re: the above comment regarding the absence of this functionality in Nav4: On
the Mac, at least, Nav4 did allow you choose which mime types were controlled by
which plug-ins, which is what this bug appears to address. For example, if you
had both the LiveAudio plug-in and the QuickTime plug-in installed, you could
set in Preferences which of the plug-ins handled the audio/wav MIME type. You
could also tell Mozilla to bypass the plug-ins and simply save wav files to disk.
Comment 9 Peter Lubczynski 2001-03-28 16:36:55 PST
Mozilla already has a internal plugin manager. It would be nice to develop some 
UI to get to some of the interface methods.
Comment 10 basic 2001-06-21 12:23:30 PDT
If about:plugin is used, it would seem that there is yet another mime type
related pref. Couldn't ALL mime type related pref be put in one place? Namely
"Helper Apps" ?
Comment 11 basic 2001-06-21 12:24:16 PDT
spam: adding self to cc
Comment 12 timeless 2001-06-21 15:03:18 PDT
helper apps is a fixed sized panel in a fixed sized dialog that is app modal.

about:plugins is a flexible page inside a flexible window that is not app 
modal.

I would much prefer the page view over the dialog view.  You get flat 
information which you can easily jump around instead of relying on nested 
dialogs.
Comment 13 Daniel Veditz [:dveditz] 2001-08-03 12:07:28 PDT
We really need this. Right now I appear to have a choice between uninstalling
QuickTime to let the browser render .png, or accepting the launch of heavyweight
QuickTime each time I encounter a .png link.

What I'd like, actually, is to be able to turn off specific plugins until I want
them, without having to move .dll's in and out of the plugin directory and
typing "javascript:navigator.plugins.refresh(true)" in the URL bar. There are
now far too many Flash ads for me to leave that one enabled for the few times I
encounter flash content I do want to see.

I'm CC'ing law because this is kinda related to helper apps too, or at least the
big picture should be kept in mind if the UI in this area gets reworked.
Comment 14 Christopher Aillon (sabbatical, not receiving bugmail) 2001-08-16 17:39:19 PDT
*** Bug 95646 has been marked as a duplicate of this bug. ***
Comment 15 Matthias Buecher 2001-08-23 16:51:45 PDT
This would be very very useful
Comment 16 Matthew Paul Thomas 2001-08-26 05:22:03 PDT
*** Bug 66644 has been marked as a duplicate of this bug. ***
Comment 17 Gilles Durys 2001-09-03 01:37:11 PDT
*** Bug 96695 has been marked as a duplicate of this bug. ***
Comment 18 Peter Lubczynski 2001-09-20 16:26:15 PDT
nobody is working on this :)
Comment 19 Jesse Ruderman 2001-09-20 16:26:39 PDT
These four bugs are related:

bug 11875 stopping animations with Esc should also stop applet animations
bug 19118 Plug-In Manager (ui for choosing mimetype-plugin associations)
bug 24418 Allow user to turn on and off rendering of video/audio 
bug 94035 Allow blocking of any media type by site
Comment 20 R.K.Aa. 2001-09-20 23:04:10 PDT
bug 61103 [RFE] Add a preference to disable dialogs for loading plugins
Comment 21 sairuh (rarely reading bugmail) 2001-09-27 12:16:55 PDT
see also bug 54940: define list for helper applications. that would nicely
complement this feature as well.
Comment 22 Gavin Jackson 2001-10-19 06:12:32 PDT
This is a great idea, but normal browser users(non techies) wouldnt know what a
mime type or dll is. A list of plugin names should show and the mime type and
file location should be in a property dialog.
Comment 23 Boris Zbarsky [:bz] (Out June 25-July 6) 2001-10-26 00:48:48 PDT
*** Bug 106700 has been marked as a duplicate of this bug. ***
Comment 24 R.K.Aa. 2001-12-15 07:49:35 PST
*** Bug 115415 has been marked as a duplicate of this bug. ***
Comment 25 Dimitrios 2001-12-17 04:32:43 PST
*** Bug 115588 has been marked as a duplicate of this bug. ***
Comment 26 SineSwiper 2002-01-02 07:59:54 PST
Voting for this bug.  Keep up the good work...hold on, nobody's working on this
bug.  Get your lazy butts in gear! :)
Comment 27 Ryoichi Furukawa 2002-01-05 10:36:07 PST
I suggest my scenario for addition plugin manager ui.

step1) define formats for prefs.js

  ex.)
  user_pref("plugins.disable_plugin.Shockwave_Flash", "C:\Program 
Files\Netscape\Program\Plugins\NPSWF32.dll");

  user_pref("plugins.mime_type.application/x-shockwave-flash", "Shockwave_Flash"

Step2) modify nsPluginTag

   Add PRBool attribute "status".
   PR_TRUE is enable, PR_FALSE is disable.
   (default is PR_TRUE)
   
step3) modify nsPluginHostImpl

  Modify nsPluginHostImpl::ScanPluginsDirectory().
  Read prefs and set enable or disable to new status
  when create nsPluginTag instances.(same as java plugin)

  Modify nsPluginHostImpl::IsPluginEnabledForType(),
  IsPluginEnabledForExtension().
  When searching nsPluginTag linked list(mPlugins), check the plugin's status.

  Modify nsPluginHostImpl::FindPluginEnabledForType().
  Read prefs and check the plugin's status.

Step4) define new interface(idl)

    create new idl file(ex. nsIPluginController) and define some methods.
    ex.)
    nsIPluginController {
       enablePlugin( plugin_name, file_name ) ;
       disablePlugin( plugin_name, file_name ) ;
       usePluginForMimeTypes( mime_type, plugin_name ) ;
    }

    and, add this interface to nsPluginHostImpl's super class

    (*)or modify existance idl(ex. nsIPluginManager)

Step5) create UI using new interface

    It can disable(enable) plugin ui,
    and can set using plugin for mime types.
Comment 28 timeless 2002-01-05 19:42:40 PST
i'm relatively opposed to paths in preferences.
Comment 29 Matthias Versen [:Matti] 2002-01-12 09:32:01 PST
*** Bug 119672 has been marked as a duplicate of this bug. ***
Comment 30 Per Olofsson 2002-01-15 08:25:21 PST
I'd like to be able to force Mozilla to display certain mime types using its
internal viewer, and not give me a save dialog or hand it to some plugin.
Actually, it'd be nice to have "View link in Mozilla" in the RMB menu (for those
evil web sites with broken mime types etc), although that thing is already
pretty cluttered.

Maybe this is better off in a separate bug? Sounds like it could fit in a
plug-in manager though.
Comment 31 Peter Lubczynski 2002-02-05 11:42:36 PST
Could mimetypes.rdf be used to hold plugin information? Is there a service for
reading that file?
Comment 32 Brad Garcia 2002-02-05 12:45:37 PST
Man, we REALLY need this feature.

I'm using the Plugger plugin in linux, which is really nice for all the
multimedia stuff.

Unfortunately (for me), the latest version also grabs all pdf, postscript,
and word documents.

I already had helper apps defined for all of these types, and it would appear
to be a BUG when you change the helper app preferences, and then have your
preferences ignored because of some overly-helpful plugin.

Please upgrade severity to "minor" because current behavior causes
"helper applications" configuration to be ignored.
Comment 33 Bill Law 2002-02-05 14:46:42 PST
re: comment 31

We could probably store additional info in mimeTypes.rdf.  We may have to tweak
the code that uses it to ignore the extra info.

It's RDF so you use the RDF interfaces to "read" it.  Note that this is easier
said than done.  I can edit mimeTypes.rdf and see what's there, but I can't
write the RDF code to do it :-).
Comment 34 Peter Lubczynski 2002-02-05 16:16:50 PST
Created attachment 68023 [details] [diff] [review]
patch to use external helper app service

I think the nsIExternalHelperAppService may do the trick as long as I totally
expose some already local public methods.

This patch looks at a user's settings in the pref's helper app dialog. If there
is a mime type or an extension there for a plugin we are about to load, we
abort and do the default. This should give users the ability to override
plugins on a per mime-type or extension basis.

TODO: I think the dialog should be extended and an option added for PLUGIN or
one of the other exisiting contants. Any objections?

nsIMIMEInfo::GetPreferredAction() already returns one of these contants:
138 const long saveToDisk = 0;
139 const long alwaysAsk = 1;
140 const long useHelperApp = 2;
141 const long handleInternally = 3;
142 const long useSystemDefault = 4;

+   const long usePlugin = 5;
Comment 35 Peter Lubczynski 2002-02-05 16:24:46 PST
Created attachment 68025 [details] [diff] [review]
slight change
Comment 36 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-02-05 19:32:52 PST
Unfortunately, at the moment there are only two things that can happen by
"default" (that is once we get to the helper app dialog):

138 const long saveToDisk = 0;
140 const long useHelperApp = 2;

Everything else is treated as saveToDisk.

The patch as it stands _will_ let one override plugins with helpers but in a
totally non-intuitive way.  Or rather, it will not be at all clear to the user
how to undo the overriding.

And of course this approach does nothing to let users pick which of multiple
plugins should handle a type if they all support it.... 
Comment 37 Matthias Versen [:Matti] 2002-02-28 10:48:42 PST
*** Bug 128272 has been marked as a duplicate of this bug. ***
Comment 38 Jesse Ruderman 2002-02-28 16:23:01 PST
Re Per Olofsson's comment 30: 
See bug 57342, Add "View as Text" option for unknown mime content-type.

Peter Lubczynski:
Is "handleInternally" the same as "View as Text"?  If so, bug 57342 might not
need the "arch" keyword.
Comment 39 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-02-28 16:28:48 PST
handleInternally does not work in the current architecture.
Comment 40 wazow 2002-03-08 00:55:10 PST
I vote for this bug. This is really becoming annoying with plugger 4.0. There is
no way currently to configure your browser to handle all websites one would like
to. Plugins simply overlap in their capabilities and you can never get the right
set running when you want.

In my case it means that I have an emulated windows running all the time and
switch to IE (yuck) occasionally. Well I guess nobady wants to consider IE as an
extension to mozilla...

I also think it should be upgraded to minor.
Comment 41 R.K.Aa. 2002-03-10 10:34:43 PST
*** Bug 129954 has been marked as a duplicate of this bug. ***
Comment 42 Brad Garcia 2002-03-21 05:37:43 PST
I've found a workaround for plugger 4.0:

 1. Edit /etc/pluggerrc-4.0, and remove or comment out all of the entries
    for files that you wish to be handled by something other than plugger.
 2. Delete ~/.mozilla/appreg
 3. If you have a ~/.netscape directory, rename it temporarily,
    mv ~/.netscape ~/foo
 4. Run mozilla, then exit
 5. mv ~/foo ~/.netscape

If you don't do step 3, then mozilla threatens to create a profile based
on your netscape profile in step 4.

It would be nice if appreg were changed so that:

1. plugin data is recomputed each time Mozilla is started, instead of being
   read from appreg.
2. The non-existence of a profile in .mozilla, rather than the existence of
   .netscape, was used to determine when to copy over a netscape 4 profile
   when appreg doesn't exist.
Comment 43 Braden 2002-04-01 12:24:18 PST
Folks: Bug 44973 was filed in an attempt to separate the required functionality
from the UI issues. Importantly, there are issues with having multiple plug-ins
for a given media type that are not being addressed in the discussion of this
bug. For instance, if I have multiple plug-ins for a media type, should a page
author be able to control which one is used? Before you answer, consider that
the page author might be using features only available in a particular vendor's
plug-in. Also note that IE allows this. If you're interested in discussing this,
I'd suggest taking it to bug 44973.

(Note that the discussion in bug 44973 is a bit stale; it occurred at a time
when URNs were being considered for use as contractIDs. In general, replace
occurrences of "URN" in that discussion with "contractID" and ignore text
specific to URN issues.)
Comment 44 Ian Pottinger 2002-04-03 22:28:57 PST
adding self to cc list
Comment 45 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-04-26 14:23:56 PDT
*** Bug 140394 has been marked as a duplicate of this bug. ***
Comment 46 Simon Spiegel 2002-05-13 14:08:46 PDT
Am I dreaming or what? Could you at least explain why this bug is a WONTFIX? IMO
this would be an extremely useful feature.
Comment 47 Simon Spiegel 2002-05-13 14:12:39 PDT
Sorry, sorry, big sorry. My fault. Didn't realize that this wasn't this bug, but
a dependig one. Really sorry.
Comment 48 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-05-14 08:43:37 PDT
*** Bug 144372 has been marked as a duplicate of this bug. ***
Comment 49 R.K.Aa. 2002-05-21 22:55:55 PDT
*** Bug 146092 has been marked as a duplicate of this bug. ***
Comment 50 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-06-19 01:01:49 PDT
*** Bug 152583 has been marked as a duplicate of this bug. ***
Comment 51 Peter Lubczynski 2002-06-19 16:36:14 PDT
*** Bug 152583 has been marked as a duplicate of this bug. ***
Comment 52 rubydoo123 2002-07-09 16:55:10 PDT
setting to PL2:P1
Comment 53 Daniel Veditz [:dveditz] 2002-07-09 18:10:42 PDT
Why is this "critical"? It may be important to you (although you only gave it a
P2) but it still sounds like an enhancement.
http://bugzilla.mozilla.org/bug_status.html#severity

mozilla1.1alpha has shipped already, so that's not such a good target, either.
Comment 54 rubydoo123 2002-07-09 18:12:58 PDT
because that is how we are prioritizing the bug
Comment 55 Brad Garcia 2002-07-10 03:07:56 PDT
dveditz, I think this is more than just an "enhancement".

Quoting from comment 32:

"I already had helper apps defined for all of these types, and it would appear
to be a BUG when you change the helper app preferences, and then have your
preferences ignored because of some overly-helpful plugin."

I see no reason why a plugin should have priority over a user-defined helper
application.  I think it would be more correct to have the helper override
the plugin, and the best solution would be to let the user choose from all
posibilities (since there could be several plugins defined to handle a single
mimetype).
Comment 56 timeless 2002-07-10 04:17:39 PDT
if you want to prioritize your bugs, please use the priority field.

this is *NEW* code, as such it's an *ENHANCEMENT* the fact that people want the
code does not change the fact that it is *NEW* code and therefore an
*ENHANCEMENT* to the product.

We do *NOT* need quotes reminding us that a bug needs to be fixed. However
people *should* be aware of definitions. dveditz is correct. changing severity
to enhancement.
Comment 57 Asa Dotzler [:asa] 2002-07-11 12:33:23 PDT
Critical is reserved for critical problems like crashes, loss of data, severe
memory leak. Severity is an impact field, not a priority field. We all share
this database and need to work to preserve shared meaning of as many fields as
possible. Severity, Target Milestone and Summary must stay meaningful to the
larger audience. We cannot afford to corrupt the meaning of those fields for
tracking different issues. If the Priority field doesn't work for you or your
team then I suggest you develop a set of labels for the status whitboard but
co-opting a field which is supposed to be meaningful to everyone in order to
express something different to just a few is a serious degredation of our shared
tool. 
Comment 58 John Villalovos 2002-07-12 14:08:27 PDT
Also it would be nice if you could specify that you DON'T want any plugin to
handle a mime-type.  So if this feature is ever done it would be nice to have a
None option.
Comment 59 Kai Lahmann (is there, where MNG is) 2002-08-10 18:41:28 PDT
*** Bug 162094 has been marked as a duplicate of this bug. ***
Comment 60 TGOS 2002-08-18 10:55:13 PDT
I'm also for the NONE entry, that allows to disable a plugin. It often is very
annoying that one can't disable Flash like one can disable Java. Also disabling
RealPlayer plugin is helpful in some cases. Right now one has to remove the
plugin of the plugin directory and restart Mozilla; but in case of some plugins
that doesn't work anymore, as Mozilla finds them even if not in the plugin
directory (I never copied the Acrobat reader plugin there and still Mozilla
shows PDF files correctly; meanwhile I found out that I also don't have to copy
the Java plugin any longer, Mozilla pulls all information it needs out of the
registry in Windows).

The question whether there should be an overall setting or a per-page setting...
does a per page setting really makes much sense? While it might be sometimes
helpful for some hardcore users, I generall think it's not. Mozilla can block
pictures by server, but whatfor is this really used? It is used to block
advertising banners by 90% of all users.

The image tag IMG is actually oudated according to W3C, as there is now the
OBJECT tag and images are objects as well. You can embed images into a page
using object tag, that works quite well (or should work quite well). So maybe
one should simply alter the current image blocker to become an object blocker.
If you block "objects" of a page, all OBJECT tags, all IMG tags, all APPLET tags
and even all EMBED (even though non official HTML tag anyway) are not loaded
(only a placeholder or empty space is shown). That way user could finally block
all banners (also Applet and Flash banners that keep annoying me), as long as
they are loaded from a different server of course. Such a blocking should not
work on MIME level, but on HTML parsing level, where these tags are noted, but
not handled as they usually would be handled (just placeholders or empty space
is put there instead of reallying accessing the *object*). This may be a
different bug (enhancement).

But setting the MIME associations for each separate page seems to be overkill to
me and hardly ever pays off. Setting MIME associations once for ever *user*
seems enough. If you want to have different settings, create multiple user
profiles and start the browser with whatever profile you currently need. MIME
associations should decide which plugin to use once the HTML parsers (or some
intermediate layer) has decided to actually load this *object* _at all_.

So I agree with the reporter, just that I want to update his little GUI suggestion:

 audio/midi
    O None
    O LiveAudio
    O LiveUpdate Crescendo version 4.02
    O QuickTime Plug-in 4.0.3
 audio/aiff
    O None
    O LiveAudio
    O QuickTime Plug-in 4.0.3
Comment 61 Peter Lubczynski 2002-08-19 13:18:54 PDT
*** Bug 143657 has been marked as a duplicate of this bug. ***
Comment 62 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-08-27 06:49:49 PDT
*** Bug 164855 has been marked as a duplicate of this bug. ***
Comment 63 Marek Z. Jeziorek 2002-09-13 09:57:56 PDT
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Comment 64 rubydoo123 2002-09-17 15:01:33 PDT
*** Bug 169191 has been marked as a duplicate of this bug. ***
Comment 65 Ajay Gautam 2002-09-24 10:01:09 PDT
Advertisers are catching up :( They are getting more and more smarter.

I see much more flash based ads these days than a few months back. Simple "Block
Images from this site" is not very effective anymore!

We need this functionality more than ever now. In addition, if "Block flash from
this site" could be added, it would be a dream come true.

I would like to take this opportunity to thank the mozilla team for making such
an excellent product, and hope that you guys continue to do so.

Thanks

Ajay Gautam
Comment 66 Joseph 2002-09-25 16:12:46 PDT
An additional idea: in next-gen plugin format, each plugin should have a vendor
string, version string, and name.  This triplet would then uniquely identify any
plugin without regard to path.  If two plugins have the same triplet, then maybe
pop a box to ask the user which to prefer, or just silently choose one, with
maybe a special status-bar warning symbol.

I agree that the mime-types helper app is the best way to go on this.  Maybe we
can have a plugin wrapper (either a formal plugin or an internal "plugin" class)
that then calls helper apps appropriately?  Then, the mime-types only involve
*one* format.  One should also then internally wrap legacy plugins with special
next-gen plugin classes, so that only one class --the plugin class--is dealt with.
Comment 67 Francois Gouget 2002-09-25 16:49:41 PDT
> An additional idea: in next-gen plugin format, each plugin should have
> a vendor string, version string, and name.  This triplet would then
> uniquely identify any plugin without regard to path.

Who uses the plugin path to identify the plugin? I'm not sure using a triplet
instead would be very useful.

However, what would be very useful is a version field accessible from
JavaScript. Then we would avoid the current version checking mess:
 - scripts that parse the Description field to extract the version number...
more or less accurately
 - scripts that assume you don't have Flash 5 capability because they get 6 as
the version number!
   (though I guess that even with a separate field one can make that mistake)

Finally find a way to really discourage the use of the plugin name to determine
whether a plugin is installed/activated: navigator.plugins['Shockwave Flash']...
This systematically fails if you try to use QuickTime as your Flash player for
instance. Maybe that's also an argument against exposing the 'Vendor String'.
Comment 68 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-10-02 14:10:53 PDT
*** Bug 172181 has been marked as a duplicate of this bug. ***
Comment 69 David Dorward 2002-10-02 14:19:24 PDT
In addition to being able to disable a certain plugin, it should be possible to
set some content types to be ignored altogether. This way a prompt to install a
suitable plugin for a content type you never want to access (e.g. midi) will not
be displayed.
Comment 70 Jaime Rodriguez, Jr. 2002-10-07 15:25:23 PDT
Topembed+ as this is required for Gecko 2.0.
Comment 71 Peter Lubczynski 2002-10-07 15:41:53 PDT
--->serge is working on this
Comment 72 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-10-09 18:35:26 PDT
*** Bug 173488 has been marked as a duplicate of this bug. ***
Comment 73 Matthias Versen [:Matti] 2002-10-10 22:33:19 PDT
*** Bug 173857 has been marked as a duplicate of this bug. ***
Comment 74 Alfonso Martinez 2002-10-20 09:35:29 PDT
*** Bug 175561 has been marked as a duplicate of this bug. ***
Comment 75 av (gone) 2002-10-24 18:11:01 PDT
Created attachment 104073 [details] [diff] [review]
Skeleton implementation of pref GUI to plugin module connection

This patch adds 'Plugins...' button to Helper Application page in preferences.
Pressing this button will cause a method of newly created sevice called:
|nsIPluginManagerService::ConfigurePlugins|.

If this basic architectural solution is OK, we can now concentrate on
implementation of everything else inside the plugin module.
Comment 76 av (gone) 2002-10-24 18:19:17 PDT
Couple of files in the previous patch are duplicates by accident, sorry about that.
Comment 77 serge (gone) 2002-11-01 18:36:28 PST
Created attachment 104922 [details] [diff] [review]
xul template for prefs ui

in progress
Comment 78 Alex Bishop 2002-11-02 10:59:45 PST
I thought new files were supposed to be MPL/GPL/LGPL...
Comment 79 Doron Rosenberg (IBM) 2002-11-03 14:42:31 PST
Why overlay the plugin entry in contents.rdf and not simply add it to the
prefs.xul file?
Comment 80 Daniel Veditz [:dveditz] 2002-11-03 18:07:21 PST
Yes, brand new files are supposed to use the MPL tri-license headers,
boilerplate available from http://www.mozilla.org/MPL/
Comment 81 serge (gone) 2002-11-04 12:33:38 PST
thanks for pointing out license header's discrepancy - causes of blind copy &
paste:( and please be notice this is not a final patch and a lot of things
(license header is the first one of course) are subject to change.
Comment 82 serge (gone) 2002-11-04 12:40:16 PST
Created attachment 105109 [details]
main prefs screen shot (example)

Doron: the idea is to place plugin perfs menu entry under privacy&security
tree, something like this screen shot, so I used as an example the
implementation of
http://lxr.mozilla.org/mozilla/source/extensions/wallet/resources/content/walletPrefsOverlay.xul

maybe there is a better solution for such implementation I'm not aware of,
could you explain you question a little bit wider, please? thanks.
Comment 83 Doron Rosenberg (IBM) 2002-11-04 13:11:32 PST
You can add the Plug-ins entry into the tree directly at:
http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/content/preftree.xul

Doing it as an overlay is ugly in this case imho.
Comment 84 rubydoo123 2002-11-07 09:43:21 PST
*** Bug 178885 has been marked as a duplicate of this bug. ***
Comment 85 Ajay Gautam 2002-11-08 10:38:36 PST
Ok, guys, I have had it. Flash ads are getting on my nerves :(

Who is working on this ? Whats the status ? How can I help ?

Thanks
Comment 86 rubydoo123 2002-11-08 11:14:25 PST
We are putting together the design document now and should be working on this in
the near term.

If you want to at least turn pop-up adds off, you can do that in the mozilla
release.
Comment 87 Ajay Gautam 2002-11-08 12:37:00 PST
> We are putting together the design document now and
> should be working on this in the near term.

I would like to join in. What stage are we in the design document? Do we have a
draft ? Can I get it ?

> If you want to at least turn pop-up adds off,
> you can do that in the mozilla release.

Thanks (a zillion) to mozilla, popups are no longer a problem. I have not had
any popus for the past 8 months (I think). Great job :)

Thanks

Ajay Gautam
Comment 88 rubydoo123 2002-11-08 12:43:11 PST
We will post the draft off of the http://www.mozilla.org/projects/plugins
section. We are hoping to get it posted by the end of next week. When it gets
posted -- please, please review it and comment. If you can help with any of the
tasks, we will get you hooked up with the other folks.
Comment 89 av (gone) 2002-11-08 13:33:41 PST
Also, you have a couple of options to get rid of Flash altogether. Just remove
the npswf32.dll from the Plugins folder. If you are on Unix platform, the better
way will be to compile Basic plugin sample from the Plugin SDK and make it
return Flash mime type (renaming the dll too) so it will be started instead of
Flash but do nothing.
Comment 90 rubydoo123 2002-11-14 10:18:32 PST
*** Bug 180149 has been marked as a duplicate of this bug. ***
Comment 91 rubydoo123 2002-11-14 14:11:53 PST
*** Bug 162264 has been marked as a duplicate of this bug. ***
Comment 92 R.K.Aa. 2002-11-17 06:15:01 PST
*** Bug 180571 has been marked as a duplicate of this bug. ***
Comment 93 Matthias Versen [:Matti] 2002-11-20 10:32:21 PST
*** Bug 181131 has been marked as a duplicate of this bug. ***
Comment 94 James Nord 2002-11-25 15:31:48 PST
SPAM: Add CC

***** acrobat plugin ;-)
Comment 95 rubydoo123 2002-12-02 12:53:04 PST
*** Bug 182763 has been marked as a duplicate of this bug. ***
Comment 96 rubydoo123 2002-12-05 14:09:39 PST
moving to 1.4 beta -- plug-in branch work
Comment 97 Justin Kerk 2002-12-27 11:28:18 PST
By the way, Opera already has this feature, and it's one of the few features
that I really miss on moving to Mozilla. Might be useful to look at how they do
it when formulating an implementation.
Comment 98 serge (gone) 2003-01-13 10:24:42 PST
--> peterl
Comment 99 Doron Rosenberg (IBM) 2003-01-13 10:27:19 PST
I can help with UI if need be
Comment 100 Peter Lubczynski 2003-01-22 13:09:28 PST
per topembed+ triage ---> P2:Future
Comment 101 peter m 2003-03-17 17:23:10 PST
I know it's called a "duplicate" problem.  But this one really is a bug, not an
enhancement/feature.

The tendency to pop up ActiveX dialog boxes for missing mime readers is getting
worse.  There are some pages for which I need to close 3 or 4 windows that say
"Could not create the control {000000-00000-00000}. The are becoming so
prevalent, that for some sites the appear for every new page.  I was wondering
if there's a way to do a partial fix, so these errors get logged to an error log
rather than a new window.

Comment 102 Gilles Durys 2003-03-22 06:31:26 PST
*** Bug 198723 has been marked as a duplicate of this bug. ***
Comment 103 SineSwiper 2003-04-22 21:24:29 PDT
There are 61 votes for this bug, 33 bugs have been marked as a duplicate of 
this one, and it blocks 8 other bugs.  As this bug was opened in November of 
1999 (over 3 years ago), this remains to be one of the oldest still-opened bugs 
for Mozilla.  In fact, this is probably one of the oldest bugs still in 
the "NEW" status.

What's the code status of this bug?
Comment 104 Matthias Versen [:Matti] 2003-05-19 14:37:51 PDT
*** Bug 206304 has been marked as a duplicate of this bug. ***
Comment 105 Kai Lahmann (is there, where MNG is) 2003-05-31 09:02:40 PDT
*** Bug 207770 has been marked as a duplicate of this bug. ***
Comment 106 Matthias Versen [:Matti] 2003-06-21 16:34:58 PDT
*** Bug 210220 has been marked as a duplicate of this bug. ***
Comment 107 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-06-26 21:48:27 PDT
*** Bug 210485 has been marked as a duplicate of this bug. ***
Comment 108 Matthias Versen [:Matti] 2003-06-27 06:59:07 PDT
*** Bug 210485 has been marked as a duplicate of this bug. ***
Comment 109 Alfonso Martinez 2003-07-10 07:28:57 PDT
*** Bug 212299 has been marked as a duplicate of this bug. ***
Comment 110 Charles Fenwick 2003-07-17 12:08:02 PDT
*** Bug 212226 has been marked as a duplicate of this bug. ***
Comment 111 Pham 2003-08-07 10:16:53 PDT
firebird nightlies has this now.

Also,what about bug 147309?

Some of the dupes of this is about Mozilla ignoring Adobe. 147309 wants to
respect   that pref but I think this bug wants the user to make the pref in
Mozilla and not in Adobe
Comment 112 Doron Rosenberg (IBM) 2003-08-07 10:51:13 PDT
firebird does not have it, they have something else.  You can't disable flash
with theirs. Also, is it an API that embeddors can use? I doubt it.
Comment 113 Matthias Versen [:Matti] 2003-10-10 08:39:48 PDT
*** Bug 221798 has been marked as a duplicate of this bug. ***
Comment 114 Matthias Versen [:Matti] 2003-12-03 18:14:14 PST
*** Bug 227403 has been marked as a duplicate of this bug. ***
Comment 115 alanjstr 2003-12-21 17:21:55 PST
I just want to be able to disable/enable Flash like I do Java.  Those bugs get
duped against this one, so here I am.
Comment 116 Olli Männistö 2003-12-22 01:03:04 PST
For what it's worth, firebird allows you to disable plugins with UI. Great for
kicking acrobat out of browser. 
Comment 117 alanjstr 2003-12-22 05:23:47 PST
I have Firebird.  Where am I supposed to be looking?  
Comment 118 Christian :Biesinger (don't email me, ping me on IRC) 2003-12-22 05:41:56 PST
no. it doesn't. in-page plugins still work in firebird even if disabled.
(<object>/<embed>)
Comment 119 Doron Rosenberg (IBM) 2003-12-22 08:29:26 PST
this is also meant to be able to say that MPEG should be opened using a certain
plugin, not just disable/enable plugins.
Comment 120 alanjstr 2003-12-22 08:41:01 PST
I know that, but any bug for "disable plugin foo" is duped on this.  So perhaps
that topic should be considered seperately, reopen 57760, and dupe a dozen bugs
to that one instead.
Comment 121 Olli Männistö 2003-12-22 12:02:03 PST
Firebird allows you to enable/disable plug-ins for downloading
(tools->options->downloading->plugins), which is really what I want and need.
YMMV. I use proxomitron with jd5000 filters to remove flash selectively.. 
Comment 122 alanjstr 2003-12-22 12:16:58 PST
Well, that dialog doesn't seem to work for me.  But that's a Firebird bug.
Comment 123 Torben 2003-12-30 10:49:09 PST
*** Bug 227639 has been marked as a duplicate of this bug. ***
Comment 124 Robin Lu 2004-01-19 22:50:59 PST
Created attachment 139478 [details] [diff] [review]
proposal patch

This is a prototype of plugin manager. You can disable plugins or mimetypes of
the plugins by it. It does not support save the configuration. I am figuring
how to do it now.
you also need to copy
  themes/classic/messenger/icons/check.gif
  themes/classic/messenger/icons/dot.gif
to
  extensions/pluginmanager/resources/skin/classic
and also the ones for the modern theme to apply the patch.

The patch is based on mozilla 1.6 branch.
Comment 125 Robin Lu 2004-01-19 23:51:33 PST
Created attachment 139483 [details]
screenshot
Comment 126 timeless 2004-01-20 00:29:06 PST
1. if you're going to use checkmarks, please align them consistently :)
2. We don't need a new windoow - if you can't fit into the pref panel then
modify about:plugins (possibly as an alternate url, about:plugins?configure)

3. if you're going to use the current layout, would you please consider honoring
the spirit of comment 0?

consider:
.________________________________________________________________________.
| Mime Types                    | Handler                              |=|
+-------------------------------+--------------------------------------+-+
|- application/                                                        |^|
| ===x-java-vm================== [Java(TM) Plug-in 1.5.0-beta-b32   |v]|H|
|    x-java-applet               |------------------------------------||H|
|    x-java-applet;version=1.1   |(None)                              || |
|    x-java-applet;version=1.1.1 |Sun Java(TM) Plug-in 1.4            || |
|    x-java-applet;version=1.1.2 |Java(TM) Plug-in 1.5.0-beta-b32=====|| |
|    x-java-applet;version=1.1.3 |____________________________________|| |
|______________________________________________________________________|v|

Note that we already have a panel labeled "Scripts & Plug-ins" in preferences,
that's approximately where this setting should live (well, scripts and plugins
should be split, but both should be in advanced) unless it's part of
about:plugins (which would be better imo).
Comment 127 Robin Lu 2004-01-20 00:53:41 PST
> 1. if you're going to use checkmarks, please align them consistently :)
sure. I will do that.

> 2. We don't need a new windoow - if you can't fit into the pref panel then
> modify about:plugins (possibly as an alternate url, about:plugins?configure)
I don't think it is a good idea. For consistency reason.

> 3. if you're going to use the current layout, would you please consider honoring
> the spirit of comment 0?
I don't like the idea too. For a user, it is much easier to disable plugins or
mimetypes in plugins than choose plugins for mimetypes. 
Comment 128 Doron Rosenberg (IBM) 2004-01-20 07:24:11 PST
The original idea was a api for vendors to be able to force say MPEG to play in
Real.  Probably adding such a tool would be the first step.

Definately shouldn't add a new overlay to navigator.xul, that could slow us
down.  It probably belongs in the pref panel like Timeless suggested, perhaps a
button that opens the new window ("Manage Plugins")?
Comment 129 timeless 2004-01-20 08:19:55 PST
i have to argue with 'easier'. having to disable something in five plugins just
so that it's accidentally handled by a sixth is *not* easier.

disabling is not something which makes sense to users. what makes sense is
saying I want to handle <list> with <thing>.

Again, the only reason I can see not to make the item just another pref panel is
if you're going to use a window, in which case you should piggyback on
about:plugins.
Comment 130 Brad Garcia 2004-01-20 08:38:38 PST
I have to agree with timeless.  If there are N plugins that all want to handle
audio/midi, then we need an interface that allows us to see which 1 plugin is
going to actually handle it, and to let us choose 1 and only 1 plugin to handle it.

The prototype given here does not allow that sort of view or selection.  As a
user, it will still not be clear to me exactly which plugin will handle
audio/midi until I examine the configuration for every single plugin.
Comment 131 Robert Kaiser (not working on stability any more) 2004-01-20 08:55:37 PST
That's a good point. OTOH, it's always good to have a noce overview of all
installed plugins :)

Well, anyways, you should add at least a buton to call this manager from
about:plugins - and I have to agree that it should be a pref panel. We already
have too many different "managers" that are outside prefs.
Comment 132 Robin Lu 2004-01-20 17:57:22 PST
OK. I agree with you all. I will add it to the pref panel.

But I still don't think the grouping plugins by mimetypes is a good idea.

Not any user will install N plugins which can deal with one mimetype. But there
is always one plugin that has N mimetypes, for example, java plugins. If you
want to choose to use another type of jave plugin, there are about more than
dozen of mimetypes to change. Sure you can add some trick to do that easier, but
it just adds more complexity. Plugin name is always more recognizable than
mimetype for normal users.

Counting the dup bugs, no more than five want to "choose plugin for mimetypes",
but nearly twenty want to "disalbe/enalbe plugins".
Comment 133 johann.petrak@gmail.com 2004-01-21 00:56:10 PST
I have to side with Robin here: the number of plugins will always be much
smaller than the number of mime-types. Many plugins will handle quite a lot of
different (but related) mime-types. So it is much easier for a user to simply
enable/disable a plugin that reassign all the handled mime-types to "none". Do
not forget in what cases and how often each of these functions might be needed:
assigning individual plugins to individual mime-types will only be used very
rarely, while switching a plugin off or on as a while will be needed much more
frequently.

Therefore, these are two different things really and one could imagine to have a
pref-panel that implements both: the simple default screen could be the list of
plugins -one line per plugin, where you can simple enable/disable. Then there
could be an "advanced" button that lets you configure all the nifty details. One
advantage of this approach would be that the first screen could be implemented
quickly, satisfying a large portion of those who wanted exactly this and got
DUPed against this bug. 
Comment 134 Olli Männistö 2004-01-21 01:16:14 PST
Let me give you guys a good example. Opening PDF files inside a browser is a
major pain. First off, you probably want to keep on browsing while keeping the
datasheet you downloaded open at the same time. Or maybe check something on the
website while you're at it. And the plugin tends to crash quite often compared
with the stand alone acrobat reader which is quite robust. Add to this that
mozilla scans for acrobat reader by default.. Firebird's plugin enable/disable
feature comes very handy here. And you can still assign a default action for pdf
files.
Comment 135 Christian :Biesinger (don't email me, ping me on IRC) 2004-01-21 05:37:29 PST
firebird's implementation does not handle in-page plugins and can therefore be
much simpler.
Comment 136 Doron Rosenberg (IBM) 2004-01-21 09:00:00 PST
The concept of telling what plugin handles what mimetype was originally designed
more for embeddors, in case they have preferences for their product, and not
really for the end user.
Comment 137 Jack Tanner 2004-01-21 17:16:22 PST
First, if this is about embeddors, wouldn't they be happier with a prefs.js way
of setting this, rather than an interactive UI?

Second, at least on Windows, there already exists a per-plugin UI (for what file
types a plug-in handles). Most plugins have a program in the Control Panel that
deals with this. So this should really be about mime types, not about plugins.
Timeless's UI suggestion is a good start.

BTW, do other browsers have similar functionality? If so, how is the UI
implemented? What works about it, and what doesn't?

Call me crazy, but I think the question of what file type is handled by what
program should be an OS-level question, not a browser (application-level)
question. I don't want to have different settings for when I open a file off my
desktop and when I open a file off the web (unless I'm downloading the file to
save for later). Given that I wonder if this "ought to be" (in an ideal world)
spun out into a separate cross-platform app.
Comment 138 haferfrost 2004-01-21 17:34:03 PST
> Call me crazy, but I think the question of what file type is handled by what
> program should be an OS-level question, not a browser (application-level)
> question. I don't want to have different settings for when I open a file off my
> desktop and when I open a file off the web

Then you should be using Internet Explorer and Outlook. This reasoning is
exactly what's been responsible for so many of their security holes in the past.
Trust me, you DO NOT want to execute Word for every application/msword file you
encounter on the Web. You DO NOT want to execute the shell for every
application/x-sh document you encounter on the Web. Yes, it is very convenient
but it's also very insecure. 
Comment 139 Lorenzo Colitti 2004-01-22 01:10:41 PST
The problem here is that just enabling or disabling plugins is not enough.

Many plugins will handle the same mime types (e.g. media players). In this case,
we would like, for example, to use the quicktime plugin for quicktime only and
use another plugin for everything else. This cannot be done by simply enabling
or disabling plugins.
Comment 140 johann.petrak@gmail.com 2004-01-22 01:37:12 PST
The problem is that practically all bugs that request explicitly the ability to
*enable/disable* plugins OR the ability to assign which plugin handles what have
been DUPed against this bug - so let us not forget these issues here just
because this back had a different scope originally. If this bug should be
reserved for the original purpose only, there should be bugs opened forthe other
issues and not gettting DUPed against his again. 
Comment 141 Simon Spiegel 2004-01-22 01:42:11 PST
Sorry for adding to the noise, but I just want to support Lorenzo's notion. For
me as an end user the main interest of this feature is the ability to decide
what content gets handled by which plugin. Take MPEG1 files as an example,
Quicktime, Real and WMP can all handle it. I want to be able to decide which
plugin does handle this file type, but I don't want to turn off a whole plugin
to do this. I need the Real plugin for Real files, the QT plugin for Sorenson
etc. Simply turning off the plugin doesn't improve the situation at all.
Comment 142 Per Olofsson 2004-01-22 01:46:08 PST
I just want to vote in favour of implementing a simple preference panel that
lets you enable or disable certain plugins. This would solve the problem for a
lot of people, and is fairly straightforward to implement. Fine grained control
over which mime type gets handled by which plugin can be added later.

Or maybe you could just copy the pref panel from Firebird.
Comment 143 johann.petrak@gmail.com 2004-01-22 02:01:57 PST
Please do not spam this bug further with your votes which aspect of the bug you
want implemented. It is obvious that there are requests for all of the aspects
and an ideal UI would probably allow to handle all of them but still keep the
interface simple and distinguish between simple and often needed, and complex
and infrequently needed functions.

Also note that this bug just about the UI - which is useless until  the backend
bugs are implemented. Note that all of the different aspects discussed here are
dealt with by the backend bugs - so once these are implemented the functionality
can be provided by the GUI defined here or some extension (or both). 
Comment 144 Brad Garcia 2004-01-22 04:18:12 PST
> Please do not spam this bug further with your votes which aspect of the bug you
want implemented.

The problem is that this bug is being commandeered as a "plugin enable/disable
selection" bug.  That is NOT what this bug was about!  Read Comment #0 again -
it's about choosing a plugin for each mime type!

I'm happy that some people would be satisfied with a plugin disabling option,
but that does not help me, and I don't want this particular bug marked as fixed
if something like that gets added.  A separate bug should be opened for that
request, and it should not be considered a dup to this bug.
Comment 145 Christian :Biesinger (don't email me, ping me on IRC) 2004-01-22 07:17:23 PST
> Call me crazy, but I think the question of what file type is handled by what
> program should be an OS-level question, not a browser 

plugins and applications are two pretty unrelated concepts.
Comment 146 Zook Valem 2004-01-22 18:11:05 PST
>>The problem is that this bug is being commandeered as a 
>>"plugin enable/disable selection" bug.  That is NOT what 
>>this bug was about!  Read Comment #0 again - it's about 
>>choosing a plugin for each mime type!
Does comment #0 include an option of choosing as "none" for any mime type?  (If
it is not the right plug-in you want)
Comment 147 mws 2004-01-30 17:22:48 PST
I originally reported this RFE bug and would request that the fix of this bug
resolves the problem that I had in comment 0 with one exception. I believe there
should be a none entry so that you can prevent all plugins from executing a
specific mime type as comment 60 suggests:

 audio/midi
    O None
    O LiveAudio
    O LiveUpdate Crescendo version 4.02
    O QuickTime Plug-in 4.0.3
 audio/aiff
    O None
    O LiveAudio
    O QuickTime Plug-in 4.0.3
Comment 148 tlroche 2004-01-30 18:30:54 PST
mws193@netscape.net  2004-01-30 17:22 PST
> I believe there should be a none entry so that you can prevent all
> plugins from executing a specific mime type as comment 60 suggests:

>  audio/midi
>     O None
>     O LiveAudio
>     O LiveUpdate Crescendo version 4.02
>     O QuickTime Plug-in 4.0.3

I concur. Specifically, I want to be able to specify that PDFs should
always be handled by Acrobat (the external app) and not the Acrobat
plugin (e.g. via the usual UI for save to disk, launch file).
Comment 149 tlroche 2004-01-30 18:49:53 PST
Olli Männistö  2003-12-22 12:02 PST
>> Firebird allows you to enable/disable plug-ins for downloading
>> (tools->options->downloading->plugins), which is really what I want
>> and need.

mws193@netscape.net  2004-01-30 17:22 PST
>  audio/midi
>     O None
>     O LiveAudio
>     O LiveUpdate Crescendo version 4.02
>     O QuickTime Plug-in 4.0.3

Note that I find the UI above to be superior to that currently in
Firebird 0.7. I find it non-intuitive that I can set
Tool>Options>Downloads>File Types>PDF=Save to Disk, and yet the plugin
will still load the file! Instead one must Tool>Options>Downloads,
ignore the File Types viewer right there in front of you, and hit
Plug-Ins>PDF=disabled. It's also superfluous: why 2 UIs? UI should be
enough for this use case!

(BTW if this is not the appropriate place to report bugs on Firebird,
please let me know. I am monitoring this bug, so a comment will do.)
Comment 150 tlroche 2004-01-30 19:26:53 PST
tlroche  2004-01-30 18:49 PST
> why 2 UIs? UI should be enough for this use case!

(should read "One UI should be enough ...") 

Also, from reading some other comments on this bug (but not all--
there's too many !-) ISTMT the UI should recognize, and distinguish
between, the separate preferences to

* ignore a particular mimetype: if I despise application/foo, the
  browser will just ignore it

* save to disk: invokes the current [Save As, x% of Whatever Saved]
  dialog sequence, with Launch File option on the latter (app launched
  determined by OS preferences).

* open with application: skips the [Save As, Whatever Saved] sequence,
  just saves to $TMP and launches the application. Application should
  be specifiable in this UI.

* open with plugin: opens in browser. Plugin should be specifiable
  with this UI.

So my rev of the above UI would be something like

audio/midi
0 Ignore
· Save to Disk
0 Application: LiveUpdate Crescendo version 4.02
0 Application: <another registered application>
0 Application: specify [text for entry of path] [browse button?]
0 Plugin: QuickTime Plug-in 4.0.3
0 Plugin: <another found plugin>

and so on, with the thingies at left being all radios.
Comment 151 Zook Valem 2004-02-01 10:55:25 PST
Comment #147 answered my question to comment #146 and I'm now satisfied with the
reporter's response.  Sorry I didn't see comment #60.  Thanks.
Comment 152 Robin Lu 2004-02-01 18:52:00 PST
(In reply to comment #139)
> The problem here is that just enabling or disabling plugins is not enough.
> 
> Many plugins will handle the same mime types (e.g. media players). In this case,
> we would like, for example, to use the quicktime plugin for quicktime only and
> use another plugin for everything else. This cannot be done by simply enabling
> or disabling plugins.

You can disable mimetypes in a plugin instead of the whole plugin (see the
screenshot). There's not much difference in the functionality of the two method.
Comment 153 Boris Zbarsky [:bz] (Out June 25-July 6) 2004-02-08 20:37:17 PST
*** Bug 233470 has been marked as a duplicate of this bug. ***
Comment 154 Robin Lu 2004-02-24 02:09:29 PST
Created attachment 142120 [details] [diff] [review]
proposal patch 2

With this patch, you can disable/enable the plugins or mimetypes in the
plugins.
Changes from last patch:
1. config can be saved to the 'plugins.rdf' now.
2. remove it from the "Tool" menu and add a button in "Scripts & Plug-ins" to
launch the manager.

Still no ui for choosing plugins for mimetypes.
Comment 155 Jeff Albro 2004-03-26 17:15:22 PST
In an effort to get developers to "scratch this itch", I'm putting up a bounty
of 3 pints of Ben and Jerry's for a solution to this bug.  Peter Lubczynski
should e-mail me with who he wants (coupons for) the pints to go to after this
problem is solved.

Thanks!

-Jeff (jeff@antistatic.com) 
Comment 156 Andrey ``Bass'' Shcheglov 2004-05-19 00:34:20 PDT
And there's one more (related) functionality from Netscape 4.x that is missing
in Mozilla: ability to make the browser handle a certain MIME type internally.
For instance, I want to assign a `text/plain' type to all *.java files and
handle them with the Navigator, even when the web site claims the file type to
be `appliaction/octet-stream'.
Comment 157 Chapman Flack 2004-05-24 15:00:25 PDT
Just a thought....

Several comments have volleyed the question whether it makes more sense to the
user to see a list of plugins/helpers, with the group of mime types each one can
handle, or a list of mime types, with the group of plugins/helpers that can
handle each one.  It seems to me that which one is "easier" depends on the
individual user's circumstances.  One user might be thinking "I want to
completely disable the Foozivity plugin, it always crashes", another might be
thinking "I have eight options to handle application/x-fzv and I want to choose
one", and yet another might just be thinking "if I see another application/x-fzv
I'm gonna scream." They'll differ in which way of organizing the UI they find
most useful.

It also seems to me this is nothing more than two views of the same thing.
Conceptually you've got a relation of plugin/helper,mimetype,boolean that can be
sorted by one column or the other, much the way about:config already works. Not
that it has to be done as a page like about:config; the point's just that the
two different presentation styles are really nothing more than different ways of
sorting the underlying relation, and they'll both be useful to different users
at different times.
Comment 158 Robin Lu 2004-05-26 02:14:30 PDT
There's another reason why I didn't implement in the choosing way. For
disable/enable method, the action is easy to define. If you disable a plugin,
what you mean is that you don't need the plugin to deal with one or more
mimetypes while the rest of the work can be determined by the browser. 

But if you like to choose a plugin for each mimetype, there are more things
needing to be defined. For example, when users do not choose anyone, which one
should be chosen? If a plugin is chosen for a mimetype, what do the user mean by
the other plugins that can deal with the mimetype? Disalbed or backup choises?
If the chosen one is removed, what is expected to do? Request the user to choose
another one or just use the next one? Before all these can be defined, it is
hard to make a UI for that.
Comment 159 Brad Garcia 2004-05-26 03:11:49 PDT
Robin,

You have similar questions to answer when you choose to solve the problem in the
manner that you chose as well.  When there is more than one plugin enabled to
handle a particular mimetype, what does it mean, and which one should be used? 
If a plugin is removed, and no other plugins capable of handling a mimetype are
currently chosen, should the user be requested to choose a new one, or just use
another one even though it is disabled?

Those are all good questions that you raise.  However, each of those questions
(as well as the additional questions that I raised) is already answered by how
the browser works *today*.  I don't really care how each of those corner-case
questions is answered - the browser implements one or the other today, and that
is fine.  At this point, it's a matter of finding out how it handles each of
those situations.

I think Chapman is onto something in his comment #157.  It seems like each
plugin/mimetype tuple conceptually has a boolean enable/disable value associated
with it.  We can allow users to view it both ways - as a list of plugins for a
particular mimetype, as well as a list of mimetypes that each plugin can handle.
 It's just two different views on the same set of data.  When you view it this
way, the corner cases that we both cited above are actually the *same* corner cases!
Comment 160 Robin Lu 2004-05-26 20:16:56 PDT
I thought they were the same before. But when I began to work on it, I found
they are different.

In disable/enable method, a plugin/mimetype tuple could be either disable or
enable. Black or white. It is browser's job to choose an enabled one.

In choosing method, if you still use disable/enable mode, choosing a plugin for
a mimetype implies disabling all the others. This implication does not exist in
disable/enable method and it brings the questions I mentioned in comment #158.
The question raised by you can be answered by the current behavior of browser
but not mine, because we introduce a new implication.

There might be one solution. We can add a new status called "preferred". The
plugins other than "preferred" can still be enabled/disabled. If no one is
preferred (users do not choose one or the preferred one is removed), browser can
choose one from enabled plugins as usual. This is clear and does not introduce
any new implication. However, it is more than just adding a view.
Comment 161 Brad Garcia 2004-05-27 04:50:48 PDT
> In choosing method, if you still use disable/enable mode,
> choosing a plugin for a mimetype implies disabling all the others.

It doesn't *have* to be that way.  Just allow the user to select more than one.
 Or none.  Once you do that, then it is simply just a different view.  You would
probably need a note stating that checking more than one allows the browser to
choose between the selected choices.
Comment 162 Chapman Flack 2004-05-27 14:04:23 PDT
I had just sort of arrived at the "preferred" idea myself, in this comment
that I was composing while comment 160 and comment 161 arrived.  :)
So here's what I was thinking...

... it wouldn't really be best to *display* the data as tuples exactly, but
group the display so the major sort key is only displayed once.  So, not:

  Acrobat Plugin     application/pdf
  Acrobat Plugin     application/vnd.fdf
  Foozivity Plugin   application/x-fzv
  Thadwackle Plugin  application/x-fzv

But rather:

  Acrobat Plugin
  		     application/pdf
  		     application/vnd.fdf
  Foozivity Plugin
  		     application/x-fzv
  Thadwackle Plugin
      	      	     application/x-fzv

Besides being easier to read, that creates a natural place to have a
'disable all' button, as well as an enable checkbox for each type:

  Acrobat Plugin      	      	      	  [disable all]
  		     application/pdf  	  [ ] enable
  		     application/vnd.fdf  [ ] enable
  Foozivity Plugin    	      	      	  [disable all]
  		     application/x-fzv	  [ ] enable
  Thadwackle Plugin                       [disable all]
      	      	     application/x-fzv    [ ] enable

Clicking 'disable all' just unchecks all the enable boxes in the group.
It works the same way in the other view:

  application/pdf			  [disable all]
                     Acrobat Plugin       [ ] enable
  application/vnd.fdf			  [disable all]
                     Acrobat Plugin       [ ] enable
  application/x-fzv			  [disable all]
                     Foozivity Plugin     [ ] enable
		     Thadwackle Plugin    [ ] enable

In either view, the constraint is enforced that at most one enable box
can be checked for any one content type. [this changes, with "preferred".]

Hmm, I've forgotten to show the marketroid names for the content types;
they'd need to be shown too:

 Adobe Forms Data Format   (application/vnd.fdf)
      	      	      	      	      	      	  Acrobat Plugin
 Portable Document Format  (application/pdf)
      	      	      	      	      	      	  Acrobat Plugin
 Rich Computing Experience (application/x-fzv)
      	      	      	      	      	      	  Foozivity Plugin
      	      	      	      	      	      	  Thadwackle Plugin

When showing the view by type, it is probably best to give the user
the option to sort either by the official content type or by the
marketroid name, because they will alphabetize differently, and users
will differ in which name they think easier to find in a list.

As for what to do if a document of type application/x-fzv comes in and
the user has disabled both Foozivity and Thadwackle - to me that's very
clear: a dialog says "This document has the type Rich Computing Experience
(application/x-fzv).  You have the following plugin(s) that could handle it
but you have not enabled one.  Would you like to enable one now?"  To my
mind software should never be in the business of deciding the user didn't
mean what he said, or supposing it knows what he really wants.  :)

One more point - this may be gravy: there was some discussion about what to
do when a *document* specifies that it wants to be handled by a particular
plugin.  My first reaction is to flog the author of the document, but I
suppose there can be legitimate reasons sometimes.  So maybe each tuple
should have something more than a boolean.  Maybe an 'enable/disable'
checkbox and a 'prefer' checkbox, where you can enable as many as you want
but can only prefer one.  A document can ask for a plugin other than the
user's preferred one, as long as it's enabled.
Comment 163 Sam McDonald 2004-07-20 15:08:36 PDT
Alert: Plug-in Manager is Missing!  

System: SuSE 9.1 Pro and Mozilla 1.7.
Problem: Under EDIT -> PREFERENCES -> ADVANCED -> SCRIPTS and PLUG-INS the check
box for selecting which plug-ins you want to enable/disable is missing.  The
words are missing too. 
Comment 164 hahn 2004-09-28 08:36:33 PDT
Comment #162 seems to close the discussion, but since there has not been any
activity for half a year on and considering the age of this bug, 

is anyone actually working on this?

would be great! please....
Comment 165 Boris Zbarsky [:bz] (Out June 25-July 6) 2004-10-04 20:42:16 PDT
*** Bug 262257 has been marked as a duplicate of this bug. ***
Comment 166 Justin Kerk 2004-10-16 22:50:52 PDT
I think this should have parity-opera in the status whiteboard but I'm not sure
what the etiquette for changing that field is.
Comment 167 Anthony DiSante 2004-12-21 22:26:06 PST
Every few times a plugin loads -- on multiple systems, and whether it's Flash,
gxine/gmplayer (audio and video), whatever -- the browser crashes.  This is
infuriating because you then lose all your open tabs (and all your mail windows,
if using mail).  It happens to me >once/week since so many sites use disgusting
embedded flash or video.

The solution is to run plugins in a separate process/thread, but there is no
progress on that since bug 156493 is going nowhere.  The work-around would be to
be able to disable a given plugin (by plugin, or mime-type, by ANTHING, I don't
even care at this point), but that's this bug, and it also is going nowhere. 
It's been going strong to nowhere for 5 years now.

I can't possibly be the only person fed up with buggy plugins causing them to
lose all their work on a weekly basis.... can I?  Granted I'm not offering to
code the solution, but it seems to me like this is a serious problem that's been
around for 5 years with zero progress.   There are scads of bug reports about
it, and still nothing.
Comment 168 Matthias Versen [:Matti] 2004-12-22 05:57:45 PST
*** Bug 275642 has been marked as a duplicate of this bug. ***
Comment 169 Doron Rosenberg (IBM) 2005-01-04 15:11:56 PST
*** Bug 277055 has been marked as a duplicate of this bug. ***
Comment 170 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-04 16:46:47 PST
*** Bug 277055 has been marked as a duplicate of this bug. ***
Comment 171 Elmar Ludwig 2005-03-17 07:30:40 PST
*** Bug 286552 has been marked as a duplicate of this bug. ***
Comment 172 Matthias Versen [:Matti] 2005-04-13 15:10:03 PDT
*** Bug 290232 has been marked as a duplicate of this bug. ***
Comment 173 Steve Russell (RaiseMachine) 2005-07-31 22:04:51 PDT
I can't believe that in all those posts noone mentioned this extension.

Mime Type Editor
http://gratisDei.com/FF.htm
Comment 174 Steve Russell (RaiseMachine) 2005-07-31 22:12:22 PDT
(it's a year or so old and will probably need a MaxVersion change in
install.rdf,  solves all I needed it to)

Maybe some of its code can be used...
Comment 175 Ria Klaassen (not reading all bugmail) 2006-02-09 01:26:33 PST
*** Bug 326494 has been marked as a duplicate of this bug. ***
Comment 176 Elmar Ludwig 2006-02-22 13:38:05 PST
*** Bug 328227 has been marked as a duplicate of this bug. ***
Comment 177 Andrew Schultz 2006-06-24 23:20:50 PDT
*** Bug 342631 has been marked as a duplicate of this bug. ***
Comment 178 James B. Higgs 2006-06-25 18:04:36 PDT
(In reply to comment #177)
> *** Bug 342631 has been marked as a duplicate of this bug. ***
> 

Hi Guys,

My Bug was marked as a DUPE of this Bug:

When web pages send PDF Documents, they usually end up being huge reource hogs,
my browser and mail/news windows start displaying incorrectly (right sides,
tops and bottoms disappear, I have to use a script program I have to resize
them correctly *after* I have unloaded the PDF file) and I have to save them
to disk, exit SeaMonkey, and run Adobe to view them properly anyway, so I
would like to keep them from loading in the first place. I would like the
option to configure SeaMonkey *not* to use a given plugin by default, but to
bring up a dialog asking me whether to Open or Save the file, preferably with
that "Always perform this action on this file type" checkbox included.

(This would have the added benefit of allowing me to save JibJab files to disk,
after I've viewed them. :> )

Jim H. (aka CuriousJ)

Reproducible: Sometimes

Steps to Reproduce:
1. Load a web page with a largish Adobe PDF document in it.

Actual Results:  
Screws up entire SeaMonkey application royally, I have to save PDF document to
disk, hit the Back button to get out of it, respond to the protests about
closing the PDF document, correct the sizing of my windows, note where I am in
all my windows, exit SeaMonkey, shut down and reboot, and return to SeaMonkey.

Expected Results:  
Expect to be *asked* whether I want to open a 3rd-party document or not.

Jim H. (aka CuriousJ)
Comment 179 James B. Higgs 2006-06-25 19:08:45 PDT
(In reply to comment #178)
> I would like the option to configure SeaMonkey *not* to use a given plugin by
> default, but to bring up a dialog asking me whether to Open or Save the file,
> preferably with that "Always perform this action on this file type" checkbox
> included. 
> 
> (This would have the added benefit of allowing me to save JibJab files to
> disk, after I've viewed them. :> )
> 
> Expected Results:  
> Expect to be *asked* whether I want to open a 3rd-party document or not.
> 

Having read all the other comments under this Bug, I think this is the first
mention of simply wanting an option to "Launch Plugin" or "Save to Disk", but,
whatever is done to resolve all these other issues, once you've defined which
plugin you want to handle which mime-types, you should still have this option,
and, of course, the "Always perform this action with this mime-type" checkbox
in the dialog.

Jim H. (aka CuriousJ)
Comment 180 Daniel Veditz [:dveditz] 2006-06-26 08:40:18 PDT
(In reply to comment #178)
> > *** Bug 342631 has been marked as a duplicate of this bug. ***
> 
> My Bug was marked as a DUPE of this Bug:

But not the part you're talking about here. If you don't want PDF's to open in the browser then uncheck "Display PDF in browser" in the Adobe prefs, or remove the plugin manually, or remove PDF from the "View and edit actions" button on the Download preference dialog panel.

I do not get PDF's opened in my browser, I get asked.
Comment 181 James B. Higgs 2006-06-26 08:59:22 PDT
(In reply to comment #180)
> or remove PDF from the "View and edit actions" button on
> the Download preference dialog panel.
> 
> I do not get PDF's opened in my browser, I get asked.
> 

Where do I find the "Download preference dialog panel"? Is it in Adobe or
SeaMonkey?

Thanx,
Jim H. (aka CuriousJ)
Comment 182 David Dorward 2006-06-26 09:03:08 PDT
In Firefox (Windows menu layout): Tools menu > Options menu item > Downloads tab > View and Edit Actions button
Comment 183 James B. Higgs 2006-06-26 15:03:53 PDT
(In reply to comment #182)
> In Firefox (Windows menu layout): Tools menu > Options menu item > Downloads
> tab > View and Edit Actions button
> 

I'm in SeaMonkey ... We don't have that.

Jim H. (aka CuriousJ)
Comment 184 James B. Higgs 2006-06-26 15:43:41 PDT
Created attachment 227157 [details]
GIF Image of SeaMonkey Download Preferences

Limited ability to control whether to load or save incoming plugin file in
SeaMonkey vs. FireFox as atested to by these comments:

------- Comment #180 from dveditz@cruzio.com  2006-06-26 08:40 PDT -------
(In reply to comment #178)
>> > > *** Bug 342631 has been marked as a duplicate of this bug. ***
> > 
> > My Bug was marked as a DUPE of this Bug:

But not the part you're talking about here. If you don't want PDF's to open in
the browser then uncheck "Display PDF in browser" in the Adobe prefs, or remove
the plugin manually, or remove PDF from the "View and edit actions" button on
the Download preference dialog panel.

I do not get PDF's opened in my browser, I get asked.

------- Comment #181 from curiousj@adelphia.net  2006-06-26 08:59 PDT -------
(In reply to comment #180)
> > or remove PDF from the "View and edit actions" button on
> > the Download preference dialog panel.
> > 
> > I do not get PDF's opened in my browser, I get asked.
> > 

Where do I find the "Download preference dialog panel"? Is it in Adobe or
SeaMonkey?

Thanx,
Jim H. (aka CuriousJ)

Comment #182 from bugzilla@david.us-lot.org 2006-06-26 09:03 PDT -------
In Firefox (Windows menu layout): Tools menu > Options menu item > Downloads
tab > View and Edit Actions button

------- Comment #183 from curiousj@adelphia.net  2006-06-26 15:03 PDT -------
(In reply to comment #182)
> > In Firefox (Windows menu layout): Tools menu > Options menu item > Downloads
> > tab > View and Edit Actions button
> > 

I'm in SeaMonkey ... We don't have that.

Jim H. (aka CuriousJ)
Comment 185 Robert Claypool 2006-06-27 20:52:51 PDT
There should be a button next to extensions and themes for plug-ins
Comment 186 Phil Ringnalda (:philor) 2006-07-04 15:46:04 PDT
*** Bug 343572 has been marked as a duplicate of this bug. ***
Comment 187 John David Galt 2007-11-01 13:35:53 PDT
Excuse me if this is a dumb question, but doesn't Tools -> Options -> Content -> Manage (in Firefox 2) already provide most of this functionality?  Granted, that dialog ought to have an "Add New Type" button.
Comment 188 Anthony DiSante 2007-11-01 15:21:25 PDT
> Excuse me if this is a dumb question, but doesn't Tools ->
> Options -> Content -> Manage (in Firefox 2) already provide
> most of this functionality?  Granted, that dialog ought to
> have an "Add New Type" button.

Well, that must be a relatively new feature; it didn't exist 3 years ago when I first commented on this bug.

But yes, it needs an "Add New Type" facility, and it also needs an option for "ask me every time", i.e. display the standard Open/Save dialog.  I think that for most embedded content, the ideal solution would be an option to do what Flashblock does: display a clickable placeholder, but instead of automatically playing upon click, it should display a menu or just display the Open/Save dialog.
Comment 189 Akkana Peck 2007-11-01 21:12:13 PDT
It's there, but it's not clear it actually does anything.

In Preferences, Content->Manage (assuming that's the same thing), I see two items for flash: SWF and SPL. Changing them from "Open with Shockwave Flash" to "Save to Disk" doesn't seem to change anything, even after a restart. When I go to an all-flash page such as http://www.nseries.com/index.html it still plays flash.

(Flashblock handles most pages like that, though I often wish there was a way to set the browser to claim temporarily that there is no flash installed, so I can see the text content. That's probably outside the scope of this bug, though.)
Comment 190 Gábor Stefanik 2007-11-23 07:53:54 PST
We might integrate the MIME Edit extension into Firefox, that's also a choice. Also, this bug is "9xp", that is, Netscape Navigator 9 has this feature.
Comment 191 Dave Townsend [:mossop] 2008-01-09 03:40:52 PST
*** Bug 411255 has been marked as a duplicate of this bug. ***
Comment 192 Gábor Stefanik 2008-01-09 07:27:43 PST
Note: not 9xp anymore, just checked, it was in the betas of Nav9, but not in the final release. Also, Tools -> Options -> Content -> Manage only handles file name extensions, not MIME types.
Comment 193 Dave Townsend [:mossop] 2008-01-10 02:53:17 PST
*** Bug 411255 has been marked as a duplicate of this bug. ***
Comment 194 Jo Hermans 2008-01-25 16:56:35 PST
*** Bug 414070 has been marked as a duplicate of this bug. ***
Comment 195 Dave Townsend [:mossop] 2008-02-14 14:45:57 PST
*** Bug 417600 has been marked as a duplicate of this bug. ***
Comment 196 Jo Hermans 2008-05-30 13:43:06 PDT
*** Bug 436576 has been marked as a duplicate of this bug. ***
Comment 197 Matthias Versen [:Matti] 2008-07-05 03:44:35 PDT
*** Bug 443686 has been marked as a duplicate of this bug. ***
Comment 198 Matthias Versen [:Matti] 2008-10-01 02:24:01 PDT
*** Bug 457861 has been marked as a duplicate of this bug. ***
Comment 199 Matthias Versen [:Matti] 2008-11-01 11:16:28 PDT
*** Bug 462680 has been marked as a duplicate of this bug. ***
Comment 200 Nochum Sossonko [:Natch] 2009-01-29 10:39:02 PST
*** Bug 475975 has been marked as a duplicate of this bug. ***
Comment 201 John Vandenberg 2010-10-21 17:42:33 PDT
(Sort of in reply to comment #190)

The MIME Edit extension isn't supported by FF 3
https://addons.mozilla.org/en-US/firefox/addon/5561/

The addons page mentions another one
http://space.geocities.yahoo.co.jp/gl/alice0775/view/20080912/1221150790

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