210148 - Want notification for newly-arriving mail even if other mail still 'new'

Status: RESOLVED FIXED

(MailNews Core :: Backend, enhancement)

Description

[Mike Cowperthwaite]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612

When new mail arrives, Mozilla generates an alert (sound or 'XP window'), and 
puts an icon on the tray, and marks the Mail icon in each Mozilla window 
component bar with a green arrow.  Collectively, these are "new mail 
notifications" (distinct from the green "new" arrows on accounts, folders and 
messages).  As soon as the user takes any action in the Mail/News window that 
indicates acknowledgement of the new mail situation, Mozilla clears the icon in 
the tray and the arrow in the component bar.

As long as *any* of the newly arrived messages are still marked New (for 
instance, click to the inbox of one account with new mail, but not another), 
Mozilla does not generate any further alerts for additional mail.  Also, if one 
inbox has been read (and so the icons are cleared/reset), additional mail will 
not re-show the tray icon or the component bar's arrow.

So I would like to see two changes.  First (perhaps an RFE): alerts should be 
repeatedly triggered as new mail arrives after a biff.  This might require a 
time limit (don't alert more often than every xx minutes) to keep from being 
annoying.

Second, the tray icon and component bar icon should be triggered after every 
biff that results in new mail, just in case they've already been cleared by 
looking at a folder.

Of course, these notifications would be suppressed for mail that goes to Trash, 
to Junk, or is marked read, once these enhancements are in place (bug 91498, bug 
189289, bug 206050).

Comment 1

[timeless]

I don't see this
2003120308 wXP
I connected to my inbox for the first time on a computer, so it downloaded all
~200k message headers. I didn't interact with mail. Mozilla's notification said
i had 5 new messages, normally it says i have ~200k new messages. To me, this
means that between the time when mozilla started to download the headers, 5 new
items came in, which it grabbed as soon as it finished getting the first batch,
and then it clobbered the original value w/ a report of the 5 new items.

iow i believe your bug has been replaced by another one. I'm looking for a bug
as i've described here, if you happen to find it, cc me :).

Comment 2

[Mike Cowperthwaite]

I just tried and I still see the bug as described, 1.6b-1120/Win2K.

1) If the tray-icon is being displayed, no further alerts are shown.

2) If the tray-icon has been cleared because one Inbox has been viewed, but 
another Inbox still has new mail and has been unviewed, no further alerts are 
shown and the tray-icon is not re-displayed.

Symptom 1 is actually a subset of symptom 2, I think.

Timeless, I did see a symptom like yours in the following situation: Sent 
several messages from account #1 to account #2; viewing Inbox #2.  Mail arrived, 
notification displayed, alert showed correct number of messages.  Switched to 
view Inbox #1, without selecting a message -- tray-icon disappeared, but 'new' 
green arrows continue to be displayed on the Inbox and the new message.  

Then immediately sent another message to account #1; when it arrived, 
notification occured again (I guess because Inbox has been viewed, the "new mail 
has arrived" status has been cleared, even tho the "these messages are new" and 
the "this folder has new messages" arrows are still present).  This notification 
only lists the latest-arriving message, despite several messages with 'new' 
arrows in the Inbox.

I don't necessarily consider this particular behavior to be a bug; but I'm not 
sure that's exactly what you've encountered, either.  I actually would be happy 
with the notifications/tooltips not even displaying a new-message count -- when 
it comes to notifications, I don't care how many, I just care whether.  
You might take a look at bug 138631.

Comment 3

[Mike Cowperthwaite]

Having been testing for bug 192039, bug 164226 and bug 219904, I think I can 
summarize this bug more concisely: so long as any Account is flagged with a 
green arrow, no new-mail notification occurs.

The tray icon will disappear as soon as any action is taken that clears the 
arrow from *an* account, but until *all* accounts have been cleared.

This is not exactly the same as the description in the original report, where I 
believed the problem depended on whether any *messages* are still marked new.


