58557 - Mozilla allows you to override internal MIME types to no effect

Status: RESOLVED FIXED

(SeaMonkey :: Preferences, defect, P3)

Description

[Chris Siebenmann]

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

Comment 1

[Matthew T (active 1999-2002)]

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.

Comment 2

[Joseph Cheek]

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.

Comment 3

[sairuh (rarely reading bugmail)]

mscott, would this be yours?

Comment 4

[a_geek]

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!

Comment 5

[Christopher Hoess (gone)]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

Comment 9

[Tobias Kunze-Briseño]

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. 

Comment 10

[Tobias Kunze-Briseño]

also, maybe 67549 should be marked as a duplicate?

Comment 11

[Marty Combs]

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.

Comment 12

[Peter Lubczynski]

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

Comment 13

[Bill Law]

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.

Comment 14

[Rainer Bielefeld]

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.

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Dario Landazuri]

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Bob Gustafson]

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

Comment 19

[Boris Zbarsky [:bzbarsky]]

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

Comment 20

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: sample patch

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)

Comment 21

[Fredrik Ax]

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

Comment 22

[Dario Landazuri]

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.

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 25

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

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 26

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 127268 [details] [diff] [review]
patch

I can't help thinking that  nsIPromptService::confirmEx has suboptimal
syntax...

Comment 27

[Boris Zbarsky [:bzbarsky]]

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?

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch v2

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

Comment 29

[jag (Peter Annema)]

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.

Comment 30

[Christian :Biesinger (don't email me, ping me on IRC)]

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 31

[jag (Peter Annema)]

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.

Comment 32

[Christian :Biesinger (don't email me, ping me on IRC)]

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.