Closed Bug 268746 Opened 15 years ago Closed 14 years ago

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

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sspitzer, Assigned: Bienvenu)

References

(Blocks 1 open bug)

Details

(Keywords: fixed1.8, fixed1.8.0.4, fixed1.8.1)

Attachments

(4 files)

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.
Whiteboard: DUPEME
Looks very similiar to Bug 241213.
Agreed, dupe.

*** This bug has been marked as a duplicate of 241213 ***
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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
*** Bug 280829 has been marked as a duplicate of this bug. ***
No longer blocks: 279650
Depends on: 279650
Blocks: 279650
No longer depends on: 279650
Blocks: 269826
No longer depends on: 269826
*** Bug 299441 has been marked as a duplicate of this bug. ***
*** Bug 305378 has been marked as a duplicate of this bug. ***
*** Bug 305888 has been marked as a duplicate of this bug. ***
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.
Attachment #196234 - Flags: superreview?(mscott)
Attachment #196234 - Flags: superreview?(mscott) → superreview+
fix for reply/forward/edit msg as new checked in. I'm going to leave move/copy
for later...
Whiteboard: DUPEME
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.
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Attached file saved eml
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"
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"
Sorry about that spam, seems I had a mid-air collision with myself.
Blocks: 241213
this gets rid of the get/set string property warning by implementing it in the
dummy header.
Attachment #196686 - Flags: superreview?(mscott)
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
Could this fix be the cause of bug 309208?
Attachment #196686 - Flags: superreview?(mscott) → superreview+
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 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.
Attachment #196234 - Flags: approval1.8b5+
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.
Attachment #196686 - Flags: approval1.8b5+
Keywords: fixed1.8
No longer blocks: 279650
(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.
*** Bug 323129 has been marked as a duplicate of this bug. ***
(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.
(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 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.
Attachment #196686 - Flags: approval1.8.0.2?
Comment on attachment 196686 [details] [diff] [review]
fix get/set string property warnings

1.8.0.2 is already done.
Attachment #196686 - Flags: approval1.8.0.3?
Attachment #196686 - Flags: approval1.8.0.2?
Attachment #196686 - Flags: approval1.8.0.2-
Comment on attachment 196686 [details] [diff] [review]
fix get/set string property warnings

Well baked.  important for Tbird.  a=timr for drivers
Comment on attachment 196686 [details] [diff] [review]
fix get/set string property warnings

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #196686 - Flags: approval1.8.0.3? → approval1.8.0.3+
Keywords: fixed1.8.0.3
Comment on attachment 196686 [details] [diff] [review]
fix get/set string property warnings

It's like pulling teeth, I tell ya.
Attachment #196686 - Flags: approval-branch-1.8.1?(mscott)
Attachment #196686 - Flags: approval-branch-1.8.1?(mscott) → approval-branch-1.8.1+
the fix get/set string property warnings has been checked into the 1.8.1 branch. Thanks for nominating Mike.
Keywords: fixed1.8.1
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).
Status: REOPENED → RESOLVED
Closed: 15 years ago14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.