User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 When using the new filters to move email and mark it as read, I get a stale email notification flag. As I have no email showing unread, I have no way of finding and CTRL-SHIFT-C the folder, so no way of clearing the flag. Double clicking the flag also does not take me to the email. Therefore the flag remains set permenantly. Reproducible: Always Steps to Reproduce: 1. Set filter to move and mark as read email on popular mailing list. 2. Wait for email to come in. 3. Impossible to identify new email, therefore impossible to clear flag. Expected Results: I would expect either: - Not to use the notification flag for email filtered to 'Mark as read'. - Alow some way of clearing the flag, *whatever* the state of the email. - Double-click flag, go to next un-read email keeping flag from clearing.
Duplicate of Bug 46133?
Ben Clewett, I'm not sure if this was a duplicate or not. Bug 46133 appears to have been cleaned up as of 1.4b. I think also the behavior of the 'newness' (green) flag on Marked-Read messages, and also of the notification flag, has changed so that this problem is no longer a problem. I wasn't quite sure how to duplicate your particular issue, so would you please check this?
Problem still exists in 1.4b. 20030529 In fact just to slightly clarify the reported bug, when all received email has been marked as read and/or deleted using a mail filter the mail system incorrectly leaves the new mail flag icon in the bottom left hand corner of the navigator and mail browsers raised, and incorrectly leaves the new mail flag on the mail server raised, but correctly does lower the new mail flag next to the mail folder where the mail currently resides. Interestingly the 'new email' flag in the subject of the email indicates that the filtered piece of email has just arrived. (I feel that marking a message as read or deleting it should clear this flag, but that's probably not the bug, but might very well be related). I think that all four flags should be the same in this situation and lowered. It's an incredibly annoying bug since it means that spam mail still triggers a raised new-mail flag for spam, and spam is very prevalent. This completely nullifies the usefulness of the new mail flags, so it's not an inconsequential bug. Even deleting the mail in the filter doesn't help.
Ian, thanks. As I noted before, this is very close to bug 46133; however, I now believe Ben Clewett's primary concern is the Windows systray icon. (Ben, are you reading this?) That icon is now cleared on selecting *any* folder, within *any* account that has been flagged with new mail. In that sense, this bug has been fixed. I've tested this a bit more (1.4b-0527), and I see that 'mark as read' alone (bug 46133) does not flag the message or folder as new, but does mark the account and the component bar; bug 'mark as read' plus 'move to...' flags at all four levels. Both circumstances trigger the system alert (sound, systray icon, WinXP tray-popup). I would primarily like to entirely squelch the system alert if all incoming messages are marked as read; if new mail meets the criteria I've set to be marked as read, I don't want to be interrupted to know about the mail. However, the 'new mail' flags are still desirable, except perhaps for the one in the Mozilla Component bar; they are less intrusive, even if I'm browsing or reading news -- in this sense, I guess I'm disagreeing with you. My secondary request would be that all levels of notification except message flagging take place if the final destination is the Junk or Trash folder. If an incoming message gets put there, even if still marked Unread, I do not want notification to percolate up to the account level. It's currently suppressed for the folder level only because there are no special 'flagged' icons available for the special Junk and Trash folders. But, this all sounds like a different bug. This is a very close analog to bug 91498 (notification-on-filtered-to-trash); and the notification-on-spam issue is bug 189289.
Another related item: bug 192039.
Hi, Yes I am reading this. I keep getting a timeout posting to Bugzilla, hope this gets through. My concern was born from experience of using Eudora, which chooses whether to display it's flag bases on whether the user actually wants to me made aware of email. Not showing this as I have selected a filter to mark this message as 'read', or other action to generally not bother me from my tireless coding with useless spam, is very satisfying. IE, there is a strict relation between the showing of the flag, and having one or more email messages to which the user wants to read, and has not read. Broken (in Eudora) by selecting the flag, indicating the user has now begun to read unread email. There is no reason to show the flag at this time as it's obvious from the interface where unread email lie. Also with Eudora, clicking on the flag takes me directly to the email in question. And shutting down Eudora with the flag showing, kills the flag. All of which I belive would make Mozilla a more pleasent and intuitive system to use. Hope this is of use. Ben
A fix for bug 192039 may have improved this situation a bit: now mail that is Marked as Read no longer is tagged with a New flag, nor is the Inbox. However, if a the mail is filtered with Mark as Read *and* Move, the destination folder does get flagged as New -- bug 230805. However, all Marked-as-Read mail still triggers the New flag on the (original) account, the New Mail icon in the Component bar, and the notifications. Suppression of this is bug 206050.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.