Closed Bug 229003 Opened 21 years ago Closed 21 years ago

Unread count persistently inaccurate

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
Mac System 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jrhett, Assigned: Bienvenu)

References

Details

Attachments

(2 files)

Mozilla IMAP debug log
186.63 KB, text/plain
Details
couple more fixes
2.47 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

The unread count in IMAP folders sometimes becomes inaccurate.  After it does
so, it appears to persist with no fix.  I believe this is related to mail
filters and/or junk mail controls.

Reproducible: Always

Steps to Reproduce:
1. See a folder with unread messages (5)
2. Open folder, see (2) unread messages
3. Read and optionally delete the unread messages
4. Folder unbolds and appears normal -- navigate to another folder
5. After a few minutes, folder will show (3) unread messages
6. Open folder, find no unread messages.
7. Repeat steps 4-6 infinitely.

Actual Results:  
Every time I enter the folder, the unread count disappears.  After I navigate
away, the unread count returns a few minutes later.

Expected Results:  
There are no unread messages in the folder, so don't display them.

There are only 4 messages in the folder at all, so the unread messages are not
off-screen.  I have also witnessed this problem with empty folders.

The offset remains constant across restarts and reboots.  The offset remains
constant when new messages are received.  (4) unread = 1 real unread, etc etc.
I too see this exact same behaviour.  It didn't happen in .3, but it is now
happening in .4 with the same exact profile.
Are you checking this folder for new messages (folder properties | check this
folder for new mail)? Have you tried the 12/19 build? I believe this is fixed in
that build.
> Are you checking this folder for new messages (folder properties | check this
> folder for new mail)? 

Yes.

> Have you tried the 12/19 build? I believe this is fixed in that build.

No.  Given that bug reports on point releases tend to get comments back like
"it's not supposed to work yet" running the daily builds seems like a pointless
exercise.  I'll do confirmation when 0.5 RC1 comes out.
OS: Windows XP → Mac System 7
I have tried nightly build 12-19 and this is still broken.

My conditions (in case it helps):
Thunderbird 0.4 and 0.5a (20031219)
Junk mail filtering on (but no specific filters applied).
I have procmail filters that sort my mail into certain folders (ie
independently of Thunderbird).
Those folders are marked with 'check this folder for new...'

If a folder is left open/selected, the count remains accurate,
otherwise the new mail count seems to be added to what the
folder count was when it was last opened.

An example - the following is a sequence of recent unread mail
counts for my 'Junk' folder (using Thunderbird 0.4):

1. folder left open:    displayed=  6, actual=  6
2. folder left open:    displayed=177, actual=177
3. another folder open: displayed=203, actual= 26
4. another folder open: displayed= 41, actual= 15

After each of the above checks all the unread messages were
manually copied (unread) to another folder.


I have just tried the same thing in the 20031219 build and
got the following sequence:

1. another folder open: displayed=0, actual=0
2. another folder open: displayed=1, actual=1
3. another folder open: displayed=3, actual=2


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040111

The unread count seemed to be working fine from Mozilla 1.1 through about 1.5,
but became flakey around 1.6.  This is what I see in detail:

Note:  folder "X" has the "Check this folder for new messages" option checked

Log in to IMAP server.

1.  Folder "X" unread count shows 28
    Click on folder "X" to open it
    MINOR BUG: Unread count on folder "X" immediately changes to 27 (even before
a message is read)

2.  Junk mail scan completes, moves 2 messages to Junk folder
    Unread count on folder "X" now shows 25

3.  Read or delete remaining messages
    Unread count on folder "X" now disappears (at 0)

4.  Click on another folder "Y" with 1 unread message
    Read the unread message.
    HERE'S THE MAIN BUG: now the unread count of folder "X" goes back to 21.

5.  Click on folder "X" and the unread count immediately disappears (at 0).

6.  Click on another folder "Z" with 1 unread message
    Read the unread message
    Folder "X" remains correct with no unread count.

Basically, it acts "broken" once, then after you click on the folder and it
properly resets back to zero it seems to work OK from that point on (even when
new messages are received).

