User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Messages apear as unread in the trash folder even if the message filter that put them there has 'mark as unread' marked. Reproducible: Always Steps to Reproduce: 1. Create any message filter that deletes the message and marks it as read. 2. Receive a message that is caught by the filter. 3. Actual Results: The message will apear in the trash box as unread. Expected Results: The message should apear in the trash box as read and the trash folder should not be in bold characters, nor should it have the number of unread messages in it increased (in the label).

Assaf Lavie: I cannot duplicate this problem with 1.3 Final. I tried using two different rule combos: - Delete message and Mark message unread - Move to [trash] and Mark message unread In both cases, the message was properly marked and relocated to the trash. By any chance do you have other rules running prior to this one, which may be deleting but not marking as read?

It seems you got me all wrong. I'm not trying to keep the message _unread_ in the trash but, on the contrary, I want it to appear as _read_ when it is deleted into the trash so it won't bug me. This bug is still occuring on my setup.

Sorry, I misposted: I did set it up as "mark as read", not "mark as unread", and that was the result I achieved. My question about additional rules still stands.

Ok. Now the problem that bothers me is not that the message that gets moved to the trash stays unread but that the label of the Trash folder becomes bold so as to indicate a new unread message. So even though the message _is_ deleted or moved and marked as read the label of the Trash folder turns to Bold which prompts me to look inside for new mail - which I hate to do. I apologize if I hadn't made that clear form the begining. But never the less this behavior is a bug.

I did understand that, but I neglected to include it in my report of my attempts to duplicate. For me, the Trash is *not* being bolded or updated with a number of unread messages -- in 1.3 Final, with the Orbit theme. However, I was able to get mail working again, kinda, in the 0426 build of 1.4b, which I am running without a theme. In this version of the program, I am seeing the Trash folder turn bold (but without a message count) when the message-as-read is filtered into it. (Note that a filter of 'Delete message' is exactly equivalent to 'Mark message as read + Move message to Trash'.) Marking as read and moving to a non-Trash folder has the same result, except that the folder name is also marked with the green arrow; apparently Trash never gets a green arrow. This is related to Bug 107206, but the specific candidate for duplication is Bug 167619. (See also Bug 46133.)

Assaf: is this for a POP or IMAP mail account? And, do you have a theme installed? (Preferences|Appearance|Themes)

Additional notes on confirmation of this bug: I duplicated the symptom using POP mail, 1.4b (0426), as described in comment 5. I noticed a slight difference if the mail arrives while viewing the folder to which the mail is moved: if the folder is Trash, it behaves the same whether the folder is viewed or unviewed (name bolds, no green arrow); but for non-Trash folders being viewed, the name is not bolded; it only gets the arrow. If a non-Trash folder is *not* being viewed, it bolds and gets the arrow. This is closely related to the behavior described in bug 179556.

mass re-assign.

Assaf Lavie, this bug appears to have been fixed in the 0507 build; could you try with 1.4b? Please mark this bug WorksForMe, if it does.

I was mistaken in my comment 9; probably I forgot to switch to Classic theme before testing. Confirming that this bug still exists in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

I'm also very annoyed by this bug, and I'm running a nightly build (Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5b) Gecko/20030908) I have a special folder called "SpamBox" where everything is caught that is 99.8% spam. But now my domain has been Hijacked by some other who's obviously a victim of a spam-virus that sends off spams with my domain forged in the spam mails, I want to delete all bounced messages and mark them as read. But moving them to trash AND marking them as read doesn't work. Marking them ONLY as read does work, but leaves the message in my inbox. I don't care about the green arrow on my mailbox (so I know that there is at least mailbox activity), as long as I am not specially alerted or the whole trash box is displayed in bold letters, because I will always spend my time looking what new spam or bounces have gotten in my mailbox.

Nina Cording, when you set up the filter to Mark Read and Delete (or, Mark Read and Move to Trash), these are the symptoms for this bug: Trash folder is bold; Trash folder does not include updated of message count; messages within Trash are not bold (read). Does that match your observation? Are you using the Classic theme? If so, try using another theme, Modern or a theme based on Modern like Orbit or Pinball. If not Classic, please state which theme you are using. Suppressing the new mail notification (system tray icon) for messages that are marked read is bug 206050 (and may be addressed by a patch under development for a different bug, see bug 189289 comment 64); suppressing the notification for messages filtered to Trash is bug 91498.

I just can't use any other theme than the classic theme. Since Version 1.5b, other themes don't work anymore. It's sad, because I really loved that pinball theme. Maybe I need an updated theme for 1.5b Maybe that's again a bug and I don't know the workaround

