User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040618 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040618 The message window does not hang, but it does not process messages: does not move them, delete them, send unsent ones, ... Reproducible: Always Steps to Reproduce: 1.Open an email attachment from a received message. 2.Use Message|Move|Local|Drafts or any folder you wish 3.Go to Messages window and try to move some message from a folder to other. Actual Results: The window does not hang, but the message is not moved. You cannot even copy, delete, send unsent messages, etc. Expected Results: To move the message, ... to work.

I see this with TB version 0.8 (20040913), Win2K. Except: it's Send Later that fails, not Send Unsent Messages. Problem exists whether Move or Copy is used. When the rfc822 attachment is opened into its own window, there is an exception thrown (bug 231282), but attempting these other operations does not show anything in the JS console. Until such point as rfc822 attachments can properly be filed into a folder (bug 204612, bug 11013), the Move and Copy menu items should be disabled when opening an rfc822 attachment into its own message window. xref bug 204350.

so the attachment is an e-mail message (e.g., forwarded to you) and you open it in a stand-alone message window, and then try to move it to another folder? That should be disabled since it doesn't work.

this is more of a front end bug...it needs to be fixed, since it really messes things up.

bienvenu, who can fix this? Time is very short for 1.8a4. Is this a recent regression?

I don't believe it's a recent regression - I'd minus it for 1.8a4 and I'll try to figure it out for 1.8 final.

Thanks, David.

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

xref bug 201881 comment 1, which mentions this problem.

I was to file a new bugreport, but think this one is duplicate, so let me post my experience here: Used OS/Software: - Mac OS X, 10.3.7 - Either Mozilla suite 1.7.6, nightly build 2004-12-31-08-1.7/mozilla-mac-MachO.dmg.gz - Or: Thunderbird, nightly build 2005-01-01-02-0.9/thunderbird-mac-MachO.dmg.gz - Or: Thunderbird release 1.0 for Mac OS X. Reproducability: always Steps to reproduce: - Select an email with a rfc822 (email) attachment. (In my case, a spamassassin report with the original spam attached) - Double click the attachment. This opens a new email window showing the attached email. - Try to move or copy the attachment mail message to a mail folder on my IMAP account. This can be done by selecting a menu (message->move->.. or message->copy->..) or right clicking and selecting "Move To" or "Copy To". Actual results: - Selecting a mail folder does not seem to do anything. The menu dissappears, the message windows remains, and selecting the destination mail folder does not show the message there. - It should be noted that move to or copy to a new mail folder will stop working completely after the last step has been performed. Thus move to will not even work on regular emails (which previously worked just fine). Expected results: - That move to is disabled for attached emails (rfc822 attachments), and copy to does indeed copy the message to a mailbox - That the state would be the same as before the operation, and unrelated operations like moving other mail messages would be possible after this action.

This bug applies to a .EML file opened in a standalone window, as well as to message/rfc822 attachments.

TB 1.6a1-0917: for a message/rfc822, this is still an issue. However, for a . EML file (xref bug 268746, with a new patch in this build): the Move menu is disabled; the Copy menu does not function, but neither does it put the program into the unstable state reported in this bug.

(In reply to comment #11) > TB 1.6a1-0917: for a message/rfc822, this is still an issue. However, for a > .EML file (xref bug 268746, with a new patch in this build): the Move menu > is disabled; the Copy menu does not function, but neither does it put the > program into the unstable state reported in this bug. With 2a1 and 3a1 builds, I'm still seeing this problem. With an RFC822 attachment, the Move and Copy items are enabled, and selecting a folder under either of them puts the program into an unstable state. With a .EML file, Copy is enabled, but selecting a folder under that menu does not put the program into an unstable state. Isn't it feasible to simply disable both menus for both cases? At least until "Copy" (import into the folders) is implemented.

(In reply to comment #12) > Isn't it feasible to simply disable both menus for both cases? At least > until "Copy" (import into the folders) is implemented. I opened bug 338537 about this back in May, by the way. This bug is still an issue with TB 2b1-1018 -- it hasn't gone away.

Moving off bugs that didn't make the deadline for Thunderbird 2.

didn't meant to mark this fixed.

I don't see this one in tb3 (using latest 3.1a1 builds).

Certainly still there for comm-central builds...

(Windows XP 64) With a 64-bit build of 20090305 Shredder/3.0b2, when you open the forwarded message into its own window, the Move and Copy options in the main menu are disabled. Body context menu disables Move, but Copy is still active. When I select it, TB crashes. (I've just sent a crash report, but I no longer know how to find the incident ID.) With a 32-bit 20090327 Shredder/3.0b3pre, same symptoms. This is not the same as the original bug; first, the problem is only exposed if someone uses the unintuitive click-on-body context menu to try one of these actions, so there's been some improvement here -- almost entirely enough, in fact: just ONE MORE disabled menu and the problem is gone. Second, the program is crashing completely, rather than going unstable.

mcow: filed bug 489005 about the disabling/hiding. Bug 489011 about the crash. FWIW: about:crashes as start page gives you a nice list of crash ids.

So Magnus -- those bugs both being fixed, what remains to keep this bug open?

Yeah, I guess now all that's left to do is for seamonkey to port bug 489005.

(In reply to comment #23) > Yeah, I guess now all that's left to do is for seamonkey to port bug 489005. Looks like that is fixed now as well.

Yeah let's close this then. Fixed by other bugs.