User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021107 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021107 I have Spam Assasin tagging mail as it comes in. A filter moves it to a spam folder, and marks it as read. However, when I look at the folder window, it has the spam folder bolded with a number of unread messages. Upon looking at the folder, the count is corrected. I'm not sure how much this matters, but I'm using an IMAP account. Reproducible: Always Steps to Reproduce: 1. Setup a filter to move to another folder and mark as read 2. Have folder pane open and Get Messages 3. Watch as the unread message count increments when the messages is moved there, but not decrement when the message is marked as read. Actual Results: Folder falsely shows unread messages Expected Results: Mozilla should have shown the correct number of unread messages, in this case, none.

W2K and Mozilla Build ID 2002101612 When a new message is filtered into a folder that is open, the user account and the open folder both get new-mail flags, but the message shows only as unread, not as new. This is confusing where there are other unread messages, and you can't be sure whether the message is new or simply unread. This does not happen when new mail is delivered to "Inbox" or when mail is filtered inito a folder that is not open.

More clarification on why it is confusing and somewhat important: I usually have folders sorted by date and sometimes I get email from someone whose computer clock is broken and it has a date like 1969 or 1980, or even a couple of days back. So when I know a folder has new mail, but there is no flag, I don't know if I'm missing something new and important somewhere in the folder.

Adam Kennedy, JMoorman: Is this bug still an issue in current builds? (1.3 Final, 1.4a or a 1.4b nightly) This looks to be a (better-reported) duplicate of Bug 167619; and Bug 201917 has a similar report except that, when the folder name is bolded, the new-message count is not displayed. All these bugs seem to be related to Bug 107206.

Mozilla PC Build: 2003042112 Connecting to IMAP server. Confirm my problem still exists. Repeated test. Create filter to move "job" message to remote IMAP filter "Jobs" and mark as read. Mail came in, was detected, was moved to "Jobs" folder, which was bolded, and the unread counter incremented to 1. Opened the "Jobs" folder. It contains the message, successfully moved, and successfully marked as read. When opening the folder, the folder name un-bolds , and the "(1)" style counter dissapears. Note that opening the folder does not select the moved message, so the action of opening the folder doesn't "read" the message and trigger the reduction that way. I wouldn't be so sure this is related to the "new messages" bug 107206. The problem appears to be ( at least without reading code ) that the counter for the folder is incremented ( without actually checking the remote server ) when an "unread" message is moved into it, but that "autoreading" the message, while in the remote IMAP folder, doesn't decrement the counter properly. Interestingly, changing the filter to move the message to a local folder, the message isn't marked as read at all, it just sits there "unread", but that's probably another bug... Indeed Comment #1 might not really applicable to this. I think this is probably a duplicate of Bug #167619 after all... Don't know how I missed it when I was filing it.

IMAP, eh? JMoorman, are you also using IMAP? Question for both: what theme, if any, do you have installed?

I have not noticed the problem lately, but I'm not sure it's gone. I'm using only POP, not IMAP. I don't think I had any theme applied; the View|Apply Theme menu shows Classic and Modern, but neither of them was checked. (Now that I've checked Classic (to see the behavior of checkmarks), I don't seem to be able to uncheck it.)

Theme in my case is Modern.

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

OS => all because the dupe was reported under Linux. Note to fixers, there is good descriptive data in the dupe. Tweaking description; was: New message counts in folder window not updated when 'Mark as Read' in filter On closer reading of comment #1, I agree with Adam that JMoorman's bug is a separate issue. Because of that, both the original report here and the report in the dupe are IMAP-related; I haven't been able to duplicate it with my POP accounts (for either the account-folder case or the local-folder case), with 1.3 Final or 1.4b (0426). (See my notes at the closely related Bug 201917.)

I'm not sure whether Additional Comment #9 is referring to Comment #1 when M.C. says, "I haven't been able to duplicate it with my POP accounts". Even if a different bug, the problem in #1 still exists in 1.3 (20030312) and W2KSP3. Should I report it elswhere?

Sorry, JMoorman, that was a little confusing. I meant I haven't been able to reproduce the original problem, which was duplicated by 167619. I have reproduced the symptom in Comment 1, with 1.4b (the only version I've tested with so far). I'm not 100% sure that it's actually a bug, altho your reasoning in comment 2 seems reasonable. I don't think there is already a bug for your problem. The title of Bug 107206 seems to encompass what you're talking about, but the specifics discussed there do not. Open it as a new bug and I'll confirm it.

Recent fixes in the notification area (for bug 186573 and bug 161999) *may* have corrected this issue; I think builds from 1.4b-0513 onwards would show this. Adam Kennedy, James McCaw, could you check this?

Mozilla 1.4b 2003050714: Problem still exists ( at least with my IMAP setup )

Interestingly, it seems to affect News servers as well. i.e. When a news filter has a "ignore thread" type filter, it marks anything in that thread as read ( or so it appears to me ). The same thing happens. The "unread message" count on a newgroup doesn't decrement when the news message is marked as read in the filter. A wrong count of unread messages is set for the newsgroup, and the unread count corrects itself when you click on the newsgroup. Thought I'd just tag it to this bug, as it seems to indicate that the problem is possibly in the filter code in general, rather than just the IMAP related code.

