Closed Bug 410148 Opened 17 years ago Closed 15 years ago

thunderbird randomly marks imap messages as read

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 373366

People

(Reporter: bugzilla, Unassigned)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
Build Identifier: 2.0.0.9 (20071031)

I like to have strict control over when my imap messages get marked as read.  As it stands, I have the Advanced>General option Wait 30 seconds before marking message as read selected, which generally gives me time to read the message or move on before the status changes.  The problem is, I've noticed repeatedly that Thunderbird is just ignoring this setting completely with some mails, and immediately marking them as read as soon as they're selected and show up in the preview pane.  Some messages it previews with the proper 30 second delay, while others get marked immediately, and I've yet to find a pattern which explains or reproduces the behavior.  It happens with old messages and with brand new ones.  It happens after I delete one mail and tbird auto-selects the chronological next, and it happens when I mouse click on a random email.  Sometimes they immediately change to read, sometimes they wait the 30 seconds.  It's irritating to no end, and without resolution to bug #297534 and being able to disable marking as read entirely I see no way to avoid this problem.  I run the imap server being used, so if you need debug data (or a test account), just ask.

Reproducible: Sometimes

Steps to Reproduce:
1. Click on an imap message, or delete one message so another is auto-selected.

Actual Results:  
Selected message may be marked read immediately.

Expected Results:  
Messages should always wait 30 seconds before becoming read (since 30 is specified in the options pane).
Also fwiw, I've seen this issue under both Windows XP and Ubuntu Linux, so it doesn't appear to be OS-specific.
Version: unspecified → 2.0
Gary, wasn't there a time bug fixed that might be related to this? dupe?
I've also had a lot of problems with IMAP. This is an IMAP log of several hours of activity. At the end, I was viewing the folder for this account (which I only view every few hours.) I recall there were four unread emails at the end. As I was watching, all of those emails got set to Read without me opening them. (I believe it was UID 1089-1093) I checked on another TB client on another computer, created an account for that, and downloaded IMAP. They indeed were downloaded as Read.
(In reply to comment #3)
> IMAP log when I was watching unread get set

Log says;
 (1) 17 UID fetch 1090:* (FLAGS), * 975 FETCH (FLAGS (\Recent) UID 1089)
     At this step, \Seen is not set.
 (2) 18 IDLE 
 (3) after a while, DONE is sent, and 19 uid store 1089 +Flags (\Seen)
This looks to be very normal behavior.

NSPR log doesn't have timestamp, so analysis of timer related problem is difficult. Get NSPR log with timestamp by DebugView.
See Bug 411258 Comment #10. See Bug 425897 Comment #21 for example of log.
And check when each request is issued, please.
I'm back with Thunderbird for the time being, and this bug is increasingly maddening.  I've noticed that it seems to affect messages which load html in particular, although I can't confirm if it's exclusively this type or not.
I can confirm this problem, and, as fas as I can tell, that it's related to the size of the email being displayed. If the email is bigger than around 40Kbytes, it's marked as read even when the delay marked as read option is configured with a big number of seconds.
The problem does not happen in thunderbird 1.5.x, only in 2.0.x, and it's also it's exclusive of IMAP accounts.

I want to know if there's a patch or release of thunderbird 2.0.x that solves this (very annoying) issue.
[commenting here rather than bug 452242]

Mauro's comment 6 suggests it may be happening to messages >40k. I can confirm this. my about:mozilla message is 43k.

Further testing:

1. clicked LAST message (55k) in the account's list - it immediately went read
2. clicked a message (64k) that is far from last in the list - it stays unread
3. two messages unread at bottom of list: 
   - clicked last (2k) - stayed unread
   - clicked second last (>40k) - immediately went unread

It would seem to not be a widespread problem or there'd be more reports and I would see it more often (I get some large messages).  So is there something more than size that helps trigger this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #7)
> [commenting here rather than bug 452242]
> 
> Mauro's comment 6 suggests it may be happening to messages >40k. I can confirm
> this. my about:mozilla message is 43k.
> 
> Further testing:
> 
> 1. clicked LAST message (55k) in the account's list - it immediately went read
> 2. clicked a message (64k) that is far from last in the list - it stays unread
> 3. two messages unread at bottom of list: 
>    - clicked last (2k) - stayed unread
>    - clicked second last (>40k) - immediately went unread
> 
> It would seem to not be a widespread problem or there'd be more reports and I
> would see it more often (I get some large messages).  So is there something
> more than size that helps trigger this?
> 

Yes, it is: It should be the first time you open that particular message. The best way to reproduce the bug is to close thunderbird and open it again.
If you manually mark the message as unread, to try to reproduce the problem again, it will not show up.


wada, is this a dupe of bug 373366?
(In reply to comment #11)
> wada, is this a dupe of bug 373366?

I can say nothing unless evidence(IMAP log with timestamp) of "thunderbird randomly marks imap messages as read" will be provided, although I feel that phenomenon/issue of bug 373366 is involved in this bug's "thunderbird randomly marks imap messages as read".
M. LaPlante, can you check bug 373366 and comment again?
duping
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: