Closed Bug 78943 Opened 24 years ago Closed 23 years ago

MIME type reported incorrectly for certain file extensions


(Core :: Networking, defect, P1)






(Reporter: law, Assigned: bzbarsky)




(Keywords: testcase)


(5 files, 2 obsolete files)

This bug is to track a quirk that remains in the uriloader/exthandler and helper
app dialog code.  I had to back out one fix (part of bug 52454) in order to not
crash when clicking on a link to

The server says the content type is "text/xul".  We look up the extension in the
mime info cache and the type is inferred to be "appliation/vnd.mozilla.xul+xml".
 But only sort of.  We don't display it as xul and show the helper app dialog.

The dialog says "Mozilla doesn't handle application/vnd.mozilla.xul+xml" which
is a lie.  I think that bug has been reported elsewhere (I'm opening a new one
so I can track this next problem).

I've got a patch for this first bug (so the dialog properly reports the mime
type as being "text/xul").  However, the resulting dialog doesn't work due to
some snafu in the uriloader.

Coming is the attachment to fix the dialog (and avoid the crash when the line of
code in question was inserted without this extra code).
Blocks: 46655
Blocks: 78106
mass move, v2.
qa to me.
QA Contact: tever → benc
Keywords: nsbeta1
Keywords: nsbeta1nsbeta1+
Priority: -- → P3
Target Milestone: --- → mozilla0.9.3
Looks like application/zip works OK in build 2001060104 Win98.
here's a testcase (at least for my purposes :) which exhibits this bug, mostly
gleaned from bug 79631. the key is trying to do the download from http (not

1. create the following mime-type in the Helper Applications prefs panel:
   Description: Zip
   mime type: application/x-zip-compressed
   extension: zip
   "ask me before opening downloaded files of this type" is selected
   action: save to disk [will need to save the mime-type, then edit to actually
set this part].

2. click on a link to a .zip file on an http page [but *not* an ftp listing],
eg: go to, scroll down to the section with "A
medium file" [those are all .zip files], and click on the "via http" link:

3. the new downloading/helper app dialog appears. "Use default action" is
selected, but the textfield is blank [bug 79231]; do not change the settings,

4. click OK.

* download progress dialog appears, and the file is saved to the temp [default]
directory, C:\TEMP\[garbage-name].zip
* a split second after the download progress dialog appears, the WinZip
application appears.
Keywords: testcase
Sai: Your site doesn't resolve for me. However, if it is sending the file as
application/zip (you never told us what MIME type the download dialog gives
you), this is what happens. Even though it's strange and should get its own bug,
this is what you see for unknown file types (Use default action [ blank ]).
when i click on a .zip from an ftp listing, the description for "You have chosen
to download a file of type:" is

    "application/zip" [application/x-zip-compressed] from <ftp path>

when i click on a .zip from an http page, the description is:

    "WinZip file" [application/x-zip-compressed] from <http path>
-> pchen
Assignee: law → pchen
Keywords: nsBranch
please update component and qa.
*** Bug 88231 has been marked as a duplicate of this bug. ***
Attached audio MIDI test (audio/midi)
Attached audio MIDI test (audio/midi)
Attached audio MIDI test (audio/midi)
Shoot! Stupid unreliable Bugzilla server.

Uh, click... one of those. File type is reported as audio/mid. Neither
audio/midi nor audio/mid are registered MIME types.
->mscott? since bill is away, if you have cycles for this one...
Assignee: pchen → mscott
pchen, blake, mscott: what's the status of this patch? have any of you been able
to test it to see if it could be checked in soon? thx!
Severity: normal → major
this doesn't really sound like an rtm stopper to warrant the nsbranch keyword.
What's the negative impact here?
From bug 88231:

I choose always open it with e.g. winamp, but the problem is that the MIME type
of the file wasn't audio/x-mpegurl but audio/mpeg-url. So it keeps asking me
every time. It seems that it reads correctly the MIME type, but then tries to
set up a helper for *another* MIME type. The only way to install the helper is
to edit the MIME type in the preferences, and change it to the correct one.

This makes it impossible to set a handler using the "Set Default" button in some

There is also another pathological possibility -- a perception issue.  If we get
a file with an unknown type, do the extension-->type mapping, and discover that
it's a type we handle internally (eg text/html) then we do not handle it but put
up a dialog!  So we get dialogs saying we can't handle text/html.  This does not
look good at all.  See bug 46655 for more discussion of this problem (arguably,
46655 and this are dups of each other....)
Blocks: 86531
clearing out the nsbranch keyword. 
Keywords: nsBranch
moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
triage --> .9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
law: what's the status of this patch? People are still getting confused on a
regular basis by Mozilla telling them it can't handle text/html... :-)

*** Bug 98950 has been marked as a duplicate of this bug. ***
*** Bug 86531 has been marked as a duplicate of this bug. ***
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
*** Bug 104154 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.6 → mozilla0.9.9
Sorry, I was out of the loop on this bug...Scott, can you answer Gerv's 

I just ran into another bug (bug 98950) that could be a dup of this (or at 
least related).
So the issue here is the following.  We can't reset the type on the mimeinfo
because that would blow away whatever was in the cache as that type already.

The only reason this bug exists at the moment is that the following scenario
causes problems:

1)  Have an entry in the mimeinfo cache for type="foo/bar" extension="baz"
2)  Get something of type="unknown/unknown" extension="baz"
3)  Look up "baz" in the cache
4)  Take the resulting mimeinfo and set its type to unknown/unknown