Adam, I was quite intrigued by your comment 14, as I do very occasionally see newsgroups shown with an unread count but no unread messages visible in the thread pane, and I do have one or two filters that Ignore Thread. However, I've tested your hypothesis and it hasn't panned out -- in cases where I know a new thread has arrived matching the rule, it gets ignored and the unread count has continued to display as expected. I've seen this for a new thread with a number of responses and another with just the original post. I also tried using filters to mark individual messages read, and those worked as expected as well.

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

Firebird 0.1 The System Tray Icon is also triggered for new "marked as read" emails

WinXP, Mozilla 1.5 Unlike comment #1, I have found that it doesn't matter whether the folder that mail is being filtered to is open or not at the time of the messages' arrival. I have also found that on some instances opening the destination folder reveals the filtered messages still marked as unread and this is not self-corrected. I have not been able to consistently reproduce this. FWIW, I am using a Courier IMAP server using Maildirs and the filtered messages are correctly appearing in the destination folder's 'cur' directory as would be expected.

Returning to this bug after a while: A quite plausible reasoning behind this bug is in bug 167619 comment 6 (by Adam Kennedy). Ben Holt, are you also using IMAP? Adam, and James McCaw -- is this bug still occurring for you? James McCaw mentioned in bug 167619 that part of his problem was receiving notification for messages marked as read. This is a separate issue: bug 206050; Dave Evans, take note. Jesse Moorman's symptom (comment 1) has been partially addressed by fixes for bug 227657 and bug 192039; these fixes are in current 1.7a builds. (Don't download a 1.7a build today, tho -- see bug 233014.) Now, a message Marked Read and Moved (or, for that matter, not moved) will lose its New flag, regardless of whether the destination folder is being viewed or not. The destination folder still gets a New flag -- this is bug 230805. I don't know if any of these issues affect this bug. Bug 201917, which I identified last year as being very close to this one, turned out to be a problem specific to the Classic theme. See bug 201917 comment 14 for the detailed description of that. I don't believe that is related to this issue, any more.

Yes, I am using IMAP. (Moz 1.6 on Linux/WinXP Pro) I have found that it behaves slightly differently depending on whether you are viewing the destination folder when the email arrives or not. If you are viewing the destination folder the folder name is bolded but the unread message count is not shown. If you are NOT viewing the destination folder the folder name is bolded and the unread message count is shown.

Hi, I am still seeing the same behaviour that I originally reported...Unfortunately, I way too busy ATM to check into it, to see if anything subtle has changed, but the general behaviour of notifying me and bolding folder, putting up green arrows when I mark a message as read is still occuring. Don't read too much into what I have just said, as I haven't thought about exactly what happens for over a year. Cheers, James

I'm still seeing the same issue using Mozilla Thunderbird 0.4 (20031205), I presume nothing major has changed since that point. My main observation is based on my "bounces from spam with the From: faked as my domain" folder, which I catch manually with a MozillaMail "Move + Mark as Read" filter seperate from all the spam actually targetted at me, which is caught by the normal spam detector. It still looks the same, and I suspect the same cause. I get a hundred mails a day in the above category. Personally, I think the filter engine could just keep track of the folders that have had any activity ( to OR from ) during the message processing, and then hit those again to get their message counts at the end of the whole filtering run. But since I don't have an in-depth knowledge of the IMAP protocol, I don't know how feasable that is. That concept would at least solve everything in one hit rather than gradually trying to somehow incrementally improve the guessing. (In reply to comment #19) > Returning to this bug after a while: > > A quite plausible reasoning behind this bug is in bug 167619 comment 6 > (by Adam Kennedy). > Ben Holt, are you also using IMAP? > Adam, and James McCaw -- is this bug still occurring for you?

Adam, do you mind trying out the latest 0.5 candidate builds: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2004-02-04-0.5/ and reporting back if you still see this issue?

As of the official 0.5 release, Thunderbird 0.5 (20040207), the problem still exists for me.

Hi bug list, It has been a long time since this bug was discussed (February), but I still see the behaviour I described in <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=167619#c5">Bug 167619, Comment 5</a>. I currently use Mozilla 1.7.2 (Debian unstable build 1.7.2-2) and Thunderbird 0.7.3 (Debian unstable build 0.7.3-1). Both display the behaviour. After a few years, I have become rather accustomed to the behaviour, but I still think it is a bug! Cheers, James

See bug 222112; a possible duplicate of bug 94215 is suggested there.

(In reply to comment #26) > See bug 222112; a possible duplicate of bug 94215 is suggested there. A very hesitant maybe... if there is a general problem of not sending enough commands to the IMAP server, it does make some sense that you could end up with the effects both here and in bug 94215. Suggest we leave as seperate for now. In fact, since bug 94215 seems to cover general "not notifying IMAP of changes" activity, rather than mark this as a duplicate of it, I'm going to mark it as a dependency instead. Once it is solved, we can revisit this and in the mean time keep the specific issue of folder message counts seperate.

see also Bug 230805

I am experiencing the same bug. See related Bug 275561 ... possible duplicate?

More possible duplicates: Bug 224823 Bug 233041 Bug 275561 Bug 277205 They all seem to describe symptoms of the same problem.

Are any of these fixed in today's TB 2.0 build? I made some changes in this area yesterday.

no response. with no original commenters present, opting for => incomplete