344278 - using "save as" function of horde webmail breaks .eml format when saving

Status: VERIFIED FIXED

(SeaMonkey :: Download & File Handling, defect)

Description

[Alessio]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 SeaMonkey/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 SeaMonkey/1.0.2

When using the "save as" function of the Horde webmail (which is used to export an email in .eml format) Mozilla "strips" the received stream and save it as an html file, corrupting the eml file format.
This does NOT happen with Firefox and Internet Explorer, but happens only with Mozilla 1.7.x and Seamonkey 1.x.
Also, this is NOT an Horde problem: the http stream which is being sent to the browser is right, it contains the data of an eml file, but whem Mozilla saves it on disk, it seems it saves an html file with another content.

Reproducible: Always

Steps to Reproduce:
1. go to http://demo.seastarnet.com:2095/horde/index.php
2. login as uid: demo pwd: seastarnet
3. on the left-side menu, go to mail->sent mail
4. open the last email (subject:"test")
5. click on "save as" in the upper-right side
6. download the .eml file which is being sent
7. open the file with a text editor and see its content


Actual Results:  
Invalid html data is being saved on disk instead of the full eml data received by the browser.

Expected Results:  
A vaild .eml format file.
Repeat the same testcase with Firefox and Internet Explorer, then see the differences between the files which will be saved on disk.

Comment 1

[Alessio]

It seems someone else is experiencing this bug with Seamonkey 1.5a too, see 4th post here: http://forums.mozillazine.org/viewtopic.php?p=2379410#2379410

Comment 2

[Andy Boze]

Attachment: test.eml file as downloaded by SeaMonkey 1.5a

Comment 3

[Andy Boze]

Attachment: test.eml file as downloaded by IE 6.0

Comment 4

[Alessio]

This bug could be a regression, since it's present on Mozilla 1.7.12, Seamonkey 1.0.2 and Seamonkey 1.5a, but it's NOT present in Seamonkey 1.1a and Firefox 1.5

Comment 5

[Tony Mechelynck [:tonymec]]

Alessio, is it present in current builds of Sm 1.1.8 (or somesuch) and/or Sm 2.0a1pre ?

Comment 6

[Alessio]

still the same problem on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8

it works fine on Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

Comment 7

[Philip Chee]

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1.6pre) Gecko/20091128 Lightning/1.0pre SeaMonkey/2.0.1pre

HTTP/1.x 200 OK
Server: cpsrvd/11.24
Connection: close
X-Powered-By: PHP/5.2.6
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: message/rfc822
Content-Disposition: attachment; filename="ddddddddddd.eml"
Content-Length: 3544

So the server is sending the right mime type but somehow we are detecting it wrongly as html. Firefox does the right thing.

Comment 8

[[e-mail]]

SeaMonkey has a message/rfc822 -> text/html stream converter. Maybe that's getting invoked even though the message is served as an attachment? I don't know how I can tell though.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Maybe that's getting invoked even though the message is served as an attachment?

Almost certainly yes, given this comment in nsDocumentOpenInfo::DispatchContent:

531   // Fifth step:  If no listener prefers this type, see if any stream
532   //              converters exist to transform this content type into
533   //              some other.
534   //
535 
536   // We always want to do this, since even content being forced to
537   // be handled externally may need decoding (eg via the unknown
538   // content decoder).

Arguably we should move this step into the !forceExternalHandling block and do something better for the unknown decoder (e.g. make it the channel's responsibility).  I would be fine with that; pretty sure that HTTP already does that.  Happy to review a patch to that effect if someone wants to write one and lists what channel impls they audited.  The other option is changing the message/rfc822 converter to not trigger for Content-Disposition: attachment or something.  Could be done, of course.

As for figuring out whether this is in fact what happens, a URILoader:5 NSPR log (in a debug build) should tell you that.  I'd be happy to look at such a log to double-check if someone points me to one.

Comment 10

[[e-mail]]

Attachment: URILoader:5

Assuming I'm looking at the right part of the log file, my suspicions as to the automatic conversion from message/rfc822 to text/html appear to be correct.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Yep.  Here's the relevant log bit:

0[c85148]: [0x7904420] nsDocumentOpenInfo::DispatchContent for type ''
0[c85148]:   Got type from channel: 'message/rfc822'
0[c85148]:   Disposition header: 'attachment; filename="http___www.seastarnet.com.sg_cpaneldemo.php.eml"'
0[c85148]:   forceExternalHandling: yes
0[c85148]: [0x7904420] nsDocumentOpenInfo::ConvertData from 'message/rfc822' to '*/*'
0[c85148]:   Got converter service
0[c85148]:   Downstream DocumentOpenInfo would be: 0x81771a8
0[c85148]:   Converter taking over now

Comment 12

[Boris Zbarsky [:bzbarsky]]

The testcase in comment 0 doesn't work anymore (no more sent mail there), so I can't tell whether my fix for bug 537120 fixes this, but it should.

Comment 13

[Alessio]

(In reply to comment #12)
> The testcase in comment 0 doesn't work anymore (no more sent mail there), so I
> can't tell whether my fix for bug 537120 fixes this, but it should.

just go to the "drafts" folder, there's a test message.
if not, you can create a draft message by yourself and test the "save as" function.

Comment 14

[Alessio]

(In reply to comment #5)
> Alessio, is it present in current builds of Sm 1.1.8 (or somesuch) and/or Sm
> 2.0a1pre ?

this bug is present in seamonkey 2.0.4 too:
Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4

Comment 15

[Boris Zbarsky [:bzbarsky]]

Oh, hmm.  This is seamonkey-only, isn't it?

I'll work on getting a seamonkey build up, but that's not happening today.

Comment 16

[Alessio]

(In reply to comment #15)
> Oh, hmm.  This is seamonkey-only, isn't it?

just tried with firefox 3.6.3 and it works fine.
Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)

Comment 17

[Philip Chee]

> just tried with firefox 3.6.3 and it works fine.
It always worked fine in Firefox. This is a SeaMonkey only problem.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Philip, do you already have a seamonkey build on hand?  If so, can you test the patches in bug 537120?

Comment 19

[Philip Chee]

Yes but I won't have time until next week.

Comment 20

[Philip Chee]

confirmed fixed in the latest trunk self build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100419 Lightning/1.1a1pre SeaMonkey/2.1a1pre