707631 - Double click on .eml files does not open standalone-Mail-window. Associate .eml files with the mail handler.

Status: ASSIGNED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[hkroll]

Attachment: example_mail-window.bmp

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0.1) Gecko/20111121 Firefox/8.0.1 SeaMonkey/2.5
Build ID: 20111121045514

Steps to reproduce:

I saved an e-mail from mail client of seamonkey 2.5 to the windows desktop by
using "save as ..." function.
I could also move the e-mail directly from mail client to desktop by dragging & dropping
it out from mail client window.

Afterwards i tried to open the saved mail with double click.


Actual results:

After double click, browser and mail client of seamonkey are opened (in the way as it is configured in the preferences, appearance); e-mail is NOT shown.
By using the windows function "open with ..." i changed the behaviour that way, that
e-mail text now is shown in browser window, BUT: attachment can't be opened anyway and mail e. g. can't be forwarded.


Expected results:

Seamonkey mail client should open the e-mail in the way, it opens e-mails, when double clicking them DIRECTLY in the mail client window; means:
showing all attachements with open/save, pictures possibly embedded, forwarding function and so on; please refer to attached file!

Maybe the question is: Why do i use the function this way and don't save Mails
directly via mail client? The answer is simple: Sometimes i need to archive Mails 
browser independent in a separate folder, e. g., for security reasons.

I also found known or solved bugs, that seem to be very similar. But i can't 
confirm that they're solved: With version 2.5 and also older versions of seamonkey the problem still exists.
(The found bug for seamonkey is: Bug 465581 and for Thunderbird: Bug 217149 and Bug 261559)

Comment 1

[Philip Chee]

Workaround: In the main Mail 3pane window do File->Open File, then select the .eml file you saved.

Comment 2

[hkroll]

(In reply to Philip Chee from comment #1)
> Workaround: In the main Mail 3pane window do File->Open File, then select
> the .eml file you saved.

Thanks for reply, yeah, i know that possiblity. But: Opening all mails with "File->open file" means navigating everytime to the different folders, where .eml files are placed, using the "open file window". Opening with double clicking by means of windows explorer is explicitly easier to use for that case, in my eyes.

Comment 3

[Karsten Düsterloh]

Using SM 2.8a1 under WinXP, with .eml registered for SM, double clicking opens the message in a browser window, which is neither intended nor expected behaviour.

Comment 8

[Martin F.]

Build-Identifikator: Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20111221 Firefox/9.0.1 SeaMonkey/2.6.1

Double-Clicking *.eml-Files just opens an *empty* browser window here. 
Only if one removes the -osint -mail parameters for the opening-handler of eml-Files it will load the message in the browser window as Karsten Düsterloh described. 
These parameters were not added by me, so the default handler for eml-files
[Path_to_Seamonkey]\seamonkey.exe -osint -mail "%1" 
seems to result in no opening at all.

Comment 9

[Philip Chee]

> [Path_to_Seamonkey]\seamonkey.exe -osint -mail "%1" 
> seems to result in no opening at all.
Frank, this seems to be your area of expertise. Any idea why this is not working?

Comment 10

[Philip Chee]

Neil sez:
"well, there are several options there,
1) -osint is supposed to work with -mail but it doesn't
2) -mail is supposed to open a .eml file but it doesn't
3) -mail is not supposed to open a .eml file"

Comment 11

[Tony Mechelynck [:tonymec]]

BTW, what does -osint do? It is not listed by "seamonkey -h" (at least, not on my L64 nightly)

Comment 12

[Jens Hatlak (:InvisibleSmiley)]

