After filters 'Move' and 'Mark Read' all mail, Notification flag is not cleared (goes stale)

RESOLVED EXPIRED

Status

SeaMonkey
MailNews: Message Display
RESOLVED EXPIRED
15 years ago
9 years ago

People

(Reporter: Ben Clewett, Assigned: Scott MacGregor)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
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.

Comment 1

15 years ago
Duplicate of Bug 46133?

Comment 2

15 years ago
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?

Comment 3

15 years ago
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.

Comment 4

15 years ago
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.
Summary: Filters to 'Mark Read', Notification flag goes stale. → After filters 'Move' and 'Mark Read' all mail, Notification flag is not cleared (goes stale)

Comment 5

15 years ago
Another related item: bug 192039.
(Reporter)

Comment 6

15 years ago
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

Comment 7

14 years ago
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.
Product: Browser → Seamonkey
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → EXPIRED

Updated

9 years ago
Component: MailNews: Notification → MailNews: Message Display
QA Contact: stephend → search
You need to log in before you can comment on or make changes to this bug.