User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.5) Gecko/20060705 SeaMonkey/1.0.3 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.5) Gecko/20060705 SeaMonkey/1.0.3 When new (POP3) mail arrives when one is in the browser and MailNews has been opened then closed, the new mail notification green arrow appears on the mail icon at the lower left and the alert sound plays. Relaunching a MailNews window by hitting CMD-2 or clicking the component bar mail icon causes MailNews to open with all notification arrows cleared. The green arrow on the brower mail icon will be cleared. No arrows will be set on the MailNews mail icon, the mail folder or or the mail inbox. I have multiple mailboxes and news servers configured. To conserve space in the folder frame I usually keep mail folders collapsed. When this problem occurs, I am obliged to hunt, expanding folders to try to figure out what account has received the new message. Reproducible: Always Steps to Reproduce: 1. Start Seamonkey 2. Open MailNews to get POP polling going 3. Close MailNews 4. While in browser, send a new e-mail from outside SeaMonkey 5. When the message arrives (green mail arrow), hit CMD-2 or click on the mail icon Actual Results: All new mail notifications will be clear. Expected Results: Minimally, the new mail notification arrows should remain on the appropriate mail folder and inbox until the triggering message is read (or whatever the normal behavior is.) One could argue that clearing the component bar notification arrows is a good thing, resetting it to trigger again on the next mail, even if one does not immediately read the current new mail. However, I think this is an unintended effect and one could argue that the component bar mail notification arrow should be simply the logical OR of any arrows present in any mail accounts. Does not happen if MailNews is open (even minimized.) Haven't tried this with a single account. (I have four.) G3-800 iBook OS X 10.4.7 Not a recent regression, this has been happening for a while.

Continuing to occur in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b2) Gecko/20060819 SeaMonkey/1.1a. Additionally, the new dock icon biff (bug 86553) has it's message count go away. in #seamonkey <ajschult> rbgray: I see the bug on linux (1.1a build)

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061019 SeaMonkey/1.1b The resolution of bug 64396 allows further observations. 1. start SM 2. open mailnews to get polling going 3. close at least mailnews 4. send an e-mail 5. see the message count in the dock icon as the message arrives. The component bar green arrow biffs in open windows will display. 6. open non-mailnews windows (browser, chatzilla), mail biffs will be visible in the component bars (thanks to the bug 64396 fix.) 7. re-launch mailnews Result: The dock count and component bar mail biffs in the other windows will clear and mailnews will come up with no biffs in the folder tree or component bar. (The folder tree biffs need to stay to enable the e-mail to be located.) Summary changed to reflect that it does not matter how mailnews is relaunched.

Still occurring in OS X 1.1 official release. ajschult reports it in Linux trunk. I am unable to reproduce this on a Windows XP system running the 1.1 release. Confirming and changing OS & Hardware to ALL.

Are your mail accounts set to check for new mail on startup? I suspect that's what's clearing the New flags. As implemented, New flags are intended to be highly ephemeral; if you (for instance) Get New Messages on an account, the flags disappear. If you click away from a folder containing New messages, the flags disappear. They certainly don't persist across restart. If it's not already clear, there is a subtle difference between the New flag on a message or folder, and one on an account. I haven't run steadily with the suite for a while, but as I recall the 'biff' in the component bar corresponds to the appearance of the tray icon, which is even more ephemeral. (Bug 116181 is about the failure of the New flag to clear from an account in situations when it should, and there are several other bugs open that basically are about the same issue except as related to the tray icon. This behavior generates far more complaints than that of New flags/arrows, biffs, and icons disappearing before the user wants them to.) I'm not completely clear what the "dock count" is on the Mac; on Windows, the tray icon shows a count of messages based on the number retrieved at the time the tray was displayed, but not subsequent new messages. I understand the WinXP has some additional hook for showing # of new messages in a standard location, but I'm not running that so I don't really know how that operates.

(In reply to comment #4) > Are your mail accounts set to check for new mail on startup? I suspect that's > what's clearing the New flags. Yes. By turning off check at startup, the New flags don't get cleared when the mail-news window is re-opened. > As implemented, New flags are intended to be highly ephemeral; if you (for > instance) Get New Messages on an account, the flags disappear. If you click > away from a folder containing New messages, the flags disappear. > They certainly don't persist across restart. But they should. They have to be persistent enough to allow the new mail to be located, otherwise, they are pretty much useless. If you have a large number of mail folders and have left some messages unread in them, you may not even be able to figure out what message just arrived. Seems to me that the New flags should only be cleared on a manual get messages, not on one which occurs as a function of opening the mailnews window. I see that there are a variety of bugs regarding new message notification. Bug 116181 is just as bad as this one, because if the New flags are stuck on, it again becomes difficult to figure out what message just arrived. I suspect it gets more complaints because it affects Windows users whereas this bug doesn't. Hopefully someone attempting to fix these notification problems will be aware of all the notification bugs and not attempt to fix them piecemeal. > I'm not completely clear what the "dock count" is on the Mac; Bug 322923 added a new message count to the SeaMonkey dock icon (when non-zero). Works like a charm.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008060701 SeaMonkey/2.0a1pre Retesting with a simple POP3 account in a relatively new profile, it seemed to work correctly. The new flags on the inbox and message were there when the mailnews window was re-opened. However, I then added a second POP3 account. When I sent to this second account, the new flags for this account were cleared when the window was opened. Sending to the first of the two accounts still had correct behavior, so the problem may be for accounts other than the first one. Of course, when one has multiple accounts, that's when one increasingly needs the flags. Server settings (both accounts): [x] check for new messages at startup [x] check for new messages every 2 min. (first account 1 min) [x] automatically download new messages

Maybe we could move the biff state check to MailTasksGetMessagesForAllServers? We could probably remove the mailnews window check as that's a shared function.

Looks like this also afflicts Thunderbird: Thunderbird/3.0a2pre (Macintosh; 2008070603) pretty much same setup as SM, two pop accounts, both checking at startup and every minute. Start TB to get polling going, then close the window and send mail to both accounts. See two messages arival reflected in the Mac dock icon. Click on the dock icon to re-open the window. Expected results: Accounts and inboxes in bold blue, with the NEW * set on the messages in the inbox folders, as would have happened if the window had been left open when the messages arrived. (In SM, I've seen the first account new mail flag cleared because it seems to get selected on window open, hence "seen". Close enough as long as the it is possible to re-open the window and figure out which of multiple accounts have the new message.) Actual results: No New decoration on account or inbox, only on the actual messages. (In testing a few weeks ago, I thought I got behavior closer to SM: first account had decoration on inbox, 2nd none.) Turning off Check at start on both and repeating, I get good behavior: on window re-open, the first account is selected hence "seen" and not highlighted. But its inbox, the second account and its inbox are New. There is enough variation in behavior (and decoration) that I'm not sure if this is should be marked core or not (perhaps the code has forked?) Should component be changed to mailnews: notification? Adding as a blocker to the biff tracking meta bug 36011. Changing the title from "relaunching MailNews clears green arrow mail biffs" to try to get terminology more correct/generic. :/ (In SeaMonkey with bug 71105 in play, the New indications also get lost if mail checking is started when the browser window opens. When the mail window is opened for the first time, the same problem occurs if Check at startup is selected.) Seems like the crux of this is that if mail.server.server#.login_at_startup pref(s?) are true, the mailnews window open code clears New flags when it shouldn't (or the flags are somehow prevented from being set when the mail arrives?) Anyone else out there (besides AJ) see all this?