IMAP trashcan unread message count not working in a proper way

RESOLVED INCOMPLETE

Status

Thunderbird
Folder and Message Lists
--
minor
RESOLVED INCOMPLETE
9 years ago
6 years ago

People

(Reporter: sebastiano, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [closeme 2012-06-11])

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.172.39 Safari/530.5
Build Identifier: 2.0.0.22 (20090605)

To reproduce, you need an IMAP account (with emptying of trashcan on exit set as true)
When moving unread messages to trashcan (located on a server within an IMAP account), trashcan folder is correctly updated, with bold typeface and unread message count.
TB will empty the trashcan at exit, and at next start you will find:
- the trashcan correctly reported as empty (no bold font, no unread count) OR the trashcan reported as it was before closing. Clicking on trashcan will show it obviously empty.
The OR depends on if you visit the trashcan before closing TB or not. If yes, you get bad behaviour. If not, everything goes.


Reproducible: Always

Steps to Reproduce:
1. login to imap account
2. delete unread messages (automatic spam deletion for example)
3. visit Trashcan folder before closing TB
Actual Results:  
Trashcan is improperly reported as containing unread messages, while it's empty.

Expected Results:  
Trashcan should be reported as normal folder (no bold typeface and unread count)
> Reproducible: Always
> Steps to Reproduce:
>(snip)
> 2. delete unread messages (automatic spam deletion for example)
> 3. visit Trashcan folder before closing TB
> Actual Results:  
> Trashcan is improperly reported as containing unread messages, while it's empty.

Similar phenomenon/issue to Bug 462880? 
> Bug 462880 IMAP folder displays mesages already deleted from web Gmail (If all mail in a folder is deleted. Response of "*0 EXISTS")
If Mail purge/Junk purge by retention policy doesn't update folder pane view for Trash, similar situation to Bug 462880 can occur at step 3, because you say "while it's empty".

Anyway, get IMAP log and check IMAP level flow.
(Reporter)

Comment 2

9 years ago
The IMAP trashcan works properly. I mean, if I delete messages on exit, messages aren't there anymore (I've cross cheched it with other mail agent and webmail). The nasty part is only the display of unread messages in trashcan, while the trashcan itself it's empty since last closing of TB.

It seems a bit different from the bug you mentioned: in this case, as soon as you click the uncorrectly reported trashcan, TB realizes that it's empty, it doesn't show any message, unread count get reset to zero.
(In reply to comment #2)
> It seems a bit different from the bug you mentioned: in this case, as soon as
> you click the uncorrectly reported trashcan, TB realizes that it's empty, it
> doesn't show any message, unread count get reset to zero.

It sounds folder view refresh issue upon Mail purge/Junk purge. "No explicit MailDB open upon Mail purge/Junk purge" may be one of causes.
(Reporter)

Comment 4

9 years ago
which kind of test can I do to investigate further?

What about "No explicit MailDB..." - is it something I can act on, or not?
(Reporter)

Comment 5

9 years ago
Created attachment 392915 [details]
TB window before closing

spam correctly detected and moved to trashcan
(Reporter)

Comment 6

9 years ago
Created attachment 392916 [details]
on reopening TB - trashcan marked as containing unread, but is empty

on reopening, TB shows trashcan as containing 1 unread message. But that folder is empty (cleaned on exit).
As I explained before, this only happens if you *visit* the Trashcan folder before closing.

Comment 7

6 years ago
 sebastiano do you still see this when using a current version?
Whiteboard: [closeme 2012-06-11]

Updated

6 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.