548070 - Cannot save as draft on reply when orig. message was an .eml file

Status: RESOLVED DUPLICATE of bug 389650

(Thunderbird :: Message Compose Window, defect)

Description

[Philippp]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1

Reading a message that was actually an eml file, reply to it.
Cannot save as draft (or autosave) -> error.


Reproducible: Always

Steps to Reproduce:
1. Thunderbird closed
2. Double click an .eml file to open the message
3. Click Reply
4. Save as draft (or wait for autosave)
Actual Results:  
5. Error: "Message could not be saved as draft" (=translation from german)

Expected Results:  
5. Should be saved as draft

Actually it shows 2 dialogs, but the smaller one (saying (translated from german) "collecting information about message") is behind the said error message. See screenshot.

Still, sending the message seems to work - so probably this is not totally similar to bug #530779 (which I had expected at first sight).

Comment 1

[Philippp]

Attachment: Screenshot: Error message and dialog behind

Comment 2

[Philippp]

Attachment: Screenshot on Mac OSX 10.5

On OSX, I could not get TB to open the eml file without opening the main app window - in fact, opening the eml the first time only opened the main app window. Opening the eml a second time (with TB already started) brought up the window with the message. Still, replying to that message seems to cause the same problem as on windows.

Comment 3

[Philippp]

Some of my clients generally archive emails as eml files (in their working folders), so this occurs more often than one might think.

Comment 4

[Nathan Tuggy (:tuggyne)]

Reproduced on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Lightning/1.0b1 Thunderbird/3.0.2 ID:20100216161403.

Error Console:
Error: [Exception... "'JavaScript component does not have a method named: "NotifyComposeBodyReady"' when calling method: [nsIMsgComposeStateListener::NotifyComposeBodyReady]"  nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location: "<unknown>"  data: no]
Error: [Exception... "'JavaScript component does not have a method named: "ComposeProcessDone"' when calling method: [nsIMsgComposeStateListener::ComposeProcessDone]"  nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: GenericSendMessage :: line 2120"  data: no]
Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js
Line: 2120
Error: no element found
Source File: chrome://communicator/content/communicatorOverlay.xul
Line: 1

The middle error occurs again whenever I try to save as a draft.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

We're resetting the blocking flag for 3.1 on this bug and instead setting the wanted-thunderbird+ flag. We have too many blocking-3.1 bugs, to the point where it doesn't mean much, and managing the list is making it hard to actually work on closing bugs, which helps no one.

Thunderbird 3.1's primary purpose is to allow us to offer a prompted major update to Thunderbird 2 users, to ensure their continued ability to safely use Thunderbird.  Thunderbird 2 is built on an outdated version of Gecko, and our long-term ability to maintain the users' safety for Thunderbird 2 users is limited.

If you think this bug meets the requirements below, please renominate with a detailed explanation of how it meets the following two criteria, and we will reconsider.  To qualify, this bug must either:

a) make the upgrade experience from TB2 very painful for a large number of users

or

b) be a new, reproducible, severe quality issue (eg dataloss, frequent crashes)

Just because this bug doesn't block TB3.1 doesn't mean it can't or won't make the release.  Once they're done with their blockers (if any), we encourage developers to keep working on non-blocking bugs, and to try to land them as early in the cycle as possible, as non-blocking bugs will become increasingly difficult to land in the later stages of the cycle.

Comment 6

[Philippp]

I do not want to obstruct your work (sadly I realize there are really plenty of other issues), and probably its not the majority of users responding from eml files.

Though, the bug is not far away from (b), it is definitely new and reproduceable. It merely depends on the technical understanding of the user whether the bug causes data loss. When the bug strikes, the user must be smart enough to realize that only the save function does not work, and that despite the error it is still possible to send the message. They need to realize that instead of saving it as a draft, they can send it to themselves in order to preserve the data (except the adresses!). (Saving the draft as an .eml is not possible, only .txt so this would not be a clean workaround either.) So one might argue that this is a kind of data loss.

Comment 7

[WADA:World Anti-bad-Duping Agency]

Philippp(bug opener), can you find bug for same phenomenon/same error message in dependency tree for meta Bug 269826?

For next in commen #5.
> a) make the upgrade experience from TB2 very painful for a large number of users

It never happened/happens, because phenomenon you wrote in bug summary exists in Tb 2(I think since initial of Tb) and still exists in Tb trunk(currently Tb3.2a1pre). i.e. any user of any Tb version, build, can experience problem you wrote in your bug summary, although internal error like comment #4 may depend on version/build.

Tb 3.0 now has capability of "import of .eml file by Drag&Drop to thread pane or a folder at folder pane", as Oulook Express could/can do. I think next is simplest change to avoid user's confusion and user's misunderstanding.
 - Change window in which .eml content is displayed to "display only window".
   - Remove action menus such as "Reply" from window in which .eml is shown,
     to protect users from repeatedly reported, and living very long,
     problems like this bug around .eml file (and message/rfc822 part too).
     (See dependency tree for meta Bug 269826)
   This is similar to SeaMonkey1/2's .eml display in Browser's tab/window.
 - Provide appropriate document/help about "import of .eml by Drag&Drop"
   to users. I could't see any explanation about the new functionality
   in any Release Notes of Tb 3.0(.0), 3.0.1, 3.0.2, 3.0.3.

Comment 8

[Philippp]

(In reply to comment #7)
> Philippp(bug opener), can you find bug for same phenomenon/same error message
> in dependency tree for meta Bug 269826?

Thanks WADA, I will look through that soon. Let me answer the other things first:
 
> For next in commen #5.
> > a) make the upgrade experience from TB2 very painful for a large number of users
> 
> It never happened/happens, because phenomenon you wrote in bug summary exists
> in Tb 2(I think since initial of Tb) and still exists in Tb trunk(currently
> Tb3.2a1pre). i.e. any user of any Tb version, build, can experience problem you
> wrote in your bug summary, although internal error like comment #4 may depend
> on version/build.

I didnt check, but I definitely know that my users started complaining about this when I rolled out TB3. No complaints before, and they have always been using .eml files heavily! Perhaps the autosave feature was previously turned off, so that it did not hit them before...

 
> Tb 3.0 now has capability of "import of .eml file by Drag&Drop to thread pane
> or a folder at folder pane", as Oulook Express could/can do. I think next is
> simplest change to avoid user's confusion and user's misunderstanding.
>  - Change window in which .eml content is displayed to "display only window".
>    - Remove action menus such as "Reply" from window in which .eml is shown,
>      to protect users from repeatedly reported, and living very long,
>      problems like this bug around .eml file (and message/rfc822 part too).
>      (See dependency tree for meta Bug 269826)

Ah, nice new feature!
Though, hindering the users from replying (by hiding the reply button) breaks users workflow at the point where they are thinking what to reply.
Instead, I would prefer that TB should suggest to do the right thing - i.e., instead of the "reply" buttons, show a hint "if you want to reply:" and an "import" button directly beneath. Perhaps this is not very much more effort (it just uses an existing feature), and much more convenient for daily use.

>    This is similar to SeaMonkey1/2's .eml display in Browser's tab/window.
>  - Provide appropriate document/help about "import of .eml by Drag&Drop"
>    to users. I could't see any explanation about the new functionality
>    in any Release Notes of Tb 3.0(.0), 3.0.1, 3.0.2, 3.0.3.

Yeah, did not know it.

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #8)
> but I definitely know that my users started complaining about this when I rolled out TB3.
> No complaints before, and they have always been using .eml files heavily!
> Perhaps the autosave feature was previously turned off, so that it did not hit them before...

I thought(probably wrongly) this bug(for .eml file) is same as bug 389650(for messages/rfc822 part==attached mail as attachment), because many of bugs listed in dependency tree for meta Bug 269826 are common problem both on ".eml file" and "message/rfc822 part". Sorry for my misunderstanding and wrong comment.

Comment 10

[Wayne Mery (:wsmwk)]

I'm missing something - is there a reason this is not a duplicate of bug 389650?

Comment 11

[Philippp]

I have no insight in the internals of TB (just user/admin), but I can well imagine that the underlying cause is the same, which is causing trouble for all kinds of messages that are not in ordinary message store (either .eml files or forwarded attached messages).
Not sure if that qualifies for being a duplicate, though...??

Comment 12

[Philippp]

Additional observation regarding .eml files:
Using AddOn "QuickFolders" (which shows shortcuts to mail folders in a bar at the top): When opening an .eml file, the QF bar stays empty in that window, even if TB was already running before I double-clicked the .eml file (and the QF bar is ok in the main TB window).
Maybe this indicates that the whole message store is not accessible to message windows that have been opened for an eml file?
(Perhaps this could justify keeping a separate bug??)

Hth...

Comment 13

[Jim Porter (:squib)]

Since Bienvenu has done a fair bit with drafts recently, he might know something about what's going on. Assuming I get the chance, I'll try to look at this too.

One observation: adding an attachment to the email seems to let me save it as a draft. Removing the attachment breaks things again. (This is on 11.0a1 on Linux, if it matters.)

Comment 14

[patrice Arnal]

From bug 193281 and in answer to  Thomas D.'s mail : 
You are right : bug 548070 is almost the same as mine.

I use Thunderbird 7.0.1 on an Ubuntu 11.10 64 bits architecture


Reading a message that was actually an eml file, reply to it.
Cannot save as draft (or autosave) -> error.

Reproducible: Always

Steps to Reproduce:
1. Thunderbird opened
2. Menu "File/open/open a saved message " to open the message
3. Click Reply
4. Save as draft (or wait for autosave)
Actual Results:  
5. Error: "Message could not be saved as draft" (=translation from french)

Expected Results:  
5. Should be saved as draft


Strange : sending the mail without saving it produced the same error on my first try, but no more later....

Comment 15

[Hiroyuki Ikezoe (:hiro)]

Does this still happen on trunk build? I can not reproduce this at all.

Comment 16

[Jim Porter (:squib)]

This works for me on trunk as well, so based on comment 10 and comment 15, resolving as duplicated. Philippp, if you still see the issue in recent nightlies (or 12.0 when it's released), feel free to reopen this.