My comment 2 has an error: I said "Sent several messages from account #1 to 
account #2" but that was backwards: I sent the messages from account #2 to 
account #1.  Switching *from* the Inbox that has just received new mail clears 
the new flags from the Inbox and the messages, but not from the account -- and 
so no further notification takes place.

Comment 4

[Mike Cowperthwaite]

Changing to enhancement, per bug 145982 comment 4.

Comment 5

[Mike Cowperthwaite]

This is related to bug 138095.

In comment 3, I wrote:
> The tray icon will disappear as soon as any action is taken that clears the 
> arrow from *an* account, but until *all* accounts have been cleared.

That sentence should continue: ... there is no further notification (alerts).

Comment 6

[Mike Cowperthwaite]

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

Comment 7

[Thomas Gstoettenmayr]

(In reply to comment #0)
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612
> 
> When new mail arrives, Mozilla generates an alert (sound or 'XP window'), and 
> puts an icon on the tray, and marks the Mail icon in each Mozilla window 
> component bar with a green arrow.  Collectively, these are "new mail 
> notifications" (distinct from the green "new" arrows on accounts, folders and 
> messages).  As soon as the user takes any action in the Mail/News window that 
> indicates acknowledgement of the new mail situation, Mozilla clears the icon in 
> the tray and the arrow in the component bar.
> 
> As long as *any* of the newly arrived messages are still marked New (for 
> instance, click to the inbox of one account with new mail, but not another), 
> Mozilla does not generate any further alerts for additional mail.  Also, if one 
> inbox has been read (and so the icons are cleared/reset), additional mail will 
> not re-show the tray icon or the component bar's arrow.
> 
> So I would like to see two changes.  First (perhaps an RFE): alerts should be 
> repeatedly triggered as new mail arrives after a biff.  This might require a 
> time limit (don't alert more often than every xx minutes) to keep from being 
> annoying.
> 
> Second, the tray icon and component bar icon should be triggered after every 
> biff that results in new mail, just in case they've already been cleared by 
> looking at a folder.
> 
> Of course, these notifications would be suppressed for mail that goes to Trash, 
> to Junk, or is marked read, once these enhancements are in place (bug 91498, bug 
> 189289, bug 206050).



it would be nice to have a switch that allows notification in tray to turn
on/off for junk. i need this for automated bulletin msgs (that i mark as junk,
but i still would like to now if there is new mail).

thanks in advance

Comment 8

[Martin Wildam]

Related TB bug 378150.

Comment 10

[Casper Gripenberg]

Shouldn't this be marked as "bug" and not as "enhancement"? One of the purposes of a mail agent is to notify of incoming mails. Since the functionality for notification seems to be in TB already, why has this not been fixed in 5 years? Is it that hard to fix (excuse my ignorace if it is). 

Comment 11

[Casper Gripenberg]

See further analysis of this problem on bug 138095.

Comment 12

[Mike Cowperthwaite]

The reason this is an enhancement is, the program is behaving as intended here 
-- follow the link from comment 4.  In fact, I've come around to not really wanting this feature.  :)   But I'd be happy to see it implemented, so long as the old behavior could be preserved via a pref.

Here's the reasoning: Suppose some new mail comes in, but you don't do anything to address it, leaving Biff=Y.  This could be because (a) you're busy working on something else that's so engrossing you don't want to be pulled away from it to look at email, or (b) you're not at your computer, in which case you didn't hear the sound / see the alert.

If more mail comes in -- particularly, if a *lot* of email comes in, over the next several hours or days -- your computer could sit there beeping repeatedly, causing you, or the co-worker in the next cube, to be annoyed by the frequent interruption.  But if doesn't beep any more, it should be OK: you've either already been notified or, when you return to your computer, you see the tray icon and thus know to open up mail.

Now, there is a subcase of (a) which is: you're at the computer, and the alert pops up, and you see it's from someone you don't want to deal with, so you ignore it; but then in the next cycle comes the email with the job offer that you really want.  In that case, yes, another notification would be desirable.

It's worth remembering that, when the notification system was first implemented, the visible alert only displayed the new-message count.  (Still true in Seamonkey?  bug 200157)  Therefore, you'd never know who the mail was from, so that subcase didn't apply, originally.

Bug 138631, especially my cmt 10 and the following, are worth reading.

Comment 13

[Casper Gripenberg]

Thanks Mike. Agree with you an all accounts. Best case scenario would be
to have it configurable of course. I'm in the "waiting for job
offer" type of camp, but I see the merit in keeping your co-workers
happy though :) 

