Closed
Bug 78943
Opened 23 years ago
Closed 23 years ago
MIME type reported incorrectly for certain file extensions
Categories
(Core :: Networking, defect, P1)
Core
Networking
Tracking
()
RESOLVED
FIXED
mozilla0.9.7
People
(Reporter: law, Assigned: bzbarsky)
References
()
Details
(Keywords: testcase)
Attachments
(5 files, 2 obsolete files)
(deleted),
application/zip
|
Details | |
(deleted),
audio/midi
|
Details | |
(deleted),
audio/midi
|
Details | |
(deleted),
audio/midi
|
Details | |
(deleted),
patch
|
law
:
review+
mscott
:
superreview+
|
Details | Diff | Splinter Review |
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).
Updated•23 years ago
|
Comment 5•23 years ago
|
||
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.
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 ]).
Comment 7•23 years ago
|
||
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>
Assignee | ||
Comment 10•23 years ago
|
||
*** Bug 88231 has been marked as a duplicate of this bug. ***
Comment 11•23 years ago
|
||
Comment 12•23 years ago
|
||
Comment 13•23 years ago
|
||
Comment 14•23 years ago
|
||
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•23 years ago
|
||
->mscott? since bill is away, if you have cycles for this one...
Assignee: pchen → mscott
Comment 16•23 years ago
|
||
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
Comment 17•23 years ago
|
||
this doesn't really sound like an rtm stopper to warrant the nsbranch keyword.
What's the negative impact here?
Assignee | ||
Comment 18•23 years ago
|
||
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•23 years ago
|
||
clearing out the nsbranch keyword.
Status: NEW → ASSIGNED
Keywords: nsBranch
Comment 22•23 years ago
|
||
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•23 years ago
|
||
*** Bug 98950 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 24•23 years ago
|
||
*** Bug 86531 has been marked as a duplicate of this bug. ***
Comment 25•23 years ago
|
||
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Reporter | ||
Comment 26•23 years ago
|
||
*** Bug 104154 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.9
Reporter | ||
Comment 27•23 years ago
|
||
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).
Assignee | ||
Comment 28•23 years ago
|
||
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•23 years ago
|
||
*** Bug 107679 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 30•23 years ago
|
||
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.
Assignee | ||
Comment 31•23 years ago
|
||
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....
Assignee | ||
Comment 32•23 years ago
|
||
Bill, would you review?
Attachment #33217 -
Attachment is obsolete: true
Assignee | ||
Comment 33•23 years ago
|
||
taking this...
Assignee: mscott → bzbarsky
Status: ASSIGNED → NEW
Priority: P3 → P1
Target Milestone: mozilla0.9.9 → mozilla0.9.7
Assignee | ||
Comment 34•23 years ago
|
||
changing url because google now serves he right mime type
Status: NEW → ASSIGNED
Comment 35•23 years ago
|
||
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.
Assignee | ||
Comment 36•23 years ago
|
||
Attachment #59449 -
Attachment is obsolete: true
Reporter | ||
Comment 37•23 years ago
|
||
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!
Attachment #60332 -
Flags: review+
Comment 38•23 years ago
|
||
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+
Assignee | ||
Comment 39•23 years ago
|
||
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 40•23 years ago
|
||
*** 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.
Description
•