User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060906 SeaMonkey/1.1b Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060906 SeaMonkey/1.1b After compacting an Inbox, the total number of messages on the status bar is set to 0. In order to get the correct number of messages to display again, SeaMonkey needs to be closed completely. Reproducible: Always Steps to Reproduce: 1. Delete some messages from an Inbox 2. Right-click the Inbox 3. Select "Compact This Folder" 4. Click on a mail folder other than the Inbox 5. Click on the Inbox Actual Results: The "Total" count on the status bar shows 0 Expected Results: The "Total" count on the status bar should show the correct number of messages in the Inbox

FWIW: happens with TB as well. So this should probably moved to CORE, but i can't find a fitting category? I could never quite find the steps to reproduce this behavior, however, i have the option set to automatically compact, so it is very likely that compacting indeed is the culprit. Using version 2 alpha 1 (20060908) on OS X 10.4

Thanks for confirming that this bug also happens with TB. I'll move it to Core under the component "MailNews: Database" since it deals with building the MSF file. Also, I've been looking through LXR, and it appears that this bug is a result of the checkin for bug 337815 (see attachment 229361 [details] [diff] [review]). In that patch, the number of messages is set to 0 in a function that is also used when folders are compacted. I tested this with a SeaMonkey build from early 7/17 (right before the checkin for that patch), and the bug is not present.

(In reply to comment #0) > In order to get the correct number of messages to display again, > SeaMonkey needs to be closed completely. Properties(of the folder)/"General Informations" tab/"Rebuild Summary Files" button was an available recovery procedure. (Tested with SeaMonkey 2009083109 build/Win2K)

I can reproduce this now, if I compact the Inbox while it's open, and then mark an unread message read (or, probably mark a read message unread). The second action seems to expose the problem...but I suspect it is the compaction that's causing the problem.

I noticed that this bug has shown up on the 1.8.0.x branch, which is more evidence that it has something to do with the code that I mentioned earlier. This has been tested using SeaMonkey 1.0.5 on WinXP and Thunderbird 1.5.0.7 on Win2K. (In reply to comment #3) > Properties(of the folder)/"General Informations" tab/"Rebuild Summary Files" > button was an available recovery procedure. > (Tested with SeaMonkey 2009083109 build/Win2K) Thanks, I almost forgot about that feature. That's a much better workaround than closing the entire program.

> ... > (In reply to comment #3) > > Properties(of the folder)/"General Informations" tab/"Rebuild Summary Files" > > button was an available recovery procedure. > > (Tested with SeaMonkey 2009083109 build/Win2K) > > Thanks, I almost forgot about that feature. That's a much better workaround > than closing the entire program. Well, yes and no... one can see it as "better" than closing/restarting SM. I consider throwing away and reconstructing a mess of information that had nothing wrong with it to be "untidy" at the least (if not "disturbing").

(In reply to comment #6) > Well, yes and no... one can see it as "better" than closing/restarting SM. I > consider throwing away and reconstructing a mess of information that had > nothing wrong with it to be "untidy" at the least (if not "disturbing"). From a technical standpoint, you're right. I was only thinking of which solution was more convenient, since restarting means having to enter passwords again, having to remember which tabs were open, losing session cookies, etc. That doesn't necessarily make it better overall though, so bad choice of words on my part.

revert the change that caused this regression, and fix it an other way, by clearin g the total and unread counts in the caller of InitFromTransferInfo instead of the routine itself.

this was a regression in 1.5.0.7 that we should fix in 1.5.0.8

fixed on trunk and branch.

Comment on attachment 239269 [details] [diff] [review] proposed fix approved for 1.8.0 branch, a=dveditz for drivers

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

fix on 1.8.0 branch

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

verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 ID:2006102517

verified fixed 1.8.1.3 using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 ID:2007032620 - tested with the steps to reproduce from comment#0