folder not marked as read with last mail marked as read. folder is still bold

NEW
Unassigned

Status

6 years ago
3 years ago

People

(Reporter: nobs, Unassigned)

Tracking

({reproducible})

x86_64
All
reproducible

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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
(Reporter)

Comment 1

6 years ago
just auto-update to v13

bug is still valid
Version: 12 → 13

Comment 2

6 years ago
Can you try rightclick on the folder -> Properties-> repair?
(Reporter)

Comment 3

6 years ago
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.

Comment 4

6 years ago
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).

Updated

6 years ago
Status: UNCONFIRMED → NEW
Component: General → Database
Ever confirmed: true
Product: Thunderbird → MailNews Core
QA Contact: general → database

Updated

6 years ago
Summary: folder not marked as read with last mail → folder not marked as read with last mai marked as read. follder is still bold

Comment 5

6 years ago
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.

Updated

6 years ago
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.

Comment 7

6 years ago
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.
(Reporter)

Comment 8

6 years ago
Confirmed

This bug-report is still valid with 17.0.2.
(Reporter)

Comment 9

6 years ago
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.

Comment 10

6 years ago
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
(Reporter)

Comment 12

3 years ago
the error still exists in 31.6.0
(Reporter)

Comment 13

3 years ago
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"

Comment 14

3 years ago
Yes, I also sometimes see the problem in this scenario.

Updated

3 years ago
Keywords: reproducible
You need to log in before you can comment on or make changes to this bug.