User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040524 Firefox/0.8.0+ Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040524 Firefox/0.8.0+ I have IMAP accounts, each with server-side filtering of mailing lists into folders. I have thunderbird configured to check these folders for new messages. With recent aviary builds, I've begun seeing odd behaviour. When a folder has new messages, I go to that folder and read them. The unread count goes to zero, BUT, if I leave the folder (ie. choose another), on the next check for new messages (either scheduled or when I click on the "Get Mail" button, the unread count (in the "Folders" pane) goes back to what it was before I read the messages. If I go back to the folder, it returns to zero. This only seems to happen for the last folder that had unread messages - ie. if I reproduce it for a different folder, it stops happening for the previous one. It doesn't happen all the time, but enough to be irritating. This happens with at least two different accounts (same profile). One is a SunONE Messaging Server, the other Cyrus IMAP, so I'm pretty sure it's not a server issue. I guess it could be a bad index cache or something, maybe as a result of some of the recent profile changes - it definitely started happening shortly after I start using the aviary branch. Reproducible: Sometimes Steps to Reproduce: 1. 2. 3.

a protocol log would be useful here too: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap my guess is that this is related to a change I made so that we don't issue a STATUS command on a selected state folder, but do a NOOP instead...an annotated protocol log (i.e., with a comment about which folder had the wrong counts) would be helpful. Thx!

Attaching annotated protocol log as requested.

In this example, the folder "jabber/jabberd" was showing the wrong count. This log starts from when message-id 783A3EE2AA17B349B869477606E922A6AE4A8D@USMAIL04.morinda.com was new - you can see me go in and read it. When I left that folder, the unread count returned to (1).

BTW, what I previous interpretted to be this only happening to the last folder that had received new messages may actually be that it only happened to folders that have a "cached" (kept-alive) connection - I use up the default 5 connections pretty quickly. This would seem to gel with your NOOP theory...

My guess is that NOOP doesn't clear the recent count, so the second time its run, it uses the previous value. Duh. So, I think the fix is to clear the parser's fNumberOfRecentMessages before issuing the NOOP. Proposed fix upcoming.

Related to bug 239196?

thx, yeah - that one should be re-closed, and I'll leave this one open.

Have applied the proposed fix and now waiting to see if the problem comes back...

I'm afraid it looks like this patch is a little too aggressive - it appears that those folders which have open connections now do not report unread messages on "Get Mail" checks anymore :(

I think they report the unread/recent messages on the first check, but not subsequent checks - but I have to turn off idle support to be sure. Maybe I should just clear the recent count on NOOPs...

no, that won't work - that's all we're doing in the case where you're seeing the problem...maybe just clear it when we actually select the folder in the ui? Argh.

I suppose it depends on your interpretation if "recent". If I get a bunch of new messages in a mailing list folder, I might go and peek to see if any are really interesting, but may not read all of them right away. I still want the unread count for that folder to be accurate. The difference between "recent" and "unseen" in IMAP has always been a bit fuzzy for me ...

this doesn't make sense - we're actually ignoring the num recent count completely, partly because RECENT is not reliable and you can have RECENT read or deleted messages...but it does make it silly to use NOOP, which only gives you a RECENT count. It's probably the numunread that we're not clearing, and that's what caused your initial bug report. But I doubt this patch actually caused a change in behaviour - it was probably broken before. But, I think I'm going to back out the fix that caused this problem in the first place, and think of a better fix for the very first problem of doing a STATUS with a selected folder. One possibility is to just get the new headers for the folder if we had a selected state connection to it, but we don't really know that at the point which we need to know it at...

I'll check this in, and re-open the old bug about not issuing STATUS for selected state folders.

*** Bug 245589 has been marked as a duplicate of this bug. ***

Have backed out the previous proposed fix and applied the new one. All seems to be well with the world (or at least my world) again... thanks!

Ian what version of thunderbird were you using when you filed this? A trunk or a 0.7 branch build?

2004-06-04 patch is now in the aviary 1.0 branch

fixed by backing out fix for bug 239181

(In reply to comment #19) > Ian what version of thunderbird were you using when you filed this? A trunk or a > 0.7 branch build? I was using my own build from AVIARY_1_0_20040515_BRANCH

*** Bug 245769 has been marked as a duplicate of this bug. ***

Iain, if you get a chance, can you try this patch http://bugzilla.mozilla.org/attachment.cgi?id=150230&action=view in http://bugzilla.mozilla.org/show_bug.cgi?id=245769 and let me know if the folder unread count still works, and we notice new mail? I'm thinking of checking it in since it will prevent us from issuing STATUS on a folder that we are in the selected state on. Thx!

(In reply to comment #24) > Iain, if you get a chance, can you try this patch Sure! I have incorporated this in my debug build, and am running with it now. Looks fine so-far .. will see how it behaves over the next few hours ....

(In reply to comment #25) > (In reply to comment #24) > > Iain, if you get a chance, can you try this patch > > Sure! I have incorporated this in my debug build, and am running with it now. > Looks fine so-far .. will see how it behaves over the next few hours .... It's been working fine since ... I have observed no anomalous behaviour. Now I'm off to watch the Stanley Cup final ... so no more testing today :)

Iain, thx for trying it out.