Not for me.  I've got folders that always show +N (10 in one folder, 64 in
another) new messages over the actual count.  When I enter the folder it
corrects itself.  After I leave the folder and it checks again in the background
the unread count goes to +N messages again.

I'm IMAP/SSL/Cyrus Server.  No other mail client has this problem.

If you need any information from me, ask now because we are removing all Mozilla
products from use, and I'll no longer have a test platform for this.
Thomas, can I get an imap protocol log showing what happens when you go through
the steps you describe, by following these instructions?

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Joe, are you using a pre 12/19 build or a post 12/19 build?
I'm using 0.4 release.
Attached file Mozilla IMAP debug log — 
Note that server hostname change to "my.imap.server" for security reasons.
Here is a more concise test case, and I have attached the debug log above (which
was confusing at first, as I have found that the debug log is cleared when
Mozilla exits!)

1.  Log in to IMAP server.
2.  Click on a monitored folder "incoming-twb0" (one that has "check for new
mail" enabled).
3.  Mark all messages read in this "incoming-twb0" folder.
4.  Wait for a new message to arrive in the "Inbox" folder.
5.  When the "You have new mail" notification comes up, the proper unread count
shows up for "Inbox", but now the "incoming-twb0" folder shows 7 unread messages.
6.  Click on "incoming-twb0" and unread count will immediately reset to the
correct value of zero and the status bar shows "There are no new messages on the
server."

Thomas, thanks a lot for the log. I see the basic problem - you have 7 messages
with the deleted flag set, but not the seen flag set. Also, in the log, I
*don't* see you marking all the messages read. How did you mark all the messages
read? Also, do you know how those 7 messages came to be deleted without getting
marked /Seen? Did you do a multi-select and delete the messages? Or do a
shift-delete? I did check in a change on 01/11 so that if you delete unread
messages (such that they get moved to the trash), they get marked /Seen.
"I did check in a change on 01/11 so that if you delete unread
messages (such that they get moved to the trash), they get marked /Seen."

Well if you weren't doing this before, then that is exactly the nature of the
problem.  I can personally verify that anytime the junk mail controls move an
unread message out of the folder is when that count increments.

That said, the fact that this problem survives restarts indicates a different
problem -- when do you actually remove deleted messages?  I just did some tests
using Thunderbird and then Mutt, and Mutt shows hundreds of deleted messages
that are weeks old in most of my folders.  "Expunge inbox on exit" is checked,
but I take it that this only applies to the inbox.  When do you delete messages
from subfolders.

Also, this may be exactly why there are so many problems with performance and
locking problems as I reported in other bugs.  If nothing is actually removing
the deleted messages from the folder, then the folder size will only grow and
grow....
We expunge the deleted messages when you select the folder, if there are more
than 20 deleted messages in the folder. If you're using the imap delete model,
such that deleted messages show up with a big red X, then it's up to you to
expunge the folder.
Assignee: mscott → bienvenu
this patch does two things:

1. If you do a shift delete, or are using the imap delete model, it makes
deleting a message store the seen flag as well.

2. Don't check the Junk or Trash folders for new messages, or no select
folders, unless the user explicitly says to check them for new messages.
Attachment #139446 - Flags: superreview?(mscott)
Comment on attachment 139446 [details] [diff] [review]
couple more fixes

oh, and there's one more change which allows you to create sub-folders called
Inbox (we should only prevent top-level folders called Inbox)
Attachment #139446 - Flags: superreview?(mscott) → superreview+
fixes checked in to 1.7 trunk builds.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 231948 has been marked as a duplicate of this bug. ***
*** Bug 229160 has been marked as a duplicate of this bug. ***
fixed on m4 branch.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040202

Bug still exists in 2/2/2004 nightly build--am I looking in the wrong place?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040209

Now WFM as of latest build.  Thank you!
Thomas, I suspect that it just took a while for your deleted messages to
eventually get compacted away. But in any case, I'm glad it's working for you!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: