268746 - unable to reply, fwd, move or copy .eml opened from disk

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[(not reading, please use [e-mail] instead)]

unable to reply, fwd, move or copy .eml opened from disk

as far as move or copy, the menu items are enabled, but they don't work.

screen shot coming.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: screen shot of the move / copy menu items

Comment 2

[OstGote!]

Looks very similiar to Bug 241213.

Comment 3

[Mike Cowperthwaite]

Agreed, dupe.

*** This bug has been marked as a duplicate of 241213 ***

Comment 4

[Mike Cowperthwaite]

I've reversed the duplicate only because bug 241213 is for Seamonkey rather than 
Thunderbird.  I can't find an earlier TB bug specific to .EML and TB.

I suspect that the fix for this problem applies to both .EML files *and* to 
message/rfc822 attachments (viz bug 241212):
                     Seamonkey       Thunderbird
message/rfc822        bug 204350      bug 224967
.EML files            bug 241213      [this bug]

See also:             bug 203570      bug 241267

Comment 5

[Stefan Zidar]

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

Comment 6

[Adam Guthrie]

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

Comment 7

[Jo Hermans]

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

Comment 8

[Magnus Melin [:mkmelin]]

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

Comment 9

[David :Bienvenu]

Attachment: implement reply/forward/edit msg as new for .eml files

the main changes here are to enable getting hold of the dummy msg hdr, and to
handle the file: urls in various parts of the compose code and common code.

Comment 10

[David :Bienvenu]

fix for reply/forward/edit msg as new checked in. I'm going to leave move/copy
for later...

Comment 11

[Mike Cowperthwaite]

Verifying that Reply, Reply All, Forward Inline, Forward as Attachment, and Edit 
as New now all open new message compose windows prefilled with information, for 
most messages.  TB 1.6a1-0917, Win2K.

There are multiple problems, however:
 - none of the actions work a message/rfc822 attachment; maybe that's expected,
   but the toolbuttons are now enabled where they weren't before.  Errors in the 
   JS console.
 - Replying/Fwd-as-Attach a message with a MIME-encoded Subject yields gibberish
   in the subject of the new message, with no error in the JS console.  (MIME-
   encoded addresses are correctly shown in the To: fields of the message for
   replies.)
 - For at least one message (in Hebrew/Windows-1255 -- attachment 69229 [details]),
   Forward Inline or Edit as New results in a blank message body.  This same
   message forwards/edits correctly if opened from a folder.  No error in the
   JS console.
 - if the message doesn't have a Message-Id header, all of the actions fail,
   with an error in the JS Console.  Maybe not a common case, but if I want to
   create a test message by hand, this can interfere.

Regarding the JS errors: note that simply opening a .EML file puts up at least 
one error itself (bug 241212 comment 41); for that matter, so does opening a 
message/rfc822 attachment (bug 231282).


(In reply to comment #10)
> fix for reply/forward/edit msg as new checked in. I'm going to leave move/copy
> for later...

"Move" is properly disabled; Copy is highly desirable, as the reverse of "save 
to disk."  At least Copy doesn't break things; xref bug 259522.

Comment 12

[Joe Sabash [:JoeS1]]

Attachment: saved eml

Comment 13

[Joe Sabash [:JoeS1]]

Try with an html composition. Just opening the saved eml results in many
javascript errors.
Error: [Exception... "'JavaScript component does not have a method named:
"getStringProperty"' when calling method: [nsIMsgDBHdr::getStringProperty]" 
nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location:
"<unknown>"  data: no]

Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIMsgMailNewsUrl.folder]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://messenger/content/mailWindowOverlay.js :: OnMsgLoaded :: line 2255" 
data: no]
Source File: chrome://messenger/content/mailWindowOverlay.js
Line: 2255

Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIMsgMailNewsUrl.folder]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://messenger/content/phishingDetector.js :: isMsgEmailScam :: line 24" 
data: no]
Source File: chrome://messenger/content/phishingDetector.js
Line: 24

The first error with multiple instances of the same error.

The opened eml is loosing the image src links as follows:
<img alt=""
 src="file:///C:/saveas/test%20images%20in%20eml.eml?type=application/x-message-display?fetchCompleteMessage=true&amp;part=1.2"
 height="79" width="290">

View page source is grayed out, the above is from the html in an attempt to
"edit as new"

Comment 14

[Joe Sabash [:JoeS1]]

Try with an html composition. Just opening the saved eml results in many
javascript errors.
Error: [Exception... "'JavaScript component does not have a method named:
"getStringProperty"' when calling method: [nsIMsgDBHdr::getStringProperty]" 
nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location:
"<unknown>"  data: no]

Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIMsgMailNewsUrl.folder]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://messenger/content/mailWindowOverlay.js :: OnMsgLoaded :: line 2255" 
data: no]
Source File: chrome://messenger/content/mailWindowOverlay.js
Line: 2255

Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIMsgMailNewsUrl.folder]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://messenger/content/phishingDetector.js :: isMsgEmailScam :: line 24" 
data: no]
Source File: chrome://messenger/content/phishingDetector.js
Line: 24

The first error with multiple instances of the same error.

The opened eml is loosing the image src links as follows:
<img alt=""
 src="file:///C:/saveas/test%20images%20in%20eml.eml?type=application/x-message-display?fetchCompleteMessage=true&amp;part=1.2"
 height="79" width="290">

View page source is grayed out, the above is from the html in an attempt to
"edit as new"

Comment 15

[Joe Sabash [:JoeS1]]

Sorry about that spam, seems I had a mid-air collision with myself.

Comment 16

[David :Bienvenu]

Attachment: fix get/set string property warnings

this gets rid of the get/set string property warning by implementing it in the
dummy header.

Comment 17

[Joe Sabash [:JoeS1]]

Error: [Exception... "'JavaScript component does not have a method named:
"getStringProperty"' when calling method: [nsIMsgDBHdr::getStringProperty]" 
nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location:
"<unknown>"  data: no]

No joy here with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050920 Thunderbird/1.6a1 ID:2005092010

I should add that the above errors come up when opening the saved eml before
trying to "reply" or "edit as new"

JoeS

Comment 18

[Brian Kennelly]

Could this fix be the cause of bug 309208?

Comment 19

[Mike Cowperthwaite]

The getStringProperty() fix is working (today's nightly), but the other two 
warnings are of course still there.  (That patch more properly belongs to
bug 241212.)

Comment 20

[Scott MacGregor]

Comment on attachment 196234 [details] [diff] [review]
implement reply/forward/edit msg as new for .eml files

we're going to take this on the branch. It's been baking for quite some time.

Comment 21

[Scott MacGregor]

Comment on attachment 196686 [details] [diff] [review]
fix get/set string property warnings

we're going to take this on the branch. It's been baking for quite some time.

Comment 22

[Mike Cowperthwaite]

(In reply to comment #11)
>  - none of the actions work a message/rfc822 attachment; maybe that's
>    expected, but the toolbuttons are now enabled where they weren't
>    before.  Errors in the JS console.

Fixed with the patch for bug 204350.  However, that patch is not going to be on the branch; this is still a (minor) issue with 1.5.


I've opened some new bugs about the problems mentioned in comment 11:

>  - Replying/Fwd-as-Attach a message with a MIME-encoded Subject yields
>    gibberish in the subject of the new message, with no error in the JS
>    console. 

Also true for message/rfc822 attachments.  Bug 314351.

>    (MIME-encoded addresses are correctly shown in the To: fields of the
>    message for replies.)

That's true for To:/CC: fields initialized from original To: or CC: fields when using Reply All; but not when the original From: header is converted to a To:.


>  - if the message doesn't have a Message-Id header, all of the actions
>    fail, with an error in the JS Console.  Maybe not a common case, but
>    if I want to create a test message by hand, this can interfere.

Also true for message/rfc822 attachments: bug 314349.


An additional problem is that selecting File|Print or File|Print Preview from a standalone window displaying a .EML file causes a crash: bug 314354.

Comment 23

[Magnus Melin [:mkmelin]]

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

Comment 24

[Mike Cowperthwaite]

(In reply to comment #11)
>  - none of the actions work a message/rfc822 attachment; maybe that's
>    expected, but the toolbuttons are now enabled where they weren't before.

And bug 323319 was opened complaining that the forward button didn't work for
an attachment.

Comment 25

[Mike Cowperthwaite]

(In reply to comment #19)
> The getStringProperty() fix is working ([0923] nightly), but the other two 
> warnings are of course still there.

This fix was attachment 196686 [details] [diff] [review], which has 1.8b5 approval -- but the getStringProperty() errors are showing up in 1.5 when a .EML is opened.
What happened --did the patch not get checked in, or did something 
overwrite it?

Comment 26

[Mike Cowperthwaite]

Comment on attachment 196686 [details] [diff] [review]
fix get/set string property warnings

(In reply to comment #25)
> (In reply to comment #19)
> > The getStringProperty() fix is working ([0923] nightly), but the other two 
> > warnings are of course still there.
> 
> This fix was attachment 196686 [details] [diff] [review] [edit], which has 1.8b5 approval -- but the
> getStringProperty() errors are showing up in 1.5 when a .EML is opened.
> What happened --did the patch not get checked in, or did something 
> overwrite it?

These errors still occur on the branch, but not on the trunk.  
Can this patch be ported over to the branches, please?  Note that it had 1.8 approval already.

Comment 27

[Scott MacGregor]

Comment on attachment 196686 [details] [diff] [review]
fix get/set string property warnings

1.8.0.2 is already done.

Comment 28

[Tim Riley [:timr]]

Comment on attachment 196686 [details] [diff] [review]
fix get/set string property warnings

Well baked.  important for Tbird.  a=timr for drivers

Comment 29

[Daniel Veditz [:dveditz]]

Comment on attachment 196686 [details] [diff] [review]
fix get/set string property warnings

approved for 1.8.0 branch, a=dveditz for drivers

Comment 30

[Mike Cowperthwaite]

Comment on attachment 196686 [details] [diff] [review]
fix get/set string property warnings

It's like pulling teeth, I tell ya.

Comment 31

[Scott MacGregor]

the fix get/set string property warnings has been checked into the 1.8.1 branch. Thanks for nominating Mike.

Comment 32

[Mike Cowperthwaite]

Thanks for getting the patch in, Scott.

For the other errors that are shown in the JS console on opening a .EML, I've opened bug 338536.

Regarding Move/Copy: bug 259522 is still outstanding, and I've opened 
bug 338537 as a mitigation.  But for .EML files (this bug) under TB, Move is disabled and Copy, while unimplemented, doesn't seem to break anything.  

To fully implement the Copy feature: bug 193281 is probably the place to do that.

Of the other spinoff bugs from comment 11 and comment 22, only bug 314351 remains unaddressed.  As those are all that's outstanding for this bug, I'm resolving this as Fixed.  I haven't yet tested with Seamonkey, but all these features have been implemented in the backend so I imagine it's fixed everywhere, for TB 2.0 and Seamonkey 1.1.

Bug 241213 is still open for the other unimplemented menu items (specifically, the View menu items).