If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Mozilla allows you to override internal MIME types to no effect

RESOLVED FIXED in mozilla1.5beta

Status

SeaMonkey
Preferences
P3
minor
RESOLVED FIXED
17 years ago
12 years ago

People

(Reporter: Chris Siebenmann, Assigned: Biesinger)

Tracking

Trunk
mozilla1.5beta

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

17 years ago
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.)
QA Contact: sairuh → shrir

Updated

17 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 1

17 years ago
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

17 years ago
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?
Assignee: matt → mscott

Comment 4

16 years ago
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. ***

Comment 9

16 years ago
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?

Comment 11

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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.

Comment 16

15 years ago
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".
Blocks: 189601

Comment 18

15 years ago
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
QA Contact: shrir → petersen
*** Bug 208877 has been marked as a duplicate of this bug. ***
Created attachment 126901 [details] [diff] [review]
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

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

Comment 22

14 years ago
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.
Assignee: mscott → cbiesinger
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → mozilla1.5alpha
Target Milestone: mozilla1.5alpha → mozilla1.5beta
Created attachment 127268 [details] [diff] [review]
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)
Attachment #126901 - Attachment is obsolete: true
Comment on attachment 127268 [details] [diff] [review]
patch

I can't help thinking that  nsIPromptService::confirmEx has suboptimal
syntax...
Attachment #127268 - Flags: review?(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?
Attachment #127268 - Flags: review?(bzbarsky) → review+
Created attachment 127273 [details] [diff] [review]
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".
Attachment #127268 - Attachment is obsolete: true
Attachment #127273 - Flags: review?(bzbarsky)
Attachment #127273 - Flags: review?(bzbarsky) → review+
Attachment #127273 - Flags: superreview?(jaggernaut)

Comment 29

14 years ago
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 31

14 years ago
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.
Attachment #127273 - Flags: superreview?(jaggernaut) → superreview+
Status: NEW → ASSIGNED
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
No longer blocks: 189601
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.