243117 - Message marked unread gets marked read again after IMAP download complete

Status: RESOLVED INCOMPLETE

(MailNews Core :: Networking: IMAP, defect)

Description

[Jay Levitt]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: version 0.6b (20040427)

When you have filtered the inbox using the "Subject or sender contains" field, 
and you mark a message unread, it will be marked read again after N seconds if 
you don't move the cursor off it (or if you can't, e.g. if there is only one 
message matching the filter).  This doesn't happen with no filtering.

Reproducible: Always
Steps to Reproduce:
1. Type a phrase into the "Subject or sender contains" field
2. Select a message in the list pane
3. Press "M" to mark it unread
4. Wait N seconds, depending on your preferences
5. The message will become read again

Comment 1

[Mike Cowperthwaite]

That field at the top is "QuickSearch" -- different from "Message filters".

I have observed this symptom, and I've also observed the opposite, a marked-read 
message being marked unread, but it is not *always* reproducible.  I do not 
consistently see the focus moving to the QS field; and even when it does, I 
don't always see the message's Unread state toggle.

The focus-switch from thread pane to QS field is Seamonkey bug 231748, which the 
reporter says is a dupe of his other bug 255469.  (255469 is reported as an IMAP 
bug -- which sort of account do you see this under?)

Do you have the message pane visible, or not?  One thing I have noticed with an 
IMAP account and a visible message pane: if you select a message and toggle its 
unread state while the message is downloading, the state will revert when the 
download is complete, then switch back again -- as if the program is reiterating 
the command you gave.

It's possible that what's happening here is a combination of that behavior and 
the focus-switch behavior: you select a message, mark it as unread; the message 
completes downloading, and the state reverts to read; before the program can 
once again mark it Unread, the focus shifts to the QS field due to the other 
bug.

(All my testing has been with TB0.7; I haven't installed a build with the new 
field-selecting QS gizmo yet.)


> 4. Wait N seconds, depending on your preferences

Can you say more about this?  What preference affects the time?

Comment 2

[Jay Levitt]

I can no longer reproduce this exact scenario with 0.7.2.  FWIW, I think that if
it were still reproduceable, a bug that results in "kept as new" mail being
marked read is major, because it's essentially loss of data.

The initial behavior was seen with the message pane open on an IMAP server.  The
server is local, very fast, and dedicated to me alone, so downloading time isn't
an issue - messages download in milliseconds.  The "preference" mentioned was
the "Mark message read after displaying for N seconds" preference.

I *DO* see the message getting marked as read after I press the Clear button to
clear the QS.  I suspect this is an alternate symptom of the same bug, which
isn't related to 255469 - I never saw the focus go to the QS field.  So we can
keep it here or I can open a new bug if that's more appropriate.

Comment 3

[Mike Cowperthwaite]

I am confirming this bug, altho I'm removing the QS dependency -- what I see is 
completely reproducible and doesn't require QS to be on.  I'm doing this because 
per comment 2, reporter can no longer reproduce the QS dependency issue.  Jay, 
if you find a situation which *does* depend on QS, please open a new bug with 
more detail.

It seems sort of the opposite of bug 119205, bug 159267, bug 195787, bug 199433, 
all of which seem to be the same problem, more or less.  I'm not sure this isn't 
a dupe itself, but I couldn't find anything.

(In reply to comment #1)
> One thing I have noticed with an IMAP account and a visible message pane: if
> you select a message and toggle its unread state while the message is
> downloading, the state will revert when the download is complete, then switch
> back again -- as if the program is reiterating the command you gave.

This symptom has changed slightly in TB.8, and I also see the behavior in 
Moz 1.8a5-1011:
 - If the "mark-as-read in preview pane, immediately" preference is set, then 
when the message completes downloading after being marked unread, it is marked 
read immediately on completion of the download, then reverts to UNread, and then 
immediately re-reverts to read.
 - If the "mark-as-read in preview pane after N seconds" preference is set, then 
when the message completes downloading after being marked unread, it is marked 
read after N seconds and shows no visible reversion.

Comment 4

[Wayne Mery (:wsmwk)]

Are david's comments in bug 199433 comment 3 relevant to this?  Is the key phrase "We don't keep track of these pending stores of the seen flag."  (reporter states bug 199433 is random, which may not square with the rest of that bug ... *if* reporter's issue still exists)

This bug's symptoms are the opposite of bug 284030.  which happens to me even if I am offline.  

but if I am offline, this bug, 243117 does not happen. Nor after I go back online.

Comment 5

[Jay Levitt]

As the original reporter... I just discovered I've apparently reported this same basic bug (or similar symptoms) in quite a few guises.  Oops.  

I've since switched from Windows to Mac, which has very different focus/selection semantics; most importantly, when clearing QuickSearch, or switching folders, there is NO message selected in the list pane, so this doesn't happen.  Using TB2.0.0.16, I can't reproduce my original failcase on Mac, but apparently I couldn't reproduce it in comment 2 back when I was on Windows.

And I can no longer reproduce bug 284030 either, but Wayne can, so I think that one's Windows vs. Mac.

But: I did report similar problems in bug 436769, which I do see on Mac.  

I suspect the basic summary of all these bugs is "When anything refreshes or modifies the list pane, and the pane ends up with a message selected, the 'Mark message read after N seconds' preference will start its countdown on that message.  In many cases, that is undesirable behavior."

There's a good discussion in bug 436769 about different workflows; some people actually like the current behavior (e.g. bug 436769 comment 7), at least in some cases.

Comment 6

[Wayne Mery (:wsmwk)]

Mike, was your testing in comment 3 via Mac?

Comment 7

[Wayne Mery (:wsmwk)]

Charles, Jay, can you reproduce this?

Comment 8

[Jay Levitt]

Nope, I'm no longer on Windows, and Mac's list-box behavior is different, so this never happened on Mac. I just briefly tried to install Thunderbird 3.1 for Windows under VMWare Fusion, but it won't talk to my IMAP server; let me know if you suspect the bug still exists and would like me to try harder.

Comment 9

[Wayne Mery (:wsmwk)]

Jay, thanks for the feedback.

1 day short of a year later, I guess then we call this incomplete