1038081 - eml file in separate message window: "Reply" and "Forward" buttons doesn't work.

Status: ASSIGNED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Edmund Wong (:ewong)]

The basic steps to reproduce:

1) Forward an attached email (Forward attachment) to yourself.
2) In SeaMonkey (2.26.1, but I suspect trunk would also do), click on
   the message.  In the attachment list, double click on the eml file.
3) The eml is displayed in a message window.
4) click on reply.

Actual Result: 
Nothing happens. (No errors in Error Console)

Expected Result:
A composition window should appear with the reply-to set to the original
eml sender.

My co-worker encountered this and I can reproduce it.

Comment 1

[Edmund Wong (:ewong)]

Attachment: proposed patch (v1)

Comment 2

[Edmund Wong (:ewong)]

Attachment: proposed patch (v2)

Comment 3

[[e-mail]]

This is a regression from bug 811117. It switched from using GetSelectedMessages() to gFolderDisplay.selectedMessageUris but that doesn't work for attached messages.

Comment 4

[Ian Neal]

Comment on attachment 8457867 [details] [diff] [review]
proposed patch (v2)

TB addressed this by creating a gFolderDisplay for messageWindow.js, maybe a longer term fix, in the interim, what is wrong with:
gFolderDisplay ? gFolderDisplay.selectedMessageUris : [gCurrentMessageUri]

Comment 5

[Edmund Wong (:ewong)]

(In reply to Ian Neal from comment #4)
> Comment on attachment 8457867 [details] [diff] [review]
> proposed patch (v2)
> 
> TB addressed this by creating a gFolderDisplay for messageWindow.js, maybe a
> longer term fix, in the interim, what is wrong with:
> gFolderDisplay ? gFolderDisplay.selectedMessageUris : [gCurrentMessageUri]

Just to clarify, do I need to implement the gFolderDisplay for messageWindow.js
code for this bug or is the |gFolderDisplay ? gFolderDisplay.selectedMessageUris : [GetLoadedMessage()];| ok?

Comment 6

[Ian Neal]

(In reply to Edmund Wong (:ewong) from comment #5)
> (In reply to Ian Neal from comment #4)
> > Comment on attachment 8457867 [details] [diff] [review]
> > proposed patch (v2)
> > 
> > TB addressed this by creating a gFolderDisplay for messageWindow.js, maybe a
> > longer term fix, in the interim, what is wrong with:
> > gFolderDisplay ? gFolderDisplay.selectedMessageUris : [gCurrentMessageUri]
> 
> Just to clarify, do I need to implement the gFolderDisplay for
> messageWindow.js
> code for this bug or is the |gFolderDisplay ?
> gFolderDisplay.selectedMessageUris : [GetLoadedMessage()];| ok?

Probably a question for Karsten and/or Neil too. The regression needs to be fixed quickly but longer term probably need something like TB did.

Comment 7

[[e-mail]]

The thing to do is to try a version of SeaMonkey before bug 811117 landed, and see whether the following functions used to work on an attached message:
* Save
* View Source
* Print (preview)
If any of them did work, then it would probably be better to fix the folder display, as that will mean that they will start working again. I don't know whether the correct fix is to tweak the existing folder display object to return the correct result in a standalone message window or to create a completely new folder display object for standalone message windows.

Comment 8

[Ian Neal]

(In reply to [e-mail] from comment #7)
> The thing to do is to try a version of SeaMonkey before bug 811117 landed,
> and see whether the following functions used to work on an attached message:
> * Save
> * View Source
> * Print (preview)
> If any of them did work, then it would probably be better to fix the folder
> display, as that will mean that they will start working again. I don't know
> whether the correct fix is to tweak the existing folder display object to
> return the correct result in a standalone message window or to create a
> completely new folder display object for standalone message windows.

All of them did work prior to the landing.

Comment 9

[Serge Gautherie (:sgautherie)]

[Copied as is, from a new bug I was about to file: confirming issue.]

Agent utilisateur : Mozilla/5.0 (Windows NT 6.0; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30
Identifiant de compilation : 20141013232806

For at least a few recent releases, I noticed an issue with received attached .eml messages:

I can select an email wich contains an attached .eml file,
and I can open that .eml file in a MailNews display window :-)

But I can't "edit/use" that message from that window:
"Edit as new" and "Forward (Inline/Attached)" do nothing :-(

Workaround:
Open a new blank message then manually copy-paste all data... :-/
(Painful when there are many to process.)

Regression:
it worked in SeaMonkey v2.0.x (Windows 2000)...

Comment 10

[GuigonsE]

Just remember that the problem still remains, in SeaMonkey 2.40 over Windows 7; when opening a message stored as an EML file (that's the way we classify them by projects: one EML file per message) the REPLY and FORWARD options (button neither menu) dosn't do anything.


Data from about:buildconfig

about:buildconfig
Source

Built from http://hg.mozilla.org/releases/mozilla-release/rev/e8bb3550be0f344804a13cc7aa268b91a9154e93
Build platform
target
i686-pc-mingw32
Build tools
Compiler 	Version 	Compiler flags
cl 	1800 	-TC -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -arch:IA32 -FS -wd4244 -wd4267 -wd4819 -we4553
cl 	1800 	-TP -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -arch:IA32 -FS -wd4251 -wd4244 -wd4267 -wd4345 -wd4351 -wd4482 -wd4800 -wd4819 -we4553 -GR- -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -O1 -Oi -Oy

Configure arguments
--enable-crashreporter --enable-release --enable-application=suite --enable-update-channel=release --enable-update-packaging --enable-jemalloc --enable-tests --with-external-source-dir=C:/builds/slave/rel-c-r/build

Comment 11

[GuigonsE]

and it continued failing with "seamonkey-2.49a1.en-US.win32.zip" install file...

Comment 12

[Rainer Bielefeld]

a) I did some research, and due to my test this problem appeared between 
   Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
   SeaMonkey/2.16.2    Build identifier: 20130310201055
   and SeaMonkey 2.19 (first bad I tested)
a1) My preliminary suspect is that this problem here appeared together with
    [Forward] does not work for email opened from file
b) We have a similar problem in "Bug 1240346 - Reply to all fails with NULL error
   when message was opened from file", but that one seems to have different roots,
   already visible with SeaMonkey 2.8

Comment 13

[Rainer Bielefeld]

As Mentioned in "Bug 241213 - Message window for .EML file needs working commands":

a) this (of course) also affects .eml files opened from HDD:
0. Download  Attachment 8826695 [details] Details for Bug 1331042
	
1. Launch Email Client
2. Menu 'File → Open File → Browse for "ThisIsAtestEmailFor_emlImport.eml"
   and open
   » File opens 
3. Menu 'Message → Reply'
   Expected: Reply message opened in composer Window
   Actual: Nothing
4. Menu 'Message → Forward'
   Expected: Forwarded message opened in composer Window
   Actual: Nothing

b) It seems we will not get feedback from mnyromyr
c) This is not a general "Separate View Window" problem. I opened the 
   source email for the attachment form Drafts Email Folder with
   'Rightlick (in Thread Pane) → Open Message in New Window' and 
   Clicked [Reply]
   » works fine                                                           :-)
d) Problem is not limited to buttons, menu items of Message-menu and
   shortcuts <ctrl+r> (Reply) and <ctrl+l> (Forward) also are affected.   :-(

Comment 14

[Worcester12345]

This bug has a patch. Has it been tested? Can it get reviewed, approved, and shipped? Thanks.

Comment 15

[Wayne Mery (:wsmwk)]

(Neil replied to the comment)