Closed Bug 297254 Opened 19 years ago Closed 19 years ago

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

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird1.1

People

(Reporter: bugzilla, Assigned: Bienvenu)

References

Details

(Keywords: fixed1.8)

Attachments

(1 file)

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.
Assignee: mscott → bienvenu
Flags: blocking1.8rc1?
Target Milestone: --- → Thunderbird1.1
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.
Attached patch proposed fixSplinter Review
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 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+
Flags: blocking1.8rc1? → blocking1.8rc1+
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
(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. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: