223731 - wrong mime type displayed and file extension added

Status: RESOLVED INCOMPLETE

(Firefox :: File Handling, defect)

Description

[Toomas Kask]

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.

Comment 1

[Toomas Kask]

Attachment: Simple testcase using PHP & content-type message/rfc822

Simple PHP script for testing

Comment 2

[Toomas Kask]

Attachment: testcase screenshot

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

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?

Comment 4

[Toomas Kask]

Attachment: Simple testcase using PHP & content-type message/rfc822

Comment 5

[Toomas Kask]

Previous script was a little bit buggy. Now it works with Internet Explorer
too...  :-)))

Comment 6

[Mats Palmgren (inactive)]

WFM, 2003-10-25-05 trunk Linux. (The file name is "mymessage.eml")

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

mats, the interesting thing is the mime type, not the filename. current builds
will not do extension fixup, on no os (in this dialog)

Comment 8

[Mats Palmgren (inactive)]

Yeah, I realized 1 second after I hit submit :-)   Ignore my WFM comment.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 13

[Boris Zbarsky [:bzbarsky]]

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?

Comment 14

[sendmail.to]

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

Comment 15

[klonos]

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?

Comment 16

[Timea Cernea [:tbabos][inactive]]

Closing this as resolved incomplete. The attached testcase, even if it is served via a https server, does not reproduce the issue for me locally. If this issue is still reproducible for you on the latest Firefox version, please do re-open it. Thanks!