Build ID: current CVS build from today Edit | Preferences | Navigator | Helper Applications allows people to create entries for MIME types for MIME types that Mozilla already handles internally. As far as I can see, these user-set entries will be then ignored, surprising the user (who is having their apparently valid preferences ignored). Steps to reproduce: 1. Open up the Helper Applications whatever-you-want-to-call-it bit of Preferences. 2. Add an entry for 'image/jpeg' that runs an external program to view the JPEG image. 3. click an appropriate number of OK buttons; observe that Mozilla doesn't emit any messages about it. 4. Type the URL of the JPEG image of your choice into Mozilla, or visit a page with a JPEG on it and use 'View Image'. 5. Observe that Mozilla has not used the just-set user MIME type information to display the JPEG image, and is thus ignoring it. I think that Mozilla should warn people if they are trying to do something with a helper application that it is going to ignore. (I assume that not ignoring it is an RFE and not a bug, and have filed that as bug #58554.)

MIME types which are handled internally should still have their own entries in the list to begin with, so you can see how they are handled.

this repros on mozilla 0.8 linux rpm with external mime types also; i used RealPlayer. Adding a helper for audio/x-pn-realaudio has no effect [still shows up in preferences, but i get the "this file has mime type audio/x-pn-realaudio and cannot be viewed using mozilla" dialog when i try to view an audio file. fyi only text/html is listed internally in mimeTypes.rdf here.

mscott, would this be yours?

The default mime type of "text/html" should be changed to "text/plain" and made editable. Hard-wiring text/html to "internal" doesn't appear to be that useful, and also is done in an erronous way, imho. If I send output from a nph-cgi and omit the status code and mime type, the page displays fine in mozilla, but netscape 4.7 wants do save it to disk. If I place a "Status: 200 OK\nContent-type: text/html\n\n" as the first print statement of said program (which is what is needed to conform to the HTTP 1.0 protocol standard, btw), mozilla displays before the proper page content: "Status: 200 Ok Content-type: text/html" which I think is a violation of the HTTP protocol standard. Imho this bug should be fixed by 1.0 at the latest, and I'd also like to see mozilla pick up the system installed mime types, too (eg. /etc/mime.types under some flavours of Unix or Linux). Thank you!

a_geek: an HTTP transaction must begin with the HTTP version, not the bogus "Status: ". Read RFC 2068 and/or RFC 2616. Our behavior is correct.

Oh, and we've been picking up mime.types/mailcap since 0.9.3 if you set the file preferences correctly, and 0.9.5 specifically picks up /etc/mime.types by default. None of which is relevant to this bug.

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

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

i'd like to give all of my 10 votes for this bug. it is just because of this that I am still forced to resort to netscape 4.7.

also, maybe 67549 should be marked as a duplicate?

I'd like to give 7 of my votes to this bug as well. Not allowing user-defined helper apps to override defaults forces me either to Netscape 4.x or Konqueror often.

Here's a patch that at one time had allowed you to override plugin handled mime types through the helper applications prefs panel: http://bugzilla.mozilla.org/attachment.cgi?id=68025&action=view The only thing is I'm not sure how expensive |GetMIMEInfoForMimeTypeFromDS| is. Need to run some tests to ensure I didn't kill performance (is mimetypes.rdf cached?)

GetMIMEInfoForMimeTypeFromDS is expensive the first time, for sure (it loads the data source). After that, the RDF is cached, but not the nsIMIMEInfos. I'm not sure people would be satisfied with just allowing override of plugin-handled types. They want to override stuff like image/gif, no? Also, I think maybe the votes for this bug really want to be votes for bug 58554. *This* bug is about letting the poor user set up helper app entries for mime types that we then ignore. That could probably be fixed without too much trouble, but it ain't gonna make the grade for mozilla1.0, I'm afraid.

I think this bug should have a higher priority than "minor" and should be solved soon. It is not so very seldom that on a special PC a special plugin causes Problems, and then it would be fine if you could use an alternative plugin. Sometimes also there are general mozilla-Problems with a plugin as bug 138173 shows I often find URLs with WAV-Elements, which could be played with many other plugins, but mozilla only accepts QUICKTIME, what actually causes crashes.

> I think this bug should have a higher priority than "minor" and should be solved > soon. Are you willing to help? There are currently two people working on this code. We're both kinda swamped with things like crashers, security issues, and the like that need resolution immediately (like hopefully before 1.0). The key issue here is checking whether a type is handled "internally" (whatever that means). I _think_ content viewer creation is scriptable, and that would be the way to go if you decide to fix it -- try creating a content viewer for the type and if that works you disallow setting up a handler for the type.

Has there been any movement on this bug? I just had a faculty member using Netscape 7.0 run into this bug. I have a feeling he's going to be less than pleased with me when I tell him this isn't fixable easily, and he'll have to go back to NS 4.7. Is there any plan to fix this? Thanks, Dario

You probably have the wrong bug. This bug is about blocking ui modification of the settings for the MIME type. You want the bug about creating a back end to support such modifications (presumably for viewing of images and such). As for movement, read the comment right before yours, substitute "one" for "two".

I am trying to download an iso image file. http://mirrors.kernel.org/redhat/redhat/linux/9/en/iso/i386/shrike-i386-disc2.iso The server is telling my browser (mozilla 1.4a) that it is a text/plain type (see file header below) I go into preferences and create a test/plain type and use the extension 'iso' and tell mozilla that I would like to download files of that mime.type and extension. Mozilla ignores this and insists on displaying this 673 MB binary file on my screen. see file header below HTTP/1.1 206 Partial Content Date: Sun, 13 Apr 2003 19:16:38 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) Last-Modified: Fri, 14 Mar 2003 03:30:53 GMT ETag: "26b00a0-28620000-3e714ced" Accept-Ranges: bytes Content-Length: 673502680 Content-Range: bytes 4008488-677511167/677511168 Keep-Alive: timeout=5, max=1000 Connection: Keep-Alive Content-Type: text/plain

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

this shows how to do it it is (in this form) not ready for checkin, because it is unlocalizable, and the text is probably not ideal (This patch prevents people from creating helper app entries for types mozilla can handle internally)

I think it would be nicer to allow the helper apps to handle the mime types then prevent people setting it up!

I agree with Fredrik, this is not (imo) the correct way to solve this. It's not a bug to be fixed by disallowing the user to do this entirely, it's functionality that was there before, and *used* before. I'm not whining about this not being fixed, and if I could program at all, I'd offer to help, but that's not where my talents lie.

Please see the last paragraph of comment 0. You're talking about a totally separate issue.

exactly - I'll try to make such helper apps work (over in bug #58554), but that's far more difficult; if I won't be able to finish that bug for 1.5alpha, I'll finish this patch instead and check it in. which means I may just as well take this bug.

so I won't be able to finish the real fix for 1.5alpha... Here's a patch to warn the user when creating files that mozilla can handle internally (it still allows creating them)

Comment on attachment 127268 [details] [diff] [review] patch I can't help thinking that nsIPromptService::confirmEx has suboptimal syntax...

Comment on attachment 127268 [details] [diff] [review] patch r=me, but would this also say "Create Anyway" if you edit an existing entry to have, say, the text/html MIME type?

the previous patch did not allow creating types that mozilla can't handle internally... which was suboptimal bz: Yes, that warning would show up in such cases. I changed the button label to "Proceed anyway".

Hmm... What's the point of allowing the user to set such a type "anyway" if we're just gonna ignore it? Btw, you'll want to replace "Mozilla" in your .properties file with %S and substitute it with the right short brand name from JS.

jag: as the message says, if the server requests external handling (Content-Disposition:Attachment), the entry here will be used to prefill the dialog

Comment on attachment 127273 [details] [diff] [review] patch v2 Ah, the message wasn't that clear (to me) on first reading. sr=jag if you fix the hardcoded "Mozilla" to use the short brandname, and perhaps see if you can make the warning message more clear.

Checking in prefwindow/resources/content/pref-applications-edit.xul; /cvsroot/mozilla/xpfe/components/prefwindow/resources/content/pref-applications- edit.xul,v <-- pref-applications-edit.xul new revision: 1.43; previous revision: 1.42 done Checking in prefwindow/resources/locale/en-US/pref-applications.properties; /cvsroot/mozilla/xpfe/components/prefwindow/resources/locale/en-US/pref-applicat ions.properties,v <-- pref-applications.properties new revision: 1.6; previous revision: 1.5 done I used the wording "%brand% can handle this type internally. For such types, a Helper Application will only be invoked if the server requests external handling." To repeat: The bug to allow such helper apps to work is bug 58554.