When I get new mail, the new mail notification (growl and dock badge) show the wrong number of messages and the wrong addresses. What seems to happen is that it looks in the first folder with unseen mail, but not in the inbox. This started to happen when I started using TB3.0b3. More details: Mail is delivered to inbox. Copies of the mail all delivered to archive folders (like archive/bugmail or archive/work). (all done on the server using filter rules) Mail is accessed over imap. Thunderbird sees the message come in to the inbox. It doesn't look in other folders. Only the inbox is 'blue'. The new mail notifications shows something like '157 new mails from bugzilla-deamon'. The count does not change as long as TB stays open. When I go into the archive folder, all messages are marked as seen. Now, when new mail comes in, the popup mentions a different address and a different count. This matches the next archive folder. When I go into all folder, to mark everything as seen, I no longer get any new mail notification. For all folders, except inbox, the check for 'check for new mail' is off. My conclusion: The notification looks in the first folder with unseen messages, but never looks in the inbox. What I want: Only look in the inbox, and not in any other folder (like previous TB versions did)

Michiel can you find the regression window ?

I noticed that if there are, at startup, unseen messages in the inbox, the new mail notification is correct. It seems that one folder is choosen at startup: the first one with unseen messages. From that point on, that folder is the only one the notification looks in.

Finding the regression window is hard, because I need to wait for mail to come in while I'm using the computer. And just testing from my own accounts is not enough. For a good test, there should be some bugmail involved (bugmail gets copied to a different folder then my own mail) So far, I tested some tb-3.0b3pre builds. 2009-05-01 is broken, while 2009-03-01 seems to work ok. But again, it takes some time to really be sure that a build works.

The behaviour can be explained as follows: When new mail comes in, nsMessengerOSXIntegration::GetFirstFolderWithNewMail [1] looks (as the name suggests) for the first folder with new mail. The order of folders seems to be alphabetical. At least, it is for me. Problem now is that 'archive/bugmail' comes before 'Inbox'. A little after startup, the archive folders are scanned for new mail (as shown by the spam that's being detected in those folders). This causes [1] to know there is new mail in the folders. The thing with my setup is that new mail comes in in multiple folders, so there are other folders with new mail. But I think it's not that weird actually. Lots of people have mail coming in in their 'Spam' folder. Luckily, 'Spam' is after 'Inbox'. But it might be that in some languages, it's the other way around. In that case, this bug affects more people, not just me. I'm not sure what a right fix here would be. I (not knowing too much about the mailnews backend) can think of the following: 1) force inbox before all other folders 2) use the same sorting the folder pane uses, instead of alphabetical 3) When new mail is detected (somewhere in imap code), pass the right folder. This removes the need to guess.

humph, does this ring a bell to you?

Actually in Windows Vista I have the same issue. I only get notified for new mail in the account which was active when TB was last closed. Hope this is not too confusing?

Though I ought to file it under a seprate bug.

From what I see, the following happens: 1) Biff notifications are originally detected (or received, i don't know) on a folder. Then, they get moved to the server [1] on purpose, bug 113366. 2) The notification code has to find the right folder, because it wants details of the message. 3) Finding the right folder fails on my setup One solution would be to send biff on the folder again, but I don't know what the implications of that are. It at least fixes the bug for me. bienvenu, do you have an opinion on this, since you wrote the patch for bug 113366? Attached a patch that's a proof-of-concept. It works for me. If we go this route, then I think that the notifications on other os-es also need a change. [1] http://mxr.mozilla.org/comm-central/source/mailnews/base/util/nsMsgDBFolder.cpp#4410

bienvenu, can you look at comment 8?

The trouble I see with this patch, and why I wrote it the way it is now, is that you'll end up with just "Inbox" all the time, and if you have 5 of them, it's meaningless. Using the root folder (e.g., account name) at least gives you some sense which of your many accounts is getting mail. Another possibility would be to combine the account + child folder names somehow, so you know that it's *this* Inbox.

humph is more up to speed on this than I am...

(In reply to comment #10) > The trouble I see with this patch, and why I wrote it the way it is now, is > that you'll end up with just "Inbox" all the time FillTooltipInfo already gets the account name from the folder, so that's taken care of. http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMessengerOSXIntegration.mm#347 The main question I have about the patch is wether the changes in nsMsgDBFolder.cpp are sound. Is it OK to emit notification on the folder instead of the account? How do other parts of the UI react to that?

This bug seems to explain what I've been seeing, but there doesn't appear to be much (or any) progress on it of late. One of the reasons I'm using growl is because of bug 534098, which prevents the bouncing icon feature from working, which is necessary to notice new mail when the dock is configured in auto-hide mode. It wasn't quite clear to me if ensuring that 'Inbox' was the alphabetically first folder that receives e-mail was sufficient, or if it's also necessary that it have unseen mail at startup.

related to Bug 536523? New mail notification by dock icon (red label with count of new email) shows only for one account, not for every account

Sorry, Growl support has been removed from the current versions. Mass bug change. Please reopen if you disagree.