The built-in Modern theme should still be useable. Other themes, yes, we need to wait for updates from the authors of Pinball, Orbit, Skypilot, etc. I started thinking about why this bug appeared to be theme-dependent, and dug into the Modern and Classic jar files (in the Mozilla/chrome directory). I think I've found the critical difference between the two themes: in Classic.jar::skin/classic/messenger/folderPane.css are these lines: treechildren:-moz-tree-cell-text(folderNameCol, newMessages-true), treechildren:-moz-tree-cell-text(folderNameCol, specialFolder-Inbox, newMessages-true) { font-weight: bold; } There is no corresponding rule in Modern.jar's corresponding file. I rebuilt the JAR with a version of that file omitting those lines, and voilà, could no longer duplicate the bug. The rules that are used to bold the foldername in Modern are duplicate in Classic: treechildren:-moz-tree-cell-text(closed, subfoldersHaveUnreadMessages-true) { font-weight: bold; } treechildren:-moz-tree-cell-text(folderNameCol, isServer-true), treechildren:-moz-tree-cell-text(hasUnreadMessages-true) { font-weight: bold; } Note the difference between 'hasUnreadMessages-true' and 'newMessages-true'. I don't know why the newMessages-true rule is in place. It appears to be designed to bold the Inbox, and folders in general, for new-but-read messages. But, if this behavior is undesirable, you can work around it the same way I did; just be aware that this hack needs to be repeated after every reinstall.

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

i am getting this bug with firebird also. in addition i get the new mail notification in my system tray (win 2k). as stated this is v annoying as it makes the whole purpose for such a filter unattainable, as junk still get my attention. my vote goes here.

Still an issue under 0.7. This is the one thing that **** me off about this product. This issue occurs for around 30% of the mail i recieve as all the emails generated by me in our bug tracking system are automatically deleted and marked as read. several times a day thunderbird tells me i have new mail and i click the notification only to find it's in the trash. I'm sure it's not a very hard thing to do and judging by the number of similar bugs logged it's obviously in high demand. thanks for reading my rant ;) some related open bugs: Bug 107206 - dupe? Bug 220933 - similar Bug 202341 - similar Bug 211439 - related Bug 157115 - related

Note that the oddball symptoms in comment 7 no longer occur (in 1.7a builds). With the Classic theme, filtering a message by Deleting (into Trash) or Marking Read and Moving to any folder, will cause that folder to appear bold but without changing the displayed number of unread messages -- whether or not the destination folder is being viewed. (The inconsistency was cleared by the fix for bug 192039.) The bolding is a result of the style-rules detailed in comment 14, and appears when the folder itself has a New flag. Bug 230805 has been filed about the New flag being set on a folder that receives only marked-as-read (and therefore, Not New) messages. Once that bug is fixed, those style rules in the Classic theme won't make any difference. Paul Stanton, none of the bugs you mention pertain to this bug, which is a pretty minor display fluke and has nothing to do with notification; your primary complaint would, I think, be solved by fixing bug 206050.

I am using 1.7 under Windows 2000. I experience this bug with both the Classic and the Modern themes. I have a rule set up to delete the message and mark it as read, but when it arrives, it goes to the trash folder, which becomes bolded and shows the number of unread messages, and when I go to it, it has a green arrow (in the Modern theme) and is bolded. I am using IMAP. I have two IMAP accounts set up. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 If I edit the filter and set it to Move to folder Trash instead of delete, it accepts it, but when I go back to edit the filter, it shows the default (non-folder pulldown menu for my first account), and it does not move it to Trash. It also still fails if I write to filters, one, run first, to mark it read, and one, run afterwards, to delete it.

