version 1.6a1 (20051202) and version 1.6a1 (20051113) steps to reproduce in 3 pane window: 1. expand a news server list subscribed newsgroups 2. simply mouse over any newsgroup and hold for 6+ seconds 3. repeat step 2 - mouse over a second newsgroup, third, etc. 4. if can't reproduce try ctrl-shift-c on a newsgroup and then mouse over some other newsgroups expected results: tooltip pops up with number of messages actual results: newsgroup goes unbold, as if all messages were read, but in fact they are not) - in some, but not all cases, the tooltip still pops up. In some cases neither happens: no tooltip but newgroup name stays bold. reproducibility: ~70% - no predictable pattern or trigger. All newsgroups seem suseptible, if on first attempt the newgroup doesn't unbold, coming back to it after trying other groups often does affect it. I restarted TB to rule out corruption and was able to recreate the problem. Only happens with news. Does not happen with mail. Doesn't happen in suite and probably not a coincidence, suite doesn't have tooltips for newsgroup folders. ==> regression wrt tooltips feature. I don't use newsgroups enough say this definitely worked before, but I think I would have noticed it, so perhaps this is a ... ... regression.

I've seen the loss-of-bold, and I think it is a regression. The "tooltip with number of messages" is the one from bug 314124, right? I'm not seeing a tooltip for the newsgroups, and since that new tooltip only counts "new messages" I wouldn't necessarily expect to see one for newsgroups. I think this only happens when the new message headers haven't yet been downloaded.

(In reply to comment #1) > > I think this only happens when the new message headers haven't yet been > downloaded. This makes sense. There is also Bug 298737

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

Seeing this on linux too, I'd say reproducibility is very high. Definitely wasn't a problem in 1.5. (though I don't get the tooltip mentioned - which is good imo)

Could this be fixed for 2.0? It's a very visible regression (from bug 314124) for news. Updating summary.

Tweaking summary more for searchability

A patch at bug 298737 has been checked in which I believe addresses *this* problem without fixing the problem originally at that bug (which predates the New Messages Folder Popup).

-> FIXED by bug 298737 landing (attachment 248023 [details] [diff] [review]).

It is not fixed on Trunk: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20061211 Thunderbird/3.0a1 ID:2006121103

Trunk is ok for me. Though it seems on restart, it forgets the read count of the last newsgroup you had open. (Go to a group with 1 unread, read it and quit, it will show 1 unread initially until you hover. Go to a group with 4, read one and quit, after restart it shows 7 until hover, after which it shows 3 as expected.)

that worked for me, Magnus - though I had to expand the server manually on restart, even though I shut down with it open (this is with 2.0 build)

Yep, same here. 2.0 doesn't seem to remember the state... You can see the wrong count momentarily though as it goes through the newsgroups fetching all new msgs. If you mark the group as a favorite folder you can also see the false counts there (trunk atleast).

With 2b1-1212, I see the same results Magnus describes if I quit while leaving the server node expanded. When I tried again, collapsing the node first, the read count was accurate on restart. But this bug itself has been squashed, yay!

Bug 364063 filed for the unread count of last group issue.