138631 - Pop-up email notification (alert) indicates wrong number of new emails

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Dan Rosen]

Using Mozilla 1.0 RC1 on Windows XP, and IMAP over SSL, the "new mail" 
notification which pops up above the system tray indicates the wrong number of 
new emails.

This problem started this morning (I didn't experience it yesterday when I 
first installed RC1) when I got several emails which were filtered to 
subfolders. Since then, whenever I get one new email, it says I have four. I'd 
guess that this does have to do with filters: I make heavy use of them, 
including filtering spam directly to the Trash folder. Hope this helps.

Comment 1

[m_feedback+moz]

I experience the same problem using 1.0RC1 on Windows 2000. The new e-mail
notification icon stays in the system tray even though I have read all my new
mails. It also shows the number of new messages incorrectly, when they arrive. I
use filters as well.

Comment 2

[grylchan]

Reporters,
We need more information.
Can you give us the build Id number please?

Does this still happen with current builds?

These new/migrated proifles? I assume imap mail acnts?

When I use current commercial branch (2002043006)
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc2) Gecko/20020430

I have filters set up for various folders (I don't have nested folders).
And when I receive new mesgs that get 'filtered' to different folders
the pop up alert reflects the correct number of new mesgs.

Remember the pop up alert only shows the number of new mesgs that
have arrived at that instant biff goes off. If you have new mesgs,
but don't read them, and biff goes off again with more new mesgs arriving,
it will only show the number of new mesgs for that current biff session
& not take into account the new mesgs from previous session.



m_feedback+moz
your problems refers to these bugs:
  Bug 133130 -Mail notifier tray icon stay after reading incoming mail.
  >It also shows the number of new messages incorrectly, when they arrive. 
  I assume you are refering to the tooltip when you move mouse over the
  icon? The orginal bug is bug 123104. That has been fixed. But if you
  are talking about dynamically changing tooltip count where if you have
  new mesgs arrive, you don't do anything, biff goes off again, and more new
  mesgs arrive. So the count should be udpated its bug 138095.

Comment 3

[m_feedback+moz]

Been checking it now with Build 2002043010, Mozilla/5.0 (Windows; U; Windows NT
5.0; en-US; rv:1.0.0+) Gecko/20020430. Using a migrated profile, and working
with several IMAP accounts and filters (I used 'move to folder' as the filtering
option). One of the accounts has 'check for new messages every 1 minute' set,
the others - every 10 minutes.

Here's the test I did:
I receive 1 new message that gets filtered and marked deleted in the inbox.
Popup alert informs me about 1 new message. I read it in the inbox, but don't
compact the folder. I send myself a message, pop up alert: username has 2 new
messages (should be 1). I don't read the message (so there's one unread message
in my inbox now). I get 2 new mails that get filtered, pop-up alert: username
has 4 new messages (should be 2). I compact the inbox (still one unread
message). I get a new message that gets filtered, no sound or pop-up alert. I
read all the unread messages in the inbox and compact it, so my inbox is
'clean'. I get a mail that gets filtered, pop-up alert: username has 3 new
massages (should be 1).

The pop-up alert doesn't show up if the new mail notification icon is still in
the system tray, which according to Comment #2 is how it is supposed to be*.
However, as you can see, even if there is no icon in the tray anymore and my
inbox is clean the pop-up alert shows an incorrect number of new messages.

(* Here I am confused about the functionality of the system tray icon and the
pop-up alert. It seems logical to me that the icon should stay in the tray as
long as there are new unread messages in the inbox, while the pop-up should
appear only at arrival of new messages to your inbox and inform about how many
have arrived at that instant. This way the pop-up alert takes over the
functionality of the new mail notification icon from Netscape 4. Thus the pop-up
alert should appear in spite of the fact that the icon informing about the new
unread messages is still in the system. Please, tell me if my logic is flawed here.)

Comment 4

[grylchan]

Ok trying to clear up confusion & address M-feedback's comments:

In comment 2, I said:
>Remember the pop up alert only shows the number of new mesgs that
>have arrived at that instant biff goes off.

It is instead supposed to show total new mesgs for that particular
mail account. At least that's what we thought.

