Replied status not applied after sending a message which was autosaved during composition

RESOLVED FIXED in Thunderbird1.1


14 years ago
13 years ago


(Reporter: bugzilla, Assigned: Bienvenu)



Bug Flags:
blocking1.8rc1 +

Firefox Tracking Flags

(Not tracked)



(1 attachment)



14 years ago
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.

- 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...

Comment 1

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

Comment 2

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

Comment 3

13 years ago
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.

Comment 4

13 years ago
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.

Comment 5

13 years ago
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.
Assignee: mscott → bienvenu
Flags: blocking1.8rc1?


13 years ago
Target Milestone: --- → Thunderbird1.1

Comment 6

13 years ago
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.

Comment 7

13 years ago
Created attachment 199882 [details] [diff] [review]
proposed fix

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)
Attachment #199882 - Flags: superreview?(mscott)

Comment 8

13 years ago
Comment on attachment 199882 [details] [diff] [review]
proposed fix

don't forget to bump the IDL for nsIMsgCompose :)
Attachment #199882 - Flags: superreview?(mscott)
Attachment #199882 - Flags: superreview+
Attachment #199882 - Flags: approval1.8rc1+


13 years ago
Flags: blocking1.8rc1? → blocking1.8rc1+


13 years ago
Last Resolved: 13 years ago
Keywords: fixed1.8
Resolution: --- → FIXED

Comment 9

13 years ago
(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.

Comment 10

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

Comment 11

13 years ago
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.

Comment 13

13 years ago
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.

Comment 14

13 years ago
*** Bug 312113 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.