(In reply to comment #19 [Eric Ewanco]) > I am using 1.7 under Windows 2000. I experience this bug with both the > Classic and the Modern themes. Then your problem is NOT THIS BUG. > I have a rule set up to delete the message and mark it as read, but when > it arrives, it goes to the trash folder, which becomes bolded and > shows the number of unread messages, and when I go to it, it has a green > arrow (in the Modern theme) and is bolded. > > I am using IMAP. IMAP has several possible ways of handling "delete" -- you can see the options in the Account Properties, Server Settings page. The behavior you are seeing is a result of using the "Move to Trash" action (at least, that's what I see with my IMAP account on fastmail.com -- other IMAP servers may behave differently). I don't see a bug for this particular problem, altho there are quite a few Networking:IMAP bugs with 'delete' in the summary. Feel free to open a new bug for this problem. > It also still fails if I write [two] filters, one, run first, to mark it read, > and one, run afterwards, to delete it. The behavior is not completely identical, tho: with this configuration, you should see that when you select the Trash folder, the message does get marked as read immediately, and has no New flag (green arrow). But the folder does indeed bold and increment the Unread count until that point. > If I edit the filter and set it to Move to folder Trash instead of delete, it > accepts it, but when I go back to edit the filter, it shows the default > (non-folder pulldown menu for my first account), and it does not move it to > Trash. I don't see either of these symptoms; a filter with Move to <imapaccount>/Trash works as expected, and on re-editing displays as expected. If you can reproduce this, open a new (separate) bug for it. (Note that unless the filter also Marks As Read, you will get a notification when the message is Moved to Trash.)

Dear mcow, I apologize if I erroneously associated my symptoms with this bug. As a software development engineer who works with bug reports daily, I understand the importance of clearly identifying symptoms and carefully reporting bugs. So I have tried to be very careful in reporting this. I am sorry if I failed in that goal. It would be helpful to know specifically why you believe this is "NOT THIS BUG". I suspect you are keying in on the fact that the log indicates that it cannot be reproduced with the Modern theme. Surely you appreciate the fact that 1) "cannot be reproduced" is not equivalent to "fixed"; 2) ten months is plenty of time for a regression to occur? In other words, the fact that someone could not reproduce the bug in September 2003 using the Modern theme does not, in my mind, rule out the possibility that I am seeing this same bug. Have you tried to reproduce the bug in the *same build* I am using with both the Classic theme and the Modern theme? That might tell us useful information. In any case, if I am to file a new bug, because I do not clearly understand why my bug is different from this one, you will need to provide me with sufficient information to distinguish my new bug from this bug, so that it doesn't get marked as a duplicate, and I have another engineer yell at me. Thank you. Eric

We need some clarification on this bug. Assaf Lavie posted the bug. These are the symptoms he reported: Messages appear unread and bolded in trash folder; trash folder is in bold characters; trash folder has number of unread messages increased in the label. Nina Cording replied, reporting the same symptoms, except she did not *explicitly* say whether she saw the number of unread messages in the Trash folder increase. In Comment 12, Mike replied. He asked Nina if these are the symptoms she sees: Trash folder is bold; trash folder does NOT include updated message count; messages within trans are NOT bold (read). This contradicts the symptoms originally reported by Assaf on two points. Finally, Nina never confirmed these symptoms Mike summarized, and neither did Assaf. My symptoms are the symptoms reported by Assaf. They are not the symptoms Mike reported in Comment 12. Does this bug pertain to the symptoms reported by Assaf and Nina, or summarized by Mike? I don't care which, but for the sake of posterity, it should be stated unambiguously that the bug with these symptoms is NOT being tracked here, and that the bug with those symptoms ARE being tracked here. Thanks.

Mike has opted to bow out of this bug. I appreciate the time he has put into it. At this point I'd like to propose that we clarify that the bug being tracked has the symptoms reported by Assaf (who opened it): When messages match a filter configured for both Delete (or Move to Trash) and Mark as Read, and the Delete action is configured as Move to Trash, 1) Messages appear unread and bolded in Trash folder; 2) Trash folder is in bold characters; 3) Trash folder has number of unread messages increased in the label.

So I'm looking in nsImapMailFolder.cpp, in ApplyFilterHit, and there is a line, under the Delete case and if (deleteToTrash) if, that has the comment "Mark read in trash", but the code is commented out. Was this intended to be checked in, perhaps due to a conflicting bug, or was it accidental?

Apparently this line was commented out in Version 1.621 by bienvenu, "fix 232892 imap unread counts not correctly updated when moving messages from imap to imap, sr=mscott". But this fix was February 2004; as of April of 2003, when this bug was submitted, the line was uncommented. So there must be another cause of the bug, although I am curious if there is a story about this line that bienvenu could tell that might shed some light on the problem.

I believe that line was removed because we now automatically mark messages read when they're deleted, at the imap protocol level, i.e., we store the /SEEN flag with the /DELETED flag, in the source folder. But, that's just for the source folder, not the destination folder. And since we do the copy followed by the delete, the destination read status won't be affected either way. The way this should be working, if you have two filter actions, one to mark the message read, and one to delete the message, is that the mark read action runs first, and marks the message read in the source filter; then the delete/move to trash action runs, and copies the already marked read message to the trash. It's really up to imap to maintain the /SEEN flag when the message is copied. I'll give this a try and see what happens.

should be fixed by checkin to bug 243832