Mike Cowperthwaite Reporter
	Description • 21 years ago

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).

	timeless
	Comment 1 • 21 years ago

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 :).

	Mike Cowperthwaite Reporter
	Comment 2 • 21 years ago

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.

	Mike Cowperthwaite Reporter
	Comment 3 • 21 years ago

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.

	Mike Cowperthwaite Reporter
	Comment 4 • 21 years ago

Changing to enhancement, per bug 145982 comment 4.

	Mike Cowperthwaite Reporter
	Comment 5 • 20 years ago

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).

	Mike Cowperthwaite Reporter
	Comment 6 • 20 years ago

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

	Thomas Gstoettenmayr
	Comment 7 • 20 years ago

(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

	Martin Wildam
	Comment 8 • 17 years ago

Related TB bug 378150.

	Casper Gripenberg
	Comment 10 • 16 years ago

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). 

	Casper Gripenberg
	Comment 11 • 16 years ago

See further analysis of this problem on bug 138095.

	Mike Cowperthwaite Reporter
	Comment 12 • 16 years ago

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.

	Casper Gripenberg
	Comment 13 • 16 years ago

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 ;-/

	Stéphane Ascoët
	Comment 15 • 12 years ago

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!

	Matt Isaacson
	Comment 17 • 8 years ago

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.