240942 - .EML files (message/rfc822) are shown as source code/plain text in browser window

Status: VERIFIED FIXED

(MailNews Core :: Networking, defect)

Description

[OstGote!]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a) Gecko/20040418 Netscape/7.1
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a) Gecko/20040418

Rendering is as expected if message is opened via remote url, see bug 239555
comment 14.

In Netscape 7.1 and Mozilla 1.6 it works. In Mozilla 1.7b it works too, I bet,
but I can't reproduce it any longer even with a new profile. Later 1.7b builds
like 2004040515 are regressed. I always did a clean uninstall before installation.

Reproducible: Always
Steps to Reproduce:
1. drag 'n' drop a local .EML to a browser window or open it via File -> Open
File  menu


Actual Results:  
Message is rendered as plain text.

Expected Results:  
Message is rendered like in Mozilla 1.6/Netscape 7.1, i.e. Headers in grey and
some header lines in bold like Subject etc. HTML-formatted e-mails displayed
correctly.

I selected this product/component because of bug 174692 comment 14.

Comment 1

[Mike Cowperthwaite]

It's possible the problem here doesn't have to do with the converter, but with 
whatever mechanism assigns a default MIME type to a particular file extension.

I assume this is also happening on Linux & Mac systems; can anyone confirm that?

Comment 2

[Boris Zbarsky [:bzbarsky]]

What MIME type does page info say the file is?

Comment 3

[Boris Zbarsky [:bzbarsky]]

And note
http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#394

Comment 4

[Robert Accettura [:raccettura]]

Well, I just tested with a .eml file on my harddrive and saw it as:
text/plain

Firefox nightly asks us what app we want to open it with, and calls it a
"Internet E-Mail Message".

I don't see how this could be fallout of bug 239555 as implied.  We don't in any
way touch how Mozilla would handle by default.  The *only* thing we do is add a
New open file dialog to MailNews, and route that all through the special URL
David specified.  That's all MailNews specific.

So I don't see any way that it could effect how the browser handles .eml files
(though ideally it should open them in MailNews)... we didn't implement that.

Comment 5

[Boris Zbarsky [:bzbarsky]]

So why is the EML file coming up as text/plain?  We have a specific mapping of
that extension to the rfc822 MIME type, so unless there is a specific setting
elsewhere (OS or user prefs) to override it, it should not render as text/plain.

Comment 6

[Robert Accettura [:raccettura]]

bz:

Here's the current patch:
http://bugzilla.mozilla.org/attachment.cgi?id=146146&action=view

I looked at it again, and I still don't see anything to account for it.  Your
more knowledgable than me.  But from what I see, I can't figure out any way for
this to take place from that patch.

Also note Neil did some cleanup that's pending
http://bugzilla.mozilla.org/attachment.cgi?id=146177&action=view

Comment 7

[David :Bienvenu]

stepping through the code, 

            nsCOMPtr<nsIMIMEService> mime = do_GetService("@mozilla.org/mime;1",
&rv);
            if (NS_SUCCEEDED(rv))
                mime->GetTypeFromFile(file, mContentType);

is not returning message/rfc822 type - it's returning empty or unknown...

mMIMEType in nsMIMEInfoBase is empty for eml...

will step through more.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Robert, that patch couldn't possibly have affected this bug.  ;)

David: that's sounding like a good lead...

Comment 9

[Robert Accettura [:raccettura]]

David,

Is this what you were referencing in comment 7:
http://lxr.mozilla.org/mozilla/source/netwerk/protocol/file/src/nsFileChannel.cpp#298

Comment 10

[David :Bienvenu]

yes, that's the place where we try to get the content type, but the failure is
happening at a lower level.

Comment 11

[David :Bienvenu]

yes, that's the place where we try to get the content type, but the failure is
happening at a lower level. Actually, I think I see the problem. Here, aTypeHint
is "" - it probably used to be null. A strlen check would probably fix this.

  LONG err = ::RegOpenKeyEx( HKEY_CLASSES_ROOT, fileExtToUse.get(), 0,
KEY_QUERY_VALUE, &hKey);
  if (err == ERROR_SUCCESS)
  {
    nsCAutoString typeToUse;
    if (aTypeHint) {
      typeToUse.Assign(aTypeHint);
    }
    else {
      LPBYTE pBytes = GetValueBytes( hKey, "Content Type");
      if (pBytes)
        typeToUse.Assign((const char*)pBytes);
      delete [] pBytes;
    }

Comment 12

[David :Bienvenu]

Attachment: potential fix

this fixes it for me (modulo the fact that nsOSHelperAppService.cpp seems to
have moved in cvs to \win... or something - my tree seems a bit confused.)

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 146513 [details] [diff] [review]
potential fix

r+sr=bzbarsky.	Though perhaps we should look into simply converting this
method to Mozilla strings...

Comment 14

[Robert Accettura [:raccettura]]

Damn you guys are quick ;-)

Comment 15

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

(In reply to comment #12)
> this fixes it for me (modulo the fact that nsOSHelperAppService.cpp seems to
> have moved in cvs to \win... or something - my tree seems a bit confused.)

Not quite... In CVS, that file has always lived in win\. However, when building,
that file gets copied to exthandler/, due to some deficiencies in make on
windows (or something like that. see the comments in the Makefile on that topic)

This was probably caused by my patch to make exthandler use ACString/AString
instead of string/wstring.. sorry :(

Comment 16

[David :Bienvenu]

thx, yes, I figured out that Makefile stuff, and I figured it was the ACString
stuff. No worries, now I know more about how that mime registry stuff works :-)

Comment 17

[David :Bienvenu]

fixed

Comment 18

[OstGote!]

> Damn you guys are quick ;-)
Yeah too quick for me to answer. Thanks!

Comment 19

[Mike Cowperthwaite]

Verified fixed:
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040420

Thanks, David!

Comment 20

[Stefan Borggraefe]

*** Bug 241346 has been marked as a duplicate of this bug. ***