User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0 Build ID: 20120601045813 Steps to reproduce: hopping to new mail using "N" then acknowledge "go the next unread in folder..." Actual results: last mail get marked as read in the list of mails but folder in the list of folders is still marked as unread (bold 1) if you cycle through unread mailboxes and enter come to the same folder again, it gets marked as read finally Expected results: mark the folder as read when the last mail in it gets read
just auto-update to v13 bug is still valid
Version: 12 → 13
Can you try rightclick on the folder -> Properties-> repair?
can try... but it happens on many (all?) folders and the installation is quite new in the Inbox another strange thing happened now: "repair" brings back a lot of emails as "unread" marking them with "all in folder as read" works first, but repair brings them back again as "unread" marking them in the list of messages with CTRL-A and then "mark as read" really works (no "bring back effect" after repair" I will further investigate when new mail comes in.
Created attachment 630557 [details] screenshot I can confirm this in some way, on TB16, win XP. Messages marked via the menuitem "mark folder read" are not properly set "read" in the database. The screenshot shows the msg source having X-Mozilla-Status: 0000. It should be 0001 (read). The msg is rendered as read. After repair, the states of the messages are fixed (the 0000 msg comes shown as unread).
Status: UNCONFIRMED → NEW
Component: General → Database
Ever confirmed: true
Product: Thunderbird → MailNews Core
QA Contact: general → database
Summary: folder not marked as read with last mail → folder not marked as read with last mai marked as read. follder is still bold
Confirmed. This bug appeared de novo a few months back (apologies that I don't know which version). It is still there in version 15. I do use the 'unread' status to check that I have seen all the stored emails, so it is a real nuisance to have to re-read them after storing them just in case they really are new. The bug is manifested whether a delay inmarking them read is set or not.
OS: Linux → All
Summary: folder not marked as read with last mai marked as read. follder is still bold → folder not marked as read with last mail marked as read. folder is still bold
> Bug summary: folder not marked as read with last mail marked as read. > folder is still bold Bug 840418 is for "READ flag by Mark Folder Read is not written to X-Mozilla-Status:" what is observed in Tb 17, and it is reproducible, and it looks same in "Select All+Mark As Read", but "still Mbox is bold even after all mail's status at thread pane is Read" can't be observed in test for that bug. To bug opener and problem reporters in this bug: Do you still see pheomenon of "bold even thouh no mails is marked as Unread at thread pane" part of this bug? By the way, same problem on other flag such as "Replied" is already found in that bug.
Version 17.0.2. My experience is the same as Comment 5 above, except that the irritating failure to accept that an email has been read is erratic. Sometimes things work as one expects, sometimes the email remains in bold as 'unread' even after it has been read and moved to a suitable folder. I agree too that this behaviour was new a few months ago and has persisted through several version changes.
Confirmed This bug-report is still valid with 17.0.2.
I just had the bug with 17.0.3 . And when I tried "repair folder" I got several old unread message after the repair. So my guess is an inconsistency between different locations in the message database about the "read"-status.
Yes, that is quite possible. Please observe it now if you get the problem even after this repair.
(In reply to :aceman from comment #10) > Please observe it now if you get the problem even after this repair. "Repair Folder"(aka "Rebuild Index") forces re-parse of "From " line and headers such as X-Mozilla-Status: with discarding almost all data in .msf(MsgDB). So, because READ flag is not written to X-Mozilla-Status: header in message source due to bug, if you do "Repair Folder" without forcing Tb to write "READ flag to X-Mozilla-Status:", "Repair Folder" surely forces to change any mail of "Read status but no READ flag in X-Mozilla-Status:" to Unread status. Known way to force "READ flag in X-Mozilla-Status:" in Tb 17 is; - Mark a mail as Unread by clicking "read column" at thread pane, then Mark As Read by clicking "read column" at thread pane - Select All at thread pane, then Mark As Read via context menu (I can't observe problem with "Select All + Mark As Read" in Tb 17) By the way, there is no need to report funny phenomena on READ flag any more, because what is wrong is already clear in Bug 840418. We need to know; - Regression window (perhaps problem from Tb 12, after "pluggable file store") - Same problem on other flags - Easy/simple/sure recovery procedure for future victims of problem
the error still exists in 31.6.0
I can maybe kinda reproduce the behavior: 1) wait until you have more than one unread mails (auto-filtered into different folders in my case) 2) jump to each by using the keyboard shortcut n and wait until it gets marked as read 3) the folder of the last one stays marked as "contains unread"
Yes, I also sometimes see the problem in this scenario.
You need to log in before you can comment on or make changes to this bug.