found using 2005060905-trunk tbird build on linux fc3. the "Replied" status not applied (displayed) in the mail 3pane window after sending a message which was autosaved during composition. setup ----- - make sure that you've got the "status" column displayed in the mail 3pane window. - make sure that you've turned on autosaving; I had mine set to save every 5 minutes. that pref UI is located in Composition > Advanced. 1. send a message to yourself. 2. once received, view that message and note that the status is "Read" 3. reply to the message: eg, hit Ctrl+R to bring up the message compose window. 4. enter some text, if you want, but don't send the response. 5. wait at least 5 more minutes (or the minimum amount of time you set for autosaving), to ensure that autosave occurs --you can watch the statusbar to verify that, if you wish. 6. send the response message. results: the message is sent, but the status remains as "Read" rather than changing to "Replied" I tested this IMAP. will see if this also occurs on POP...

this also occurred with my POP account (global inbox, fwiw).

oh whups, I meant to say: the POP account I tested was *not* using global inbox.

Noticed that some of my replied statuses were occasionally not being applied. Then I found this bug. I can confirm that this has been happening to me with Win32 trunk builds at least since this bug was opened. Can't recall if it did before that.

this happened to me, but I'm not sure it's autosave. Did folders get recompacted in between the time you hit reply and the time the reply was sent? It doesn't seem to happen with auto-save alone.

argh, I take it back - I do see this. My auto-save interval was longer than I thought. This is pretty painful, Scott. I'll look for a fix.

the problem is that saving as draft (either auto or manual) sets nsMsgCompose::mType to draft, and we never set it back to what it was at compose time when we send, and that makes us not mark the original message as replied to, since we think it's a draft.

instead of playing tricks with the type to determine if we need to delete a draft, I just added an attribute to the compose object. If we opened a draft, or saved a draft, set that attribute to true, and check it before we try to cleanup after message send. I hate to say this, but I think we're going to want this for the branch. Autosave makes this a really bad bug (the bug has been around for a while, but autosave exacerbates it)

Comment on attachment 199882 [details] [diff] [review] proposed fix don't forget to bump the IDL for nsIMsgCompose :)

(In reply to comment #7) > the bug has been around for a while I guess you mean bug 128996. I wrote a fairly bitter comment here about just how "bad" this bug is (compared to bug 155622, which makes drafts extremely tedious to use), but then I figured there's no point in poking at an open sore and wiped it out.

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

I was afraid this was a regression from some recent changes, which was why I jumped on it. It turned out not to be, but as I pointed out, autosave makes it much more frequent a problem. bug 155622 is indeed a ugly drag, but if you use html compose, it's not an issue. My guess is that it would be ugly to fix, but I could be wrong - I don't know that code at all.

(In reply to comment #11) > bug 155622 is indeed a ugly drag, but if you use > html compose, it's not an issue. La-la-la, la-la-la -- I don't use a feature, therefore its bugs are not "bad", la-la-la. (from "The Ballad of Open Source") HTML compose plus plain-text send has its own problems: the text is not properly processed for format=flowed, per bug 125928. Leading spaces and quotemarks are not space-stuffed, trailing spaces are not stripped. See comments 19-22, 28, 31, 32, 34, 37 at that bug. > I don't know that code at all. Nobody who's actively contributing code does, it seems.

I did say it was an ugly drag, so I don't think I was belittling the problem - I was just trying to say that there is at least a work-around.

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