I was right/wrong in the behavior of how 'number of new
mesgs in alert window' is updated. It's supposed to count the
total number of new mesgs and not the number of new mesgs that
arrive per biff session. 

But it doesn't do this but if you add filters then it DOES behave
like this.

Test case 1
 use imap inbox
 doesn't matter what deletion mode you use
 Don't click on any of the new mesgs.
 make sure there is no notification icon in system tray
 (get rid of it by doing get mesg or clicking on another folder)

-send 2 mesgs to inbox
 alert shows 2
-send 3 mesgs to inbox
 alert shows 3 (not 5)

 **so the alert is showing number of new mesgs per biff session and
   not total number of new mesgs
 **
-send 1 mesg to filtered folder
 alerts shows 1 (not 6)
-send 2 megs to other filtered folder
 alert shows 3 (not 7)

 **in this case, alert is counting total number of new mesgs
   for the filtered folders only. It's ignoring new mesgs
   in the inbox and NOT showing number of new mesgs that
   arrive per biff session
 **

test case2
-send 1 mesg to inbox and 1 mesg each to 2 filtered folders
 alert shows 3
 **this case alert is working with inbox/filtered folders
 **
-send 1 mesg to inbox
 alert shows 3 not 4
 **count reflects filtered new mesg totals + new mesg for that
   biff session in the inbox
 **



So in short we have 2 different behaviors for mail and non-filtered
mail.
   -filtered mail : alert shows total new mesgs in any filtered folder
   -non-filtered mail: alert shows total new mesgs for that particular
                       biff session

So m_feedback when you do your test, that is why you see the results
you do.

Not sure how you want to handle this Scott? I can update summary
line when we decide.

I don't think deletion model (mark as deleted) has an effect on
mail alert window if using filters.

Tested with commercial branch 2002050506 on NT 4.0
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc2) Gecko/20020505

Comment 5

[grylchan]

also see david's/scott's comments on filters/new mesgs as
it relates to tooltip on notification icon as
it's basically same situation as alerts. But with
tooltip we don't dynamically update it (bug 138095).

http://bugzilla.mozilla.org/show_bug.cgi?id=123104#c26
http://bugzilla.mozilla.org/show_bug.cgi?id=123104#c29
http://bugzilla.mozilla.org/show_bug.cgi?id=123104#c31
http://bugzilla.mozilla.org/show_bug.cgi?id=123104#c33

I'm not sure what the proper way to handle this is.

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

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

Comment 7

[Andrew Hallam]

Mozilla 1.5, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.5) Gecko/20031007

I'm getting similar behaviour, except that none of the messages are being
affected by filters *and* I suspect that the when the popup says I have recieved
2 new message one of them is getting deleted. I was watching the screen last
night when a new message alert occured and I saw two new messages appear, but
one disappeared. However, I saw who it was from and contacted them and they did
send me a message.

The account in question is IMAP. I have 4 IMPA and one POP acount configured.

Comment 8

[theBrave]

Yes, encountered the same problem.
But I'm a basic user, no filtering. So the popup (& the tray icon) report the 
number of new messages SINCE the last check.

As I have an permanent connexion & Thunderbird check every 10 minutes, it 
almost report 1 message everytime.

Bug found on 0.3 & 0.4, Windows XP & 2000.

Comment 9

[Hamish Moffatt]

I'm seeing this with messages moved by filters. I'm having the filters move
certain messages from my IMAP inbox to a local folder. 

