Open Bug 138631 Opened 20 years ago Updated 7 years ago
Pop-up email notification (alert) indicates wrong number of new emails
4.47 KB, image/png
4.55 KB, image/png
10.57 KB, image/gif
290.68 KB, image/jpeg
13.92 KB, image/jpeg
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.
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.
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.
Assignee: sspitzer → mscott
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.)
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
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.
*** Bug 143139 has been marked as a duplicate of this bug. ***
Component: Mail Window Front End → Mail Notification
Summary: Pop-up email notification indicates wrong number of new emails → Pop-up email notification (alert) indicates wrong number of new emails
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.
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.
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.
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'.
Assignee: mscott → sspitzer
OS: Windows XP → All
QA Contact: stephend
Hardware: PC → All
Whiteboard: [see comment 10]
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.
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.
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.
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?)
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"?
Component: MailNews: Notification → MailNews: Message Display
QA Contact: search
Assignee: mail → nobody
QA Contact: search → message-display
This bug still exists on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20100111 Lightning/1.0b2pre Thunderbird/3.0.1 this is from 2002, what's it been like... 8 years? :) added attachment
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?
It's now 2012. Ten years and counting :)
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).
This notification is after receiving 1 new mail. Using IMAP. Thunderbird 14 on Arch Linux.
You need to log in before you can comment on or make changes to this bug.