The code, unfortunately, is..well..don't want to put it too bluntly,
so I'll just say "not nice". 

Keeping count of how many new messages you've had since
your last check will involve some sort of local house-keeping, as this
number does not seem to be available for query anywhere. All you can
get is the count of new messages since the latest POP/IMAP poll, or the 
total count of unread messages. So to fix this will require some sort
of persitent storage (per e-mail account), in 
nsMessengerWinIntegration.cpp, to keep a tally of all the biff events 
accumulated since the tray icon was put up.

Then we have the pop up portion, which might just require some heavy
duty code path / race condition / boolean state variable analysis
until you "get the code", so that you can actually put up the pieces
in the right order. I think the code for it is there..just the state
variables and callbacks make it hard to see where the snag is.

Suddenly I just like the current behaviour so much more than
previously. Very strange ;-/

Comment 15

[Stéphane Ascoët]

I found unbearable that this bug still exists. Often, the bell doesn't ring at all, so we never get noticed of new mail. Mozilla developers should urgently work on this instead of adding continuously new features(often to please new users, but making regressions for advanced users, like the "http://" hidden now in Firefox). So I'm forced to leave Kmail running in background to have notifications, and then I read messages in Thunderbird!

Comment 17

[Matt Isaacson]

It's not encouraging to see that my bug #1059598, having finally come up on someone's radar over a year after it was submitted, has now promptly been identified by someone else as a duplicate of this bug, which has languished in the database for more than twelve years, apparently because of having been recategorized from a bug to a requested enhancement (according to reasoning I am not able to follow) not long after it was first submitted.

I would like to respectfully submit that the decision to relabel this bug as an enhancement request was questionable and request that it be reconsidered, if for no other reason than this: the behavior exhibited by the Windows version of Thunderbird does not extend to the Macintosh version: on the Mac, audible and visual alerts are ALWAYS issued when new emails are received – behavior which seems entirely logical to me. I think this simple fact effectively undermines the notion that the Windows version is behaving as intended. Or were the two versions intended to behave differently with regard to this feature? I'd find that hard to believe – the two versions seem to be nearly identical in almost every detail.

Comment 18

[Magnus Melin [:mkmelin] (away, back June 30)]

I'm not sure which bug I wrote it in - it's a cluster of them - but I think the essence of how to keep track of what to notify about is this: keep track of the timestamp of the last (newest) message we notified about. For further notifications, ignore older than that.

Comment 19

[Thomas D. (:thomas8)]

If it's true (as this bug suggests) that we don't even trigger the notification every time new mail arrives (and it's not a settings issue) as long as other brand-new (never-touched, yellow star) messages are still around, we should be careful about "fixing" that. For high-frequency accounts, getting alerts every second might be extremely annoying, and reducing the "get messages" interval may not be feasible. For such scenarios, I believe we would need something like:

• Bug 443749 - Implement option to delay Biff notification to a given interval, fixed times, or idle to reduce disturbance e.g. while working

That said, I'm not sure if we're really skipping biffs (this bug 210148), and I'd think I've seen biffs in spite of new and never touched messages. We definitely have a problem about showing the right (newest) thing on the biff notification (bug 375717), which imho is the biggest annoyance.

Comment 20

[Ping Chen [:rnons] (away)]

Attachment: Bug 210148 - Fix new message notification on Windows. r=mkmelin

Previously when biff icon is visible, there is no notification for newly received messages.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e417f7ae0a0c
Fix new message notification on Windows. r=mkmelin

Comment 22

[Ping Chen [:rnons] (away)]

Comment on attachment 9204747 [details]
Bug 210148 - Fix new message notification on Windows. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): Implemented like this years ago.
User impact if declined: When there are NEW mails in any folder, notification window never shows up again on receiving a new mail
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): Impacts windows notification only.

