User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061201 SeaMonkey/1.5a Build Identifier: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1pre) Gecko/20061201 Thunderbird/2.0b1pre" - Build ID: 2006120103 Messages which ave been read into the current folder or newsgroup since we last entered it, won't be find by "Next unread" Reproducible: Always Steps to Reproduce: 1. Read, or Mark as Read, all unread messages (if any) ouside of "Junk" and "Trash" folders. 2. Go to some newsgroup, to Inbox, or to some folder which is the destination of a "Move to" action in some message filter(s). 3. Wait for new messages to arrive into current folder or newsgroup, as shown in left pane. 4. Hit n (or click Go => Next => Unread Message). Actual Results: Nothing happens if all new messages are in current folder or newsgroup. If there are some for _another_ folder or newsgroup, a popup appears, asking if we want to go there. Expected Results: Next newly-arrived message for current folder or newsgroup should be made current. Workaround: Go to another folder or newsgroup, even one with no new messages. Then n will work again.

I see this on newsgroups, although I don't see it on my IMAP mail accounts.

(In reply to comment #1) > I see this on newsgroups, although I don't see it on my IMAP mail accounts. > OK, after some more testing, it seems not to happen in Local Folders. (I use the Global Inbox and have no individual folders for mi POP3 accounts.) I definitely see it in the Mozilla newsgroups (which are the only ones I follow).

I just tried to reproduce this with 2b1-1215. I notice that the newsgroup name has bolded and shows a count, but I don't see any indication of a new message in the thread pane. I use View | Threads | Threads with Unread, and I had kept the newsgroup selected after marking-all-read, so the thread pane continued to show a number of all-read threads. After the new message was indicated in the folder pane, no change in the thread pane. Tony Mechelynck, do you see the same thing?

we have a bug where if there are gaps in the article numbers, e.g., an article was canceled before we could download the header, we'll count that article as unread. That bug has been around forever. But recently, I made it so that instead of the count getting corrected when you click on the newsgroup, the bad count persists. I have a fix for that regression. And I'm trying to make it so we automatically mark the missing articles as read. bug 298737 has a patch for the first issue, and I'm looking at fixing the second one.

(In reply to comment #3) > I just tried to reproduce this with 2b1-1215. I notice that the newsgroup > name has bolded and shows a count, but I don't see any indication of a new > message in the thread pane. I use View | Threads | Threads with Unread, and I > had kept the newsgroup selected after marking-all-read, so the thread pane > continued to show a number of all-read threads. After the new message was > indicated in the folder pane, no change in the thread pane. > > Tony Mechelynck, do you see the same thing? > What I see is as follows: If at least one of the newly bolded groups is not the current groups, or if there is a newly arrived mail, then if I hit n I get a popup asking me if I want to go to the next unread message in <whatever>. If the newly bolded group is the current group, and there are no other bolded groups or folders (not counting Junk and Trash) then hitting n does nothing, but after clicking a _different_ group or folder name in the left pane, n asks me if I want to go back. This is illogical: I would expect to be led to the newly arrived message, even if it is in the current group (after a refresh if necessary). I usually don't see a new bolded or underlined header in the right pane, but that doesn't mean a thing, since there are far more articles in groups like mozilla.support.firefox (and similar) than can fit onscreen even with the newsreader window maximized. (In reply to comment #4) > we have a bug where if there are gaps in the article numbers, e.g., an article > was canceled before we could download the header, we'll count that article as > unread. That bug has been around forever. But recently, I made it so that > instead of the count getting corrected when you click on the newsgroup, the > bad count persists. I have a fix for that regression. And I'm trying to make > it so we automatically mark the missing articles as read. > > bug 298737 has a patch for the first issue, and I'm looking at fixing the > second one. > I see your "phantom messages" bug when there is a gap (and BTW bug 290826 ought to get either "confirmed" or "resolved duplicate" status after all that time), but this is different: there really is an actual new message on the server, the left pane shows it, but hitting n doesn't go to it; OTOH, going to a group with no new messages (such as mozilla.announce which is a low-traffic group), and _then_ hitting n, gets a popup asking me if I want to go back to the group I just left, and if I answer yes to that, the new message is found.

I think there's another bug on this that this should be duped to, but I'm not finding it (it may be this bug that I was remembering). In any case, this will be incidentally fixed by bug 311774.

Tony, bug 311774 is fixed. is this problem gone for you? (In reply to comment #6) > I think there's another bug on this that this should be duped to, but I'm not > finding it (it may be this bug that I was remembering). > > In any case, this will be incidentally fixed by bug 311774.

In reply to comment #7 Yes, AFAICT the problem has disappeared. => WFM Sometimes I see the newsgroup count not decreasing after reading one or more messages (news only, not mail) but IIUC it's a different bug.