Closed Bug 19118 Opened 25 years ago Closed 11 years ago

Plug-In Manager (ui for choosing mimetype-plugin associations)

Categories

(Firefox :: Settings UI, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mattsmeltz, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(6 files, 3 obsolete files)

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.
Status: NEW → ASSIGNED
Target Milestone: M15
Target Milestone: M15 → M17
<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>
Assignee: av → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
Target Milestone: M17 → Future
*** Bug 32380 has been marked as a duplicate of this bug. ***
Depends on: 44973
*** 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.
Keywords: nsbeta1, nsCatFood
*** 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. ***
Summary: Plug-In Manager for Browser → Plug-In Manager (ui for choosing mimetype-plugin associations)
nobody is working on this :)
Assignee: nobody → peterlubczynski
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.
Blocks: 104166
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. ***
Keywords: mozilla1.0
Target Milestone: Future → ---
*** 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 :-).
Status: NEW → ASSIGNED
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;
Keywords: helpwantedpatch
Target Milestone: --- → mozilla0.9.9
Attached patch slight change (obsolete) — Splinter Review
Attachment #68023 - Attachment is obsolete: true
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.... 
Target Milestone: mozilla0.9.9 → mozilla1.1
*** 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. ***
Blocks: 147866
Depends on: 54940
Whiteboard: [Plug-in Mgr]
Target Milestone: mozilla1.1alpha → mozilla1.2beta
*** Bug 152583 has been marked as a duplicate of this bug. ***
Blocks: 152583
No longer blocks: 152583
*** Bug 152583 has been marked as a duplicate of this bug. ***
Blocks: 90062
setting to PL2:P1
Severity: enhancement → critical
Priority: P3 → P2
Whiteboard: [Plug-in Mgr] → [Plug-in Mgr][PL2:P1]
Target Milestone: mozilla1.2beta → mozilla1.1alpha
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.
Severity: critical → enhancement
Keywords: mozilla1.04xp, mozilla1.2
Severity: enhancement → critical
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. 
Severity: critical → normal
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.
Priority: P2 → P1
Target Milestone: mozilla1.1alpha → mozilla1.2beta
*** 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
Keywords: topembed
*** Bug 169191 has been marked as a duplicate of this bug. ***
Blocks: 168889
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
Blocks: 169985
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.
Keywords: topembedtopembed+
--->serge is working on this
Assignee: peterlubczynski → serge
Status: ASSIGNED → NEW
*** Bug 173488 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2beta → mozilla1.3beta
*** Bug 173857 has been marked as a duplicate of this bug. ***
*** Bug 175561 has been marked as a duplicate of this bug. ***
Blocks: grouper
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.
Attachment #68025 - Attachment is obsolete: true
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
Whiteboard: [Plug-in Mgr][PL2:P1] → [Plug-in Mgr][PL:Branch]
Target Milestone: mozilla1.3beta → mozilla1.4beta
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
Assignee: serge → peterl
I can help with UI if need be
Keywords: mozilla1.2
per topembed+ triage ---> P2:Future
Priority: P1 → P2
Target Milestone: mozilla1.4beta → Future
Target Milestone: Future → mozilla1.5alpha
Blocks: 191546
Blocks: majorbugs
Depends on: 144263
Whiteboard: [Plug-in Mgr][PL:Branch] → [Plug-in Mgr][PL:Branch],edt_a3
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.
Target Milestone: mozilla1.5alpha → ---
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. ***
Attached patch proposal patch (obsolete) — Splinter Review
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.
Attached image screenshot
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. ***
Attached patch proposal patch 2Splinter Review
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.
Attachment #139478 - Attachment is obsolete: true
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) 
Severity: normal → enhancement
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. ***
No longer blocks: majorbugs
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. ***
Assignee: peterl-bugs → nobody
Priority: P2 → --
QA Contact: shrir → plugins
(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.
Blocks: 411980
(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
Component: Plug-ins → Preferences
Keywords: 4xp, topembed+
Product: Core → Firefox
QA Contact: plugins → preferences
Whiteboard: [Plug-in Mgr][PL:Branch],edt_a3
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.