206050 - The 'New mail' notification should ignore messages that are directly filtered to the status read.

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Kees Grinwis]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030404 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030404 Phoenix/0.5

I'm filtering various e-mails to a special directory and set their status to
read immediately when I've received them. (For example CVS commit logs)

Currently this triggers the new mail notification, which will tell me that I've
got new mail. However when I open Mozilla Mail I don't have new mail (the
received mail was already set to read), and the 'New mail' icon keeps in the
system tray.

The 'New Mail' icon won't disappear until I've opened the folder with the CVS
mail, which was filtered to be read immediately.



Reproducible: Always

Steps to Reproduce:
1.
2.
3.



Expected Results:  
The expected behaviour would be silence discarding of the CVS mail because I
filtered it to have the status read immediately.

No 'New message arrived popup' and no 'New messages' icon in the system tray.

Comment 1

[Kees Grinwis]

Sorry, forgot to mention that bug 18289 (No new mail notification (biff) when
junk mail arrives) seems to have a simular problem, but then with junk mail
instead of mail that is immediately filtered to the status 'read'.

Comment 2

[Mike Cowperthwaite]

Reporter presumably meant bug 189289.  See also bug 91498 -- same issue, except 
for the Trash rather than Junk folder.

This bug addresses a specific symptom that falls under bug 107206.

Kees Grinwis, I assume that in addition to the system-tray icon, you would also 
want to suppress the popup-alert (windows-only, like the tray icon), and the 
alert sound (all OS's).  There is also the matter of the "biff icon" (the green 
arrow appearing on the mail icon in the Mozilla component bar); and the green 
arrows that appear on the folders containing newly arrived messages and 
(ideally) the accounts containing such folders.

Incidentally, the build Id you show is a Firebird (Phoenix) build -- there is no 
mail client associated with that!  Which mail client are you talking about -- 
Thunderbird, or Mozilla Messenger?

Comment 3

[Kees Grinwis]

>This bug addresses a specific symptom that falls under bug 107206.

The symptom is more or less the same and all (related) bugs may have the same
solution.