When "baz" is "xul" this breaks badly.

So possible options:

1)  Make a _copy_ of the mime info when getting from cache.  This way the caller
    can fuck with it all they want and it's not a problem.  Since XUL loads
    before anything else with the "xul" extension, the XUL mime info in the
    cache would be correct.
2)  Add an "original type" member to the mimeinfo.  This would be used both for
    the "set default" stuff and for display purposes.  If we do this we should
    make sure that we _always_ set this in DoContent()
3)  Special-case known types (xul, html, etc) and not reset the content-type for
    those.  This does not solve the display problem ("can't handle text/html")
    and and just generally sounds icky.

I think I like option 2 the most.  comments?

Oh, and as far as text/html and other "internal" types are concerned... should
we not initialize the mimeinfo for those with "handle internally, don't ask"? 
That would certainly help with this problem, no?
*** Bug 107679 has been marked as a duplicate of this bug. ***
 I like option 1 the best, because the fix is simpler (and I've already coded 
it up and attached it to this bug).  It also prevents problems down the road 
where other callers might unwittingly modify the nsIMIMEInfo they get from the 
mime service.  I don't think the real live cache entries should ever be exposed 
outside the mime service proper.
OK, option 1 works fine as long as we're careful never to put something in the
cache if it came from cache (not too hard since only the mime service should be
adding things to the cache).  So we need some way to Clone an nsIMIMEInfo....
Attached patch Patch implementing approach 1 (obsolete) — Splinter Review
Bill, would you review?
Attachment #33217 - Attachment is obsolete: true
taking this...
Assignee: mscott → bzbarsky
Priority: P3 → P1
Target Milestone: mozilla0.9.9 → mozilla0.9.7
changing url because google now serves he right mime type
Note that nsIURI::Clone will fails for some mailnews uris. This is because the
mailnews specific schemes don't register a protocol handler, so when NS_NewURI
is called, it can't work out what to do.

See bug 31241, and the problems I have in bug 44995, comment #39 among others.

The 'solution' I used there isn't valid here, however.
Depends on: 31241
Comment on attachment 60332 [details] [diff] [review]
Patch v1.1 -- assert on Clone() failure for uris and files


Sorry for the delay.  I can't keep up with my bugmail lately; if something is
urgent, email me directly!
Attachment #60332 - Flags: review+
Comment on attachment 60332 [details] [diff] [review]
Patch v1.1 -- assert on Clone() failure for uris and files

sr=mscott thanks for your patience.
Attachment #60332 - Flags: superreview+
Checked in.
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 46655 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.