If I receive just one message in an IMAP check, and it goes straight to the
local folder, the new mail notification pops up to tell me that I have 0 new
messages :( Then the icon stays until I switch to another folder (not the inbox)
and back to the inbox.

I saw this often in Thunderbird 0.4 and now in the 20040207 build also.

Comment 10

[Mike Cowperthwaite]

I'm not sure whether comment 4 did in fact "clear up confusion."  Dan Rosen 
unfortunately has never responded here since his first report, and I think this 
bug has been hijacked a little.  Given when this bug was filed, I suspect Dan's 
problem was the result of the fix for bug 123104.  Anyway:

Per comment 4:
> alert window is ... supposed to count the total number of new mesgs
> and not the number of new mesgs that arrive per biff session.
> [...]
> the alert is showing number of new mesgs per biff session and
> not total number of new mesgs

This symptom is this bug, I think, based on the summary and comment 4, 7, & 8.  
There are other problems with filtered IMAP accounts, and these are different 
bugs; in particular, bug 228168 is about the problem in comment 9.

However, what exactly is expected is a little hard to be sure about: certainly 
the count should include the total number of 'new' messages in the Inbox and all 
folders of the account.  But should it include those messages that have been 
filtered to another account?  If so, for just the current biff, or for all 
previous biffs?  Note that messages filtered to another account *are* tracked 
for certain purposes already: see bug 116181 / bug 222068, and bug 202783.

Currently (1.8, I think since 1.4 if not earlier) ONE alert is shown at a time, 
for a single "biffable unit" (meaning, an account or an individual IMAP folder). 
 When multiple "units" are being checked, the alert is only for the first unit 
with new mail to complete biff (bug 145982).  Until all accounts with new 
messages from previous checks have had their 'new' status cleared, no new alerts 
will be shown, even if the tray icon has been cleared (bug 210148).

The alert always shows the number of messages received in the last biff, either 
for the entire account -- for both POP and (if no filtering or intra-account 
client-side filtering) for IMAP -- or for the IMAP folder (in the case of 
server-side filtering).  Extra-account client-side filtering, as noted above, is 
bug 228168.

(POP filters moving to IMAP is apparently a problem: bug 180094 and numerous 
others.  In my testing, the filter simply fails to operate and the mail remains 
in the Inbox.)

It's important to remember that not all unread mails are new!  Also, the 'new' 
flag is a little tentative -- it's cleared (at least in the Inbox) if the user 
does an explicit Get New Messages for the account, it's cleared if the user 
selects a different folder than the one containing the new messages.  Each 
folder containing a 'new' message is itself marked 'new'.

Comment 11

[Chris Cook]

My expectations are as follows:

(In reply to comment #10)
> Per comment 4:
> > alert window is ... supposed to count the total number of new mesgs
> > and not the number of new mesgs that arrive per biff session.
> > [...]
> > the alert is showing number of new mesgs per biff session and
> > not total number of new mesgs

I'm used to the fact that the notification shows a new message count for the
biff only.

> This symptom is this bug, I think, based on the summary and comment 4, 7, & 8.  
> There are other problems with filtered IMAP accounts, and these are different 
> bugs; in particular, bug 228168 is about the problem in comment 9.
> 
> However, what exactly is expected is a little hard to be sure about: certainly 
> the count should include the total number of 'new' messages in the Inbox and all 
> folders of the account.  But should it include those messages that have been 
> filtered to another account?  If so, for just the current biff, or for all 
> previous biffs?  Note that messages filtered to another account *are* tracked 
> for certain purposes already: see bug 116181 / bug 222068, and bug 202783.

I would expect that a new message count would be based on the number of new
messages in the "biff unit" AFTER they are marked as spam, deleted, marked as
read, or any other rule that would make them not new but ignoring the folder
they are in or have been moved to. Moved messages are still new even though they
have been moved outside of the IMAP folder.

Comment 12

[Mike Cowperthwaite]

Attachment: Screenshot of TB's manifestation of this bug

Using TB's slider alert with only the userid of the sending mail displayed, this is the alert I got when I clicked on the tray icon after returning to my system from an absence.

It took a while for me to get around to making the screenshot of this.  After I cleared this bug, the tray icon's tooltip read "WELL has 1 new message" -- I think because another new message had arrived while the alert was displayed.

Comment 13

[Mike Cowperthwaite]

Attachment: Second screenshot

This is the alert after clicking on the tray icon again, after seeing that 
"1 new message" tooltip.  Altho, after I cleared this alert and looked in the folder, there were six new messages.

The wrong value in the tooltip, as noted back in comment 2, is bug 138095, but I think that same value is used for this alert.

Comment 14

[Thomas D. (:thomas8)]

Attachment: Screenshot of this bug in TB 2 RC1 en-us

added screenshot showing that this bug is still there in TB 2's IMPROVED new mail notification alerts if custom filters do filter msgs straight into custom mail folders

Expected results:
msg count caption ("accountname has 2 new messages") should calculate the number of all msgs that actually arrived for that account (except spam?), including those filtered into custom mailfolders

Actual results:
msg count caption calculates only the no of emails that actually landed in the INBOX of the given account, excluding the no of new msgs that have been filtered into custom mail folders. However, the filtered msgs do appear in the preview list below the caption (so it shouldn't be such a big prob to count them correctly?)

Comment 15

[Thomas D. (:thomas8)]

With regard to my attachment screenshot (see comment #14), it is accidental that the first mail which landed in my inbox (and gets counted) happens to be gmx's daily spam report including the count of spams I got. the second mail (from gmx magazin) is the one which gets filtered away into a subfolder of that account on arrival, and, due to the bug, is not counted in the total no. of new msgs as displayed in the new mail alert's caption.

btw, I am using POP, not IMAP.

I was about to suggest renaming this bug to improve descriptive adequacy and retrievability into "New Mail Notification Alert shows wrong total number of new messages when messages are filtered into mail folders other than inbox", but I realized there are too many other issues around the msg count that are included in this bug as well, let alone all those other bugs around the msg count issue. It's quite confusing. Is there a meta bug for this, like "Bugs and RFEs concerning New Mail Notification Alert total message count"?

Comment 17

[Shy]

This bug still exists on 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b2pre Thunderbird/3.0.1

this is from 2002, what's it been like... 8 years? :)

added attachment

Comment 18

[Shy]

Attachment: screenshot of tb 3.0.1

Comment 19

[Rahul Kopikar]

Yeah! Its 2011 now and still no fix on it. Why is it taking so long. I dont think it is rocket science. Infact, I dont think building a rocket would take that long, right?

Comment 20

[Gili Tzabari]

It's now 2012. Ten years and counting :)

Comment 21

[Thomas D. (:thomas8)]

This "bug" is not actionable: In its current state, it cannot be fixed because there's a lot of confusion about the nature of the bug.

1) This bug is reported against SeaMonkey, not Thunderbird. I'm not sure if fixing it for SeaMonkey's MailNews Component will automatically fix it for TB, too.
Anyway, it means there'll be little or no attention for this in TB (and I'm not suggesting it deserves much attention...). I notice that many comments refer to TB. Perhaps we should change it the product of this bug to TB.

2) We don't have a detailed description verifying the current (or intended) behaviour in the current version of TB (TB10), considering complex combinations of POP vs. IMAP, msgs filtered into same account, other accounts, msgs marked spam, deleted or marked read by filter etc.
I think roughly the current (intended) behaviour is "count new msgs of most recent biff only", but "show a limited number of *any* new msgs for account, regardless if they belong to current biff or not". If that's true, then screenshots like attachment 423961 [details] don't prove there's anything wrong at all, especially when they come without explanation.

3) We don't have good detailed description of expected behaviour, and it's kinda hard to do without knowing 2). I suspect that it's more of a feature request than a bug, or 2) is somewhat confusing but not necessarily wrong.

(In reply to Rahul Kopikar from comment #19)
> Yeah! Its 2011 now and still no fix on it. Why is it taking so long. I dont
> think it is rocket science. Infact, I dont think building a rocket would
> take that long, right?

1st, this is free open source software, so according to the rules, no obligations, and whining usually won't help unless you contribute something to move the bug forward.

2nd, it all depends on how many dollars and people you have available for building the rocket. For TB, not enough dollars and not enough people; plus, their agenda for fixing bugs is not always transparent. So yes, things can take longer than expected.

3rd, this bug has been classified as "minor", and rightly so. There are thousands of bugs and RFEs that hurt more than this one, so if there's any developer time to spare, they'll fix bugs with a higher priority. And we've certainly seen worse bugs surving as long or longer than this one.

(And ftr, I'm a volunteer and personally, this doesn't bother me much).

Comment 22

[fedux]

Attachment: New mail notification

This notification is after receiving 1 new mail. Using IMAP. Thunderbird 14 on Arch Linux.