>Kees Grinwis, I assume that in addition to the system-tray icon, you would
>also want to suppress the popup-alert (windows-only, like the tray icon),
>and the  alert sound (all OS's). 

I've already stated that there should be no 'new message arrived' popup, which
is indeed the pop-up alert that is shown at the right-bottom on the screen for a
few seconds

>There is also the matter of the "biff icon" (the green arrow appearing on
>the mail icon in the Mozilla component bar); and the green arrows that
>appear on the folders containing newly arrived messages and (ideally) the
>accounts containing such folders.

I didn't notice those yet, but those indications should be suppressed too.

ACTUALLY all notifications related to 'New Mail Arrived' should be suppressed
when all new mail is filtered to the status 'read' when its received. Only when
one or more messages with the status 'New' remain the 'New Mail' alerts should
be fired.

>Incidentally, the build Id you show is a Firebird (Phoenix) build -- there is 
>no mail client associated with that!  Which mail client are you talking about
> -- Thunderbird, or Mozilla Messenger?

I'm filing this bug at home, using Mozilla Firebird on MacOS X, however the bug
occurs at work were I'm using Mozilla Messenger (SeaMonkey) on WinXP. However it
might also occur on Mozilla Mail (Thunderbird) but I'm unable to check this now.

Comment 4

[Ere Maijala (slow)]

Seems to me this problem causes the mark as read filter do more harm than good. 

Comment 5

[Mike Cowperthwaite]

Note the recent comment in bug 189289 stating that the patch pending in that bug
also addresses the symptom in this one.

Comment 6

[David :Bienvenu]

taking

Comment 7

[Mike Cowperthwaite]

Part of the implementation of bug 189289's fix was that the incoming mail 
identified as Junk loses its New flag; perhaps this is necessary to prevent the 
notification.

NOTE: per Bug 227657, a message filtered with Mark as Read (but not moved) loses 
its New flag, as does the Inbox itself.  In this case, even without the green 
arrow on the message, Mozilla puts up the notification.


If it is necessary to clear the 'new' status to prevent notification, there seem 
to be two ways this could go: any message marked as Read in a filter loses its 
new flag (which includes filtering with Delete Message); or, a specific filter 
action could be added for "Clear 'New' Status" (or, "Suppress Notification") -- 
which is bug 11040.

If the first method is implemented: this probably should be a preference, not 
automatic like no-notify-on-Junk is.  I suspect, tho, that a preference is too 
coarse a technique for real use -- I can think of cases where someone might want 
notification (or, at least, want a green arrow) for *some* mail that's been 
marked Read, but not all.

Ideally, it would be best to suppress notification without losing the green 
arrow -- that is, on the message and folder; the green arrow on the account 
seems to be directly tied to notification (see bug 210148).

Comment 8

[Mike Cowperthwaite]

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

Comment 9

[Mike Cowperthwaite]

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

Comment 10

[S. Myles Prather]

I wish I could use all my votes on this one bug. It's really driving me nuts.
Our sys-admin has a bunch of scripts that sends out warnings all through the
day. They don't concern me at all, but I can't mark them as junk, so I just want
to filter them off to trash marked as read and never even know it happened. I
can't work for more than 15 minutes at a time without my biff popping up due to
one of these trash mails. I have to context-switch over to mail only to find my
trash folder in bold text and nothing in my inbox. Arggg. :(

Comment 11

[David :Bienvenu]

Attachment: fix for pop3 case

this patch fixes the problem for the pop3 case.  I'm not terribly happy with
the way it works (making the num new messages count go negative on the incoming
folder is a bit hacky) and I want to test it some more.  But it seems to do the
basic job. I'll work on the imap case next.

Comment 12

[David :Bienvenu]

Attachment: imap fix

Comment 13

[David :Bienvenu]

fixed on trunk. The one remaining problem is that imap messages deleted by
filters end up unread in the trash folder, so that if your Trash folder is under
your Inbox, it will look like you have new mail, and biff will fire. The fix for
this will have to involve marking the imap msg read before moving it to the
trash folder, or just pretending that we've marked it read (which is code I
removed - maybe I need to restore that code, even though it means the unread
count on the trash will be wrong...)

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Wouldn't it be better to let the biff-notification ignore new messages that are
in the trashcan, rather then to mess with the newmessages-count in the trashcan.

Sounds like it would be more consistent and logical UI. And it would the user to
see that there are messages in the trashcan that got automatically moved there
and let him/her go through them before emptying the trashcan

Comment 15

[David :Bienvenu]

ignoring the trash is the first solution that occurred to me, and the easiest
one as well, so I'm leaning towards it :-)

Comment 16

[Robert Accettura [:raccettura]]

I'd suggest possibly just make an option in the filter UI to not notify if the
filter triggers.

Some people such as myself use SpamAssassin, so we have a filter to move
suspected spam to the junk folder.  Obviously, I don't want it to fire for what
is filtered.

I think that might be a better solution in the long run.  That would be much
more flexible, as people can turn off notifications for things they don't want
in the long run.

I'm sure some would create a filter to turn off notification on mailing lists.
(if subject contains "forum reply:" then  "move-->forum mail" & "don't notify"),
or bugzilla mail.

That would cover everyone.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Robert: that sounds cool but it also sounds like a compleatly new request.

Comment 18

[Robert Accettura [:raccettura]]

(In reply to comment #17)
> Robert: that sounds cool but it also sounds like a compleatly new request.

Most likely is.  I discussed it once briefly with dbienvenu before.  Since it's
relevent to this conversation, I mentioned it here, just to see if there is any
opinion.  I'll file a new bug when I get a few free cycles later this evening.

IMHO it would solve a ton of these notification requests.  

Filters, by their nature are messy, and considered "advanced", so having an
extra option shouldn't be a big deal as far as cluttering the UI goes.  They are
intended for power users who want flexibility.  Not amatures who want a basic
mail client.

Comment 19

[David :Bienvenu]

I think there might already be an RFE open for that...

Comment 20

[Mike Cowperthwaite]

Suppress notification for messages in the trash: bug 91498
Provide filter action to suppress notification: bug 11040

Comment 21

[Robert Accettura [:raccettura]]

Thanks Mike.  I see I'm also cc'd on that one ;-)

Organization, organization, organization.  The key to success.

Comment 22

[paul stanton]

heres my expected behaviour. i'm pretty sure this is the same for most of you?
basically all events should be fired after the 'mark as read' filter has been
run. this would allow the event handlers to assertain whether they should
actually do anything.

1. if a filter markes mail as read:
  a) the new mail notification should not be fired
  b) the folder the new mail resides in should not be bold
  c) the new mail count on that folder should not be incremented
