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

Shrirang is now QA owner for Plug-ins; QA assigning all of my Plug-ins bugs over to him.

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

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

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

Could about:plugins be re-written to do this?

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.

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

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.

Mozilla already has a internal plugin manager. It would be nice to develop some UI to get to some of the interface methods.

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

spam: adding self to cc

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.

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.

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

This would be very very useful

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

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

nobody is working on this :)

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

bug 61103 [RFE] Add a preference to disable dialogs for loading plugins

see also bug 54940: define list for helper applications. that would nicely complement this feature as well.

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.

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

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

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

Voting for this bug. Keep up the good work...hold on, nobody's working on this bug. Get your lazy butts in gear! :)

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.

i'm relatively opposed to paths in preferences.

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

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.

Could mimetypes.rdf be used to hold plugin information? Is there a service for reading that file?

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.

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

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;

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

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

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.

handleInternally does not work in the current architecture.

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.

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

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.

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

adding self to cc list

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

Am I dreaming or what? Could you at least explain why this bug is a WONTFIX? IMO this would be an extremely useful feature.

Sorry, sorry, big sorry. My fault. Didn't realize that this wasn't this bug, but a dependig one. Really sorry.

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

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

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

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

setting to PL2:P1

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.

because that is how we are prioritizing the bug

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

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.

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.

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.

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

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

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

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

batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

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

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

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.

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

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

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.

Topembed+ as this is required for Gecko 2.0.

--->serge is working on this

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

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

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

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.

Couple of files in the previous patch are duplicates by accident, sorry about that.

in progress

I thought new files were supposed to be MPL/GPL/LGPL...

Why overlay the plugin entry in contents.rdf and not simply add it to the prefs.xul file?

Yes, brand new files are supposed to use the MPL tri-license headers, boilerplate available from http://www.mozilla.org/MPL/

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.

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.

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.

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

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

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.

> 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

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.

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.

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

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

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

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

SPAM: Add CC ***** acrobat plugin ;-)

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

moving to 1.4 beta -- plug-in branch work

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.

--> peterl

I can help with UI if need be

per topembed+ triage ---> P2:Future

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.

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

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?

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

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

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

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

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

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

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

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

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.

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

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

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.

For what it's worth, firebird allows you to disable plugins with UI. Great for kicking acrobat out of browser.

I have Firebird. Where am I supposed to be looking?

no. it doesn't. in-page plugins still work in firebird even if disabled. (<object>/<embed>)

this is also meant to be able to say that MPEG should be opened using a certain plugin, not just disable/enable plugins.

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.

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

Well, that dialog doesn't seem to work for me. But that's a Firebird bug.

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

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.

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

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

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")?

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.

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.

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.

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

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.

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.

firebird's implementation does not handle in-page plugins and can therefore be much simpler.

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.

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.

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

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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.

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)

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

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.

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.

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!

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.

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

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.

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

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

I think this should have parity-opera in the status whiteboard but I'm not sure what the etiquette for changing that field is.

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.

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

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

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

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

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

I can't believe that in all those posts noone mentioned this extension. Mime Type Editor http://gratisDei.com/FF.htm

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

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

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

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

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

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

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

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

In Firefox (Windows menu layout): Tools menu > Options menu item > Downloads tab > View and Edit Actions button

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

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)

There should be a button next to extensions and themes for plug-ins

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

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.

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

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

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.

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.

(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