wrong mime type displayed and file extension added

NEW
Unassigned

Status

()

--
major
15 years ago
2 years ago

People

(Reporter: bladerunner, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
Created attachment 134168 [details]
Simple testcase using PHP & content-type message/rfc822

Simple PHP script for testing
(Reporter)

Comment 2

15 years ago
Created attachment 134169 [details]
testcase screenshot
(Reporter)

Updated

15 years ago
Attachment #134168 - Attachment is obsolete: true
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?
(Reporter)

Comment 4

15 years ago
Created attachment 134171 [details]
Simple testcase using PHP & content-type message/rfc822
(Reporter)

Comment 5

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

Comment 6

15 years ago
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)

Comment 8

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

Updated

15 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?

Comment 14

13 years ago
(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

9 years ago
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

Updated

2 years ago
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.