Unread mail count in Archive unified Folder is not equal to the sum of its subfolders' unread counts

NEW
Unassigned

Status

Thunderbird
Folder and Message Lists
8 years ago
a year ago

People

(Reporter: protz, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a4) Gecko/20100413 Minefield/3.7a4
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100413 Shredder/3.0.4

I have a GMail account, another non-gmail IMAP account, both have Archives. What I see (*Smart Folder View*) is:

Archives (regular appearance, no unread messages, nothing)
|-- @provider1.com (same, no unread messages)
|-- @gmail.com (1) (Bold, 1 unread message)

This is very inconsistent and seems quite different from all the other unread count bugs I have seen. So maybe it's a duplicate, but I'd rather make sure. The stories goes on.

Next step: right-click on "@gmail.com" folder, and mark all read.
Result: Thunderbird is totally wrong

I now get:

Archives (1) (Grey appearance, as if it has unread messages it has not fetched, count is 1)
|-- @provider1.com (no unread messages)
|-- @gmail.com (1) (Grey appearance, 1 unread message)

But I just asked Thunderbird to mark all the messages in GMail's Archive as read! How can this possibly be?

I must right-click on "@gmail.com" once again, and mark the folder read one more time for the count to get right.

It's been like that for as long as I can remember, and I don't think I have this issue with other accounts, only the GMail one.

Reproducible: Always
(Reporter)

Comment 1

8 years ago
Still seeing this with a fresh comm-1.9.2 build from today. This is not 533928 as it's been committed to 1.9.2 already. Ludo, any ideas?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yeah it might be due to the very specific way we implement archive on gmail. On Gmail we use the all-mail folder by default for archives, that might end up in showing issues. see bugs 498659 and 532159.

Other than That I'm a very conservative user and I don't use the unified folder view. David Thoughts ?
Summary: Unread mail count in Archive Smart Folder is not equal to the sum of its subfolders' unread counts → Unread mail count in Archive unified Folder is not equal to the sum of its subfolders' unread counts

Comment 3

7 years ago
Mark all read doesn't download headers first, so if we've found out about the unread messages using the STATUS command, and there are still non-downloaded headers, mark all read might still leave unread messages. There's a bug filed on that.
(Reporter)

Comment 4

7 years ago
Ok. What about the first case?
> 
> Archives (regular appearance, no unread messages, nothing)
> |-- @provider1.com (same, no unread messages)
> |-- @gmail.com (1) (Bold, 1 unread message)
> 

It also happens that Archives has, for instance, 2 unread and @gmail.com has 3. There's no "mark as read" implied here. Is it related to another bug or is it worthwhile to keep this bug open just for that first case?

Comment 5

7 years ago
duplicate of Bug 550520 - Smart Folder unread count != sum(contained folder counts) ?

Comment 6

6 years ago
I think this bug is still present in Thunderbird 9.0 (beta channel), Win7.
I have two Gmail accounts.
The archives folder shows a summary count of 58.
Gmail account #1 shows zero unread, which matches the actual status of that account.
Gmail account #2 Shows 3 unread, yet ALL are read in the account inbox and sub-folders.

Gmail account #1 ALWAYS reads correct, the unread count matches the actual status.
Gmail account #2 is ALWAYS wrong, and the Archives number always shows some unread.  Even if I read them in the inbox or a sub-folder, I have to go back to the archives folder and mark it read as well.

Yet I've checked all the settings, both in Tbird and in the Gmail settings and can't find any differences between these two accounts that would cause this behavior.

This always messes up the mail notifications pop-up, as it shows the unread from the archives, rather than the newly arrived message info.
You need to log in before you can comment on or make changes to this bug.