(In reply to Tony Mechelynck [:tonymec] from comment #11)
> BTW, what does -osint do? It is not listed by "seamonkey -h" (at least, not
> on my L64 nightly)

https://developer.mozilla.org/en/Command_Line_Options#-osint; bug 384384 comment 33

Basically, from what I understand, it's to be used when a Mozilla-based application registers itself as default handler for certain protocols or file types on Windows. No idea whether it still works (as expected) or is still used during the process of registration.

Comment 13

[Martin F.]

"still works" is interesting. SM2.0x didn't seem to register with -osint (at least there is no -osint and no -mail for *.eml-Files on WinXP with SM 2.0.6, it appears to be rather new to me(?)

Comment 14

[hkroll]

Could anybody explain to a newbie, why Status "new" and resolved as "invalid"?
It still doesn't work.

Comment 15

[Jens Hatlak (:InvisibleSmiley)]

(In reply to hkroll from comment #14)
> Could anybody explain to a newbie, why Status "new" and resolved as
> "invalid"?

No idea where you saw "invalid", but "NEW" means "confirmed: this is an issue but no-one is currently working on it".

Comment 16

[Philip Chee]

When Javascript is turned off, all the hidden fields are displayed including Status/Resolved etc. It's a bit confusing that way.

Comment 17

[Tony Mechelynck [:tonymec]]

(In reply to hkroll from comment #14)
> Could anybody explain to a newbie, why Status "new" and resolved as
> "invalid"?
> It still doesn't work.

Not only the present bug is not currently resolved as INVALID, its History shows that it never was.

FYI (and OT for a bug comment which is not supposed to be help or support) the bug could have been RESOLVED INVALID, even after having been confirmed by turning it from UNCONFIRMED to NEW, in the following cases:
-- the behaviour is intentional (i.e., “T'ain't a bug, it's a feature”)
-- there is a bug, but it isn't a Mozilla bug (e.g. an MS-Windows bug, a GTK bug, an OSX bug, a bug in some web page, etc.)
-- the reporter misunderstood what was happening, and reported something different than what was actually happening.
See also https://developer.mozilla.org/en/What_to_do_and_what_not_to_do_in_Bugzilla#Resolving_bugs and scroll down to “Resolving bugs as INVALID”

Comment 18

[hkroll]

Sorry & Thanks (it was the Java script issue - Comment 16);
So i assume it's still seen as a bug to be solved.

Comment 19

[Frank Wein [:mcsmurf]]

The -osint argument was introduced to fix a security issue (Bug 384384), this argument is something that the normal user does not need to use (that's also why it does not appear in seamonkey.exe -help). It's only used internally when other apps open SeaMonkey.
Currently the installer sets the file handler to just pass the .eml file to SeaMonkey. That's wrong though as !macro UpdateProtocolHandlers overwrites this with ""$\"$8$\" -osint -mail $\"%1$\"" (which does not work either...).

So there are two issues:
1) Sync UpdateProtocolHandlers and SetHandlersMail so that both set the same file handler for .eml files. SetHandlersMail gets called when setting SeaMonkey as default mail client, the other function gets called by the installer and after updating SeaMonkey via the in-app update function.
2) Modify http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMailNewsCommandLineHandler.js (or a related file in the call-chain) so that it can handle files passed from the command-line. I looked at this with Venkman, it ends up here: http://hg.mozilla.org/comm-central/annotate/5dae8feffefe/mailnews/base/src/nsMailNewsCommandLineHandler.js#l73
"    73        // Necko URL, so convert it into a message header
[...]
    76          neckoURL = Services.io.newURI(mailURL, null, null);"
(mailURL at this time is the Windows path, so C:\\bla\\blub.eml).

Then it does this:
"82 if (neckoURL instanceof Ci.nsIMsgMessageUrl)
83 msgHdr = neckoURL.messageHeader; "

Then at this point I'm not sure what happens, someone needs to check (I'm confused by what Venkman displays there).

Comment 20

[Frank Wein [:mcsmurf]]

Also see Bug 467768 on this, this changed the logic in TB quite a while ago how it handles .eml files.

Comment 21

[rsx11m]

Please leave at "Trunk" (i.e., current development) as the highest affected version.

Comment 22

[Gregor Dschung]

I'm still believing introducing a new commandline switch as proposed in Bug 571841 is the simplest way to fix this issue.

Comment 23

[Zane U. Ji]

ThunderBird doesn't have such problem. It has some unique code to deal with the situation:
https://mxr.mozilla.org/comm-central/source/mail/components/nsMailDefaultHandler.js#152

I was wondering if we should port that nsMailDefaultHandler.js to SM as well.

Comment 25

[[e-mail]]

We'd also have to associate .eml files with the mail handler...

Comment 26

[Philip Chee]

(In reply to Jens Hatlak (:InvisibleSmiley) from comment #24)
> *** This bug has been marked as a duplicate of bug 1164817 ***

(In reply to [e-mail] from comment #25)
> We'd also have to associate .eml files with the mail handler...

RE-OPENED.

Comment 27

[Philip Chee]

From Bug 1164817 Comment 0:
> so next - for windows clients set registry:
> HKEY_CURRENT_USER\Software\Classes\SeaMonkeyEML\shell\open\command
> "C:\Program Files (x86)\SeaMonkey\seamonkey.exe" -mail "%1"
> and .eml files opens by double-click ...

> http://mxr.mozilla.org/comm-central/source/suite/shell/src/nsWindowsShellService.cpp?rev=9281c70c7224#149
> //   HKCU\SOFTWARE\Classes\.eml         (default)         REG_SZ    SeaMonkeyEML
> //
> //   That aliases to this class:
> //   HKCU\SOFTWARE\Classes\SeaMonkeyEML\ (default)        REG_SZ    SeaMonkey (Mail) Document
> //                                      FriendlyTypeName  REG_SZ    SeaMonkey (Mail) Document
> //     DefaultIcon                      (default)         REG_SZ    <appfolder>\chrome\icons\default\misc-file.ico
> //     shell\open\command               (default)         REG_SZ    <apppath> "%1"

> http://mxr.mozilla.org/comm-central/source/suite/shell/src/nsWindowsShellService.cpp?rev=9281c70c7224#245
> #define VAL_MAIL_OPEN "\"%APPPATH%\" \"%1\""
This should proably be changed to:
#define VAL_MAIL_OPEN "\"%APPPATH%\" -mail \"%1\""

Comment 28

[hkroll]

I just tried it out again with seamonkey-version 2.46:

When i MANUALLY change hotkey >HKEY_CURRENT_USER\Software\Classes\SeaMonkeyEML\shell\open\command<
from >"C:\Program Files (x86)\SeaMonkey\seamonkey.exe" "%1"<
to >"C:\Program Files (x86)\SeaMonkey\seamonkey.exe" -mail "%1"<
then IT WORKS as it should!

So, it seems, that Philip Chees assumption is right!

Fixing that issue would be great!

Comment 29

[Frank-Rainer Grahl (:frg)]

Attachment: 707631-handlermail-2539.patch

This works for me and Windows. Setting -osint seems to cause no problems under the supported OS versions so just match the other handlers.

[Approval Request Comment]
Regression caused by (bug #): --
User impact if declined: Saved mails will open in the browser.
Testing completed (on m-c, etc.): 2.53.9
Risk to taking this patch (and alternatives if risky): trivial.
String changes made by this patch: --

Comment 30

[Ian Neal]

Comment on attachment 9224333 [details] [diff] [review]
707631-handlermail-2539.patch

[Triage Comment]
r/a=me

Comment 31

[Frank-Rainer Grahl (:frg)]

Comment on attachment 9224333 [details] [diff] [review]
707631-handlermail-2539.patch

This caused a regression with not populating the from field but there were also problems finding the default account so need to retest.

Comment 32

[Hid Starks]

Attachment: same problem

Thanks from handhowadtua1983.