78943 - MIME type reported incorrectly for certain file extensions

Status: RESOLVED FIXED

(Core :: Networking, defect, P1)

Description

[Bill Law]

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 http://www.google.com/mozilla/google.xul.

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

Comment 1

[Bill Law]

Attachment: Patch to fix dialog in most cases (except text/xul)

Comment 2

[benc]

mass move, v2.
qa to me.

Comment 3

[Skewer]

Attachment: application/zip testcase

Comment 4

[Skewer]

Looks like application/zip works OK in build 2001060104 Win98.

Comment 5

[sairuh (rarely reading bugmail)]

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

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 http://law.mcom.com/download.html, scroll down to the section with "A
medium file" [those are all .zip files], and click on the "via http" link:
http://law.mcom.com/medium.zip

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

4. click OK.

results:
* 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.

Comment 6

[Skewer]

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

Comment 7

[sairuh (rarely reading bugmail)]

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>

Comment 8

[Viswanath Ramachandran]

-> pchen

Comment 9

[benc]

please update component and qa.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Skewer]

Attachment: MIDI test (audio/midi)

Comment 12

[Skewer]

Attachment: MIDI test (audio/midi)

Comment 13

[Skewer]

Attachment: MIDI test (audio/midi)

Comment 14

[Skewer]

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.

Comment 15

[sairuh (rarely reading bugmail)]

->mscott? since bill is away, if you have cycles for this one...

Comment 16

[sairuh (rarely reading bugmail)]

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!

Comment 17

[Scott MacGregor]

this doesn't really sound like an rtm stopper to warrant the nsbranch keyword.
What's the negative impact here?

Comment 18

[Boris Zbarsky [:bzbarsky]]

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

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

Comment 19

[Scott MacGregor]

clearing out the nsbranch keyword. 

Comment 20

[scottputterman]

moving to 0.9.4

Comment 21

[Scott MacGregor]

triage --> .9.5

Comment 22

[Gervase Markham [:gerv]]

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

Gerv

Comment 23

[gabriel]

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

Comment 24

[Bill Law]

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

Comment 25

[Asa Dotzler [:asa]]

0.9.5 is out the door. bumping TM up by one.

Comment 26

[Bill Law]

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

Comment 27

[Bill Law]

Sorry, I was out of the loop on this bug...Scott, can you answer Gerv's 
question?

I just ran into another bug (bug 98950) that could be a dup of this (or at 
least related).

Comment 28

[Boris Zbarsky [:bzbarsky]]

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?

Comment 29

[sairuh (rarely reading bugmail)]

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

Comment 30

[Bill Law]

 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.

Comment 31

[Boris Zbarsky [:bzbarsky]]

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

Comment 32

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch implementing approach 1

Bill, would you review?

Comment 33

[Boris Zbarsky [:bzbarsky]]

taking this...

Comment 34

[Boris Zbarsky [:bzbarsky]]

changing url because google now serves he right mime type

Comment 35

[Bradley Baetz (:bbaetz)]

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.

Comment 36

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch v1.1 -- assert on Clone() failure for uris and files

Comment 37

[Bill Law]

Comment on attachment 60332 [details] [diff] [review]
Patch v1.1 -- assert on Clone() failure for uris and files

r=law

Sorry for the delay.  I can't keep up with my bugmail lately; if something is
urgent, email me directly!

Comment 38

[Scott MacGregor]

Comment on attachment 60332 [details] [diff] [review]
Patch v1.1 -- assert on Clone() failure for uris and files

sr=mscott thanks for your patience.

Comment 39

[Boris Zbarsky [:bzbarsky]]

Checked in.

Comment 40

[Boris Zbarsky [:bzbarsky]]

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