Closed Bug 564450 Opened 14 years ago Closed 13 years ago

When open non-cached/loaded message thru IMAP, it is incorrectly marked as read.

Categories

(MailNews Core :: Networking: IMAP, defect)

1.9.2 Branch
x86_64
Windows 7
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 662792

People

(Reporter: honzaBugZilla, Unassigned)

References

()

Details

(Whiteboard: [has protocol logs])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; cs; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; cs; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4

Details you can find here: (i create small web page about this problem) http://projekty.mujserver.net/bugReports/Thunderbird-3-0-4-message-read/

Reproducible: Sometimes

Steps to Reproduce:
1. Open Thunderbird
2. Configure thunderbird as described here http://projekty.mujserver.net/bugReports/Thunderbird-3-0-4-message-read/ in first section. (you must have fresh account or you can also delete message storage file for INBOX (C:\Users\Honza\AppData\Roaming\Thunderbird\Profiles\<profile>\ImapMail\<server>\INBOX), index (*.msf) you can leave without change)
3. Restart Thunderbird to apply changes (may be optional)
4. Click on some message wich is bigger than 50kb. (Is will be marked as read almost realibly on big messages: 1MB+) It will do not happen often on very small messages (<5kb). For detailed description see: http://projekty.mujserver.net/bugReports/Thunderbird-3-0-4-message-read/
Actual Results:  
Message is marked as read.

Expected Results:  
Message should be leaved unchanged. (un-read)

http://projekty.mujserver.net/bugReports/Thunderbird-3-0-4-message-read/

I tested this also with Thunderbird 3.1 beta. Result is same.
I also tested this with "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100221 Shredder/3.2a1pre". Results is also same. Message has been marked as read.

IMAP log is available here: http://projekty.mujserver.net/bugReports/Thunderbird-3-0-4-message-read/imap.zip 
 It is zipped imap.log. Password for this log please request on my mail. (in log is complete message and some e-mail adresses)
 Proccess of taking log:
 1) Start Thunderbird (with logging enabled)
 2) Click on big message. Waint until it will be downloaded and marked as read.
 3) Than I marked it back to un-read. (pressing M-key; I do not remember if I perform this step, sorry)
 4) Close Thunderbird.

If you want, I can also capture screencast or make more complex log.

This bug is critical for us. It makes Thunderbird unusable for us. Because read/un-read flag is critical for us. This bug causes unrecoverable data loss (losing un-read flag). We now switched back to Outlook, which do not have this problem, but it is incredibly slow.
Version: unspecified → 3.0
UPDATE: Message is marked as read before it loads. 
1) Click on message
2) Wait 1,2,3 seconds
3) Message marked as read, but is not loaded yet.
4) Wait 1,2,3 seconds, message loads and is still readed. :(
5) Press M-key to get it back unread
UPDATE 2: When you mark message back to unread before it loads (in the middle of 3 and 4 in my last comment), it will be unread also after message loads.

So message is marked as read few seconds after click. If it is loaded before this timeout, it will be unread forever.
Confirmed. It behaves in the same way for me.

Thunderbird: "Mozilla/5.0 (Windows; U; Windows NT 6.1; cs; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4"
Same for me. :-(

Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
Component: Folder and Message Lists → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: folders-message-lists → networking.imap
Whiteboard: [has protocol logs]
Version: 3.0 → 1.9.2 Branch
see Bug 662792 for an imap only issue that may be what you're seeing, along with some details. I'm reasonably sure this is the same bug, and there's a fix in that bug.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.