User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Mozilla displays wrong mime type and adds wrong file extension. Reproducible: Always Steps to Reproduce: 1. go to http://bladerunner.dyn.ee/test.php (this is not 24h up, sorry) 2. submit form 3. either choose 'Open it with the default application' or 'Save it to disk' Actual Results: Mozilla opens this file in browser not in MS Outlook as expected or saves as file named 'mymessage.eml.htm' not 'mymessage.eml'! I added 'message/rfc822' to Mozilla Helper Applications list with no luck.
Created attachment 134168 [details] Simple testcase using PHP & content-type message/rfc822 Simple PHP script for testing
this is a fun bug bz, thanks for your uriloader logging patch. that was helpful here. So what happens is this: 1. we see the message/rfc822 content type 2. we find out we can't display it and look for a converter 3. we find one: message/rfc822 -> text/html, and we use it (the comment says we do want conversion even if we handle this externally...) 4. so we pass it off to another DocumentOpenInfo 5. that one notices the content-disposition:attachment header, and brings up the helper app dialog. with a text/html content type. do we have to change the content type on the channel when doing conversions?
Previous script was a little bit buggy. Now it works with Internet Explorer too... :-)))
WFM, 2003-10-25-05 trunk Linux. (The file name is "mymessage.eml")
mats, the interesting thing is the mime type, not the filename. current builds will not do extension fixup, on no os (in this dialog)
Yeah, I realized 1 second after I hit submit :-) Ignore my WFM comment.
Hmm... We do want to change the type on the channel when doing conversions; otherwise, how will the downstream listener know what type we converted to? I'm hard-pressed to come up with decoders other than nsUnknownDecoder that would need to be run on attachments.... can you think of any? Maybe the binhex decoder? Even that is questionable... Perhaps we should decode if (!forceExternalHandling || mContentType == UNKNOWN_CONTENT_TYPE) ?
> otherwise, how will the downstream listener know what type we converted to? I thought it got handed the type directly... ah, it does: nextLink->mContentType = aOutContentType; (hm.. at least sometimes) >Maybe the binhex decoder? I think we do want to use the binhex decoder.... otherwise we get an inconsistency between disposition:attachment and :inline, in that such files only get decoded for inline attachment... Other than the unknown decoder and binhex, I can't think of converters that we would want to use if forceExternalHandling is true.
> I thought it got handed the type directly... The nsDocumentOpenInfo may... but the final listener (eg nsParser) just gets the channel. So in fact stream converters MUST change the type on the channel. See, for inline attachment for a file we know how to display (eg a binhexed HTML file) we _do_ perhaps want to decode from binhex. And I think we want to binhex decode actual honest-to-god e-mail attachments... So yes, we want to use the binhex decoder there. Maybe we should try to categorize converters in some sane way with a relevant flag? Then pass an arg to the converter service so it will only use the "right" converters? I'm not sure how to define "right" in this case, though....
> So in fact stream converters MUST change the type on the channel. ah, that makes sense > I'm not sure how to define "right" in this case, though.... difficult question. we could name the flag "don't apply when handling externally", but that really just moves the decision down to the converters. how about "doesn't semantically change the content"? message/rfc822 converter does that, it causes dataloss and changes the representation of the data. the unknown decoder just sets a different content type; and binhex uncompresses (un-encodes?) it.
Ah, yes. That's exactly the distinction I was looking for. Note that for, eg, binhex, this will still result in the "wrong" mime type being shown in this dialog... is that something to worry about? darin? Thoughts?
(In reply to comment #0) > Actual Results: > Mozilla opens this file in browser not in MS Outlook as expected or saves as > file named 'mymessage.eml.htm' not 'mymessage.eml'! > Is this Bug fixed? When trying the testcase, Firefox offers me "open that file 'mymessage.eml' with Outlook".
Trying to confirm this one, but the test cases open as php code. Am I supposed to save this in my server and try it?
Assignee: file-handling → nobody
QA Contact: file-handling
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.