2. if a filter moves the mail to the trash
  a) the new mail notification should be fired
  b) the trash folder should be bold
  c) the new mail count on the trash folder should be incremented
3. if a filter markes as read and moves to trash
  a) the new mail notification should not be fired
  b) the trash folder the new mail resides in should not be bold
  c) the new mail count on the trash folder should not be incremented

Comment 23

[S. Myles Prather]

Yes, i agree 100%.

Comment 24

[Mike Cowperthwaite]

I agree with comment 22, but the comment about the behavior for deleted messages 
belongs in bug 91498.  Note that the count on the folder is not the number of 
new messages but the number of unread messages; there is a difference.

Note: if the filter action used is 'Delete Message', it typically marks the 
message read.  This may not be (or may no longer be) the case for IMAP; I'm not 
sure how to read David Bienvenus's comment 13.  If you want the message left 
unread, you should use the filter action Move to Trash instead.  (Compare to 
using the context menu to delete a message, which leaves it unread: bug 211439.)

Comment 25

[Robert Accettura [:raccettura]]

I would only add a rule about moving mail to the Junk folder.

Want it marked as unread still (So I can check later on that it's definately not
spam).  

Shouldn't notify as new mail, but stay new mail in the junk folder.

Comment 26

[David :Bienvenu]

re Junk folder, yes, that's the way it behaves now.

Re deleting/moving to the trash, now that we have multiple filter actions,
there's no need to mark deleted messages as read in the destination folder,
you're right. But, remember, for imap, there's a need to mark the deleted
message as read in the *source* folder (in imap, messages that are deleted are
still there...)

So if I understand correctly, everything should be working the way people want,
right?

Comment 27

[Robert Accettura [:raccettura]]

Well, I have SpamAsassin filtering my mail, with a custom filter rule.

That still notifies when it's moved to Junk.  But that (as said above) is
another bug.

From rereading this bug... yes, I believe everyone is either satisfied, or
covered by another bug at this time.

Comment 28

[Mike Cowperthwaite]

OK, I've tested this patch out, and I am satisfied.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040210

Tested a filter which checks for a particular sender (one of my other accounts).
  Filter action                Notification
  -------------                ------------
  (none)                          Yes
  Mark as Read                    No
  Move to Subfolder               Yes
  Move to Sub & Mark Read         No
  Move to Trash                   Yes
  Move to Trash & Mark Read       No
  Delete Message (marks read)     No
  Move to Local Folders           Yes
  Move to Local & Mark Read       No

Nice work, David!  Verifying.

Comment 29

[paul stanton]

for the dummies... what version will this be released in?

Comment 30

[Robert Accettura [:raccettura]]

(In reply to comment #29)
> for the dummies... what version will this be released in?

For sure 1.7b or nightlies.  I think it's in 1.7a, not sure if that branched yet.

Comment 31

[David :Bienvenu]

yes, it made 1.7a

Comment 32

[Hamish Moffatt]

(In reply to comment #31)
> yes, it made 1.7a

Has it made a Thunderbird build yet?

Comment 33

[Daniel de Wildt]

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

Comment 34

[Daniel de Wildt]

Bug 235012 is explicitly filled for thunderbird. In dependence on comment 32:
Are patches checked in to the tree automaticly in the next thunderbird release?

Comment 35

[David :Bienvenu]

yes, thunderbird and seamonkey share all this code.

Comment 36

[paul stanton]

thanks for the patch .. installed nightly build of thunderbird because i couldnt
wait for release and am now have some of my sanity back.