User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 When I expand a news account (using the + button on the accounts left side) to reveal the groups within, it probes the server to see how many new messages each group has. This works for some groups, where the brace'd number is shown on the right of each group name, but others don't. This has been happening for some time (perhaps back to 0.9.8), and affects the same groups each time). Clicking on the group then reveals (after polling the server?) the real number of new messages. Reproducible: Always Steps to Reproduce: 1. Collapse a news account. 2. Wait until the affected groups should have new messages. 3. Expand the news account, and verify that some groups "new message count" hasn't been updated properly. 4) If quick enough, this can be further verified by clicking on any group - any that are broken will suddenly report a significant increase in the number of new messages - much more than could be found between the account expansion and the selection of the group. eg. refresh a group. Clicking it again immdeiately should typically show no additional new messages. Wait a long time (say 1 hr) and follow the steps above. The group should now show a reasonable number of new messages. Those groups that are broken won't show the additional messages until you actually click on the group to force an update. Actual Results: Any newsgroups that were checked would now be properly sync'd. Expected Results: All subscribed groups for that account should have had their "news message count" updated properly. Then any additional clicks on ANY groups should report a bare minimum (or 0) new messages.
I bet this is bug 103012 *** This bug has been marked as a duplicate of 103012 ***
verified dup. we've had reports that this fixed the problem in bug 103012. please file a new bug if that hasn't fixed it for you.
Assuming the fix is in by Sep27, I'm still seeing the problem. Details of what I see as the difference between 103012 and this bug are below... I'd argue your definition of the problem: Old: > When Mozilla went to update the unread count it would update all of the groups > until it hit one with an empty message count and then stop. When Mozilla went to update the unread count it would update all of the groups until it hit one with a *zero unread message count* and then stop. My test case (based on bug 168005 that just got marked as a dup of this one) has say 10 groups, all with many messages (mostly) marked read, and it seems to stop at the first group with zero unread messages. Is that not different to what you're seeing? And another thing... it doesn't actually *stop* updating the groups according to the status bar - just that the unread messages indicator for each group isn't updated. sTu.
I'm happy now... :) sTu. *** This bug has been marked as a duplicate of 103012 ***
Right, there was a fix checked in that solved most people's problems. Thanks for commenting back.