Comment 24

[Wayne Mery (:wsmwk)]

Comment on attachment 9204747 [details]
Bug 210148 - Fix new message notification on Windows. r=mkmelin

[Triage Comment]
approved for beta

Did you file the follow up bug about system alerts?

Comment 25

[Ping Chen [:rnons] (away)]

(In reply to Wayne Mery (:wsmwk) from comment #24)

Did you file the follow up bug about system alerts?

Working on it in bug 715799. The three platforms will share the same code, to try using system alerts first, then fallback to TB customized alert window.

Comment 26

[Rob Lemley [:rjl]]

Thunderbird 87.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/00d81b65ff8b

Comment 28

[Ali Savas]

I can confirm that this bug has been fixed. The notifications now works as usual.

However, the sound for new emails still only plays once. If this is a new bug, I'm happy to open a new one for it.

Comment 29

[Wayne Mery (:wsmwk)]

Comment on attachment 9204747 [details]
Bug 210148 - Fix new message notification on Windows. r=mkmelin

[Triage Comment]
Approved for esr78

This would be a good one to test

Comment 30

[Rob Lemley [:rjl]]

Thunderbird 78.8.1:
https://hg.mozilla.org/releases/comm-esr78/rev/319196c5e666

Comment 31

[Stéphane Ascoët]

"However, the sound for new emails still only plays once. If this is a new bug, I'm happy to open a new one for it."

It was the initial aim of this bug!

Comment 32

[WaltS48 [:walts48]]

(In reply to Stéphane Ascoët from comment #31)

"However, the sound for new emails still only plays once. If this is a new bug, I'm happy to open a new one for it."

It was the initial aim of this bug!

I see the notification, but don't hear the sound when receiving a second message using the 78.8.1 release candidate on Windows 10.

Sent 2 messages one after the other to my Gmail IMAP account with "Allow immediate server notifications" enabled, from my Comcast POP3 account.
Received the sound notification for the first message, but not the second message but did see the notification popup.

Sent a reply to my Comcast account from one of those messages, received the message, got the notification popup, but no sound alert.

The envelope in the "Show hidden icons" of the Windows task bar shows 1 new Gmail and 1 new Comcast message.

Comment 33

[Ali Savas]

Same here.

Comment 34

[Ping Chen [:rnons] (away)]

Sorry, I didn't notice the sound problem. The notification code is being rewritten in bug 715799, I will try to fix it there.

Comment 35

[Klaus B.]

Something is wrong here: Ever since I updated to 78.8.1 I see a new message notification that spans the height of the entire screen. Basically it notifies lots of feed articles which I don't care about. Wasn't the number of notified messages limited to 6 or 8?

I suggest your remove this from the next ESR until it's fixed for real. Like this, the notifications are really overwhelming.

Comment 36

[Wayne Mery (:wsmwk)]

(In reply to Klaus B. from comment #35)

...
I suggest your remove this from the next ESR until it's fixed for real. Like this, the notifications are really overwhelming.

Or just move on and fix it. Where is your bug report?

Comment 37

[Klaus B.]

Well, a backout is quicker than filing a new bug and running it through Daily and beta. The issue here could just be that you "forgot" to backport bug 375717 and now you get never before seen amounts of "not new" (just unread) e-mail notified. I've NI'ed the developer and reviewer, surely they can take the appropriate steps, including filing a new bug if necessary with in-depth insight into the matter. I'll attach a screenshot when it happens again.

Comment 38

[Wayne Mery (:wsmwk)]

No one forgot to take bug 375717. As can be seen by the comment history there it was a conscious decision. The ramifications of that decision didn't include what you describe in comment 35.

I don't see us doing a special build to back this out. We just land the patch from bug 375717 for 78.9.0, as was planned.

Comment 39

[Klaus B.]

Filed bug 1697882. I don't think it will be fixed by the uplift of bug 375717. The patch here exposed some unwanted behaviour and IMHO should be removed from ESR again in the next build.

Comment 40

[Ping Chen [:rnons] (away)]

Sent a patch to bug 1697882, I don't think it's regressed by this bug though.

Comment 41

[Klaus B.]

Looks like the feed notification has always been broken. That it shows so prominently now was regressed by this bug, I believe, before it just wouldn't have been shown at all.

Comment 42

[Magnus Melin [:mkmelin] (away, back June 30)]

I agree it probably makes most sense to back out this one from 78, since it's an ancient bug. Yes, it doesn't seem like it regressed the behavior per se, just exposed other bugs further. We can then focus on gettin all the behaviors right for 91.

Comment 43

[Wayne Mery (:wsmwk)]

OTOH, at 50% uptake of 78.8.1, the low level of reports in support (one so far) and bugzilla that the "regression" suggests extremely few users are affected and I would judge the overall change is positive. (I tested myself on windows and my alerts are less than 1/4 screen)

I think we should leave it in place for now and see how bug 375717 helps. Or try a 78 adjustment to feed notifications that doesn't involve UI exposed prefs.

Comment 44

[Klaus B.]

Bug 375717 won't help since the feed messages are new and would always be notified. That bug only stops notifications for old unread messages.

Comment 45

[Ping Chen [:rnons] (away)]

Maybe we should backout this from esr78, since people rely on the old behavior and bug 261841 can't be fixed soon.

Comment 46

[Wayne Mery (:wsmwk)]

(In reply to Ping Chen (:rnons) from comment #45)

Maybe we should backout this from esr78, since people rely on the old behavior and bug 261841 can't be fixed soon.

There are definitely reports other than this bug, but the numbers are underwhelming given ~7M users on 78.8.1 against a total of 6-7 reports (cited in bug 261841, though two unrelated as Klaus points out, plus one report in mozilla.support.thunderbird and maybe one in reddit). That said, it may be problematic if bug 261841 cannot be delivered in the v78 time frame. Up to you and the justdave to land the backout you decide that is best.

Comment 47

[Dave Miller [:justdave]]

So... back it out, and tie it to the completion of bug 261841 for re-uplifting it? Since Wayne left it up to us, I'll take the decision of the patch author. (NI me again when you have a decision)

I'm on a Mac and have the sound disabled on my TB notifications so I don't really have a personal investment in how this behaves...

Comment 48

[Ping Chen [:rnons] (away)]

Let's back out it and focus on v91 as Magnus said in comment 42. Thanks.

Comment 49

[Dave Miller [:justdave]]

Do we want it backed out of beta as well, or just ESR?

Comment 50

[Dave Miller [:justdave]]

Backed out for ESR 78.9.0:
https://hg.mozilla.org/releases/comm-esr78/rev/fe1944116f1b14f637a1604c7ab04ca9cd6f8151

Comment 51

[Klaus B.]

(In reply to Dave Miller [:justdave] ([e-mail]) from comment #49)

Do we want it backed out of beta as well, or just ESR?

The last TB 87 beta has been shipped, that is beta 3, backing it out there now wouldn't make any difference. It will be in TB 88 beta 1 again in less than a week.

Comment 52

[Ping Chen [:rnons] (away)]

I tested 86.0b3 on Windows a bit, notification for feeds never show up, I think the getNumNewMessages is broken for feed folders.

Comment 53

[Rob Lemley [:rjl]]

Comment on attachment 9204747 [details]
Bug 210148 - Fix new message notification on Windows. r=mkmelin

Unsetting flag since this was backed out.

Comment 54

[Wayne Mery (:wsmwk)]

let's also back this out in the next beta build (next week)

Comment 55

[Ping Chen [:rnons] (away)]

(In reply to Wayne Mery (:wsmwk) from comment #54)

let's also back this out in the next beta build (next week)

The trunk/beta is using a new JS implementation now, so this patch does not really exist in trunk/beta anymore.

If I had started directly with bug 715799, there won't be so much troubles. But I was new to the code, and was trying to get familiar with it by working on this first.

Comment 56

[Wayne Mery (:wsmwk)]

Thanks for clarifying