509163 - SeaMonkey 2 beta dock icon (showing new emails) does not reset

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[Wade Reese]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090805 SeaMonkey/2.0b2pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090805 SeaMonkey/2.0b2pre

Seamonkey beta dock icon (showing total emails) does not reset unless you log out of Seamonky.  (This is the little green circle with the number of emails you have... that is over the SM dock icon).  Example:  If I have 10 emails, and read all ten, the SM dock icon will say 10 until I log out of SM.

Reproducible: Always

Steps to Reproduce:
1.Launch SM
2.get emails
3.read emails.  The dock email count does not reset until I close SM
Actual Results:  
The dock email count just keeps going up and up... until I shut SM down.

Expected Results:  
When I read an email the count in the dock should go down by 1

Comment 1

[Wade Reese]

Hi again,  I got an email back on this just now but it did not have a comment from an analyst.  This issue still exists in the newest SM build (and under Snow Leopard).

Comment 2

[Rich Gray (:rbgray)]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090903 SeaMonkey/2.0b2

Confirming - I've been seeing this in the 2.0 betas.  Certainly a regression from the 1.1 series where this has worked splendidly.  Due to problems importing my profile, I was quite late to the SM2 game, so I have no idea where this problem started.

Alas, I don't get the dock count problem consistently.  I've seen:
- the dock count be correct - it goes back to zero (gone) when I read messages.
- the count stick; new messages arrive, the count goes up, I read them, the count stays.  Only way to clear it is to restart SeaMonkey.
- the count stick but subsequent messages increase and decrease the count back to the stuck count.  Again, the only way to get back to zero is to restart SM.

I've not yet had time to figure out which steps do and don't reproduce the problem conditions.  Guess I should see if this happens in Thunderbird as well...

Comment 3

[Wade Reese]

Hi,

I am still seeing this problem as of today under the current build... fyi.

Hope that this gets sorted out without much effort.  

You are right, this capability worked just fine in version 1.x.

Regards,

Wade

Comment 4

[Rich Gray (:rbgray)]

OK, I think I understand this better and have steps to reproduce.

My server settings for the test account:

[ ] Check for new messages at startup
[x] Check for new messages every [ 2] minutes
[x] Automatically download new messages
[ ] Fetch headers only
[x] Leave messages on server
    [x] for at most [ 2] days


1.  totally Quit SeaMonkey
2.  send message(s) to a SeaMonkey account while it is down
3.  Start SeaMonkey so that it does not immediately open mailnews (i.e. the default behavior of just open a browser window.)
4.  Wait for the initial mail poll, which should display the count of messages you sent.
5.  Open mailnews.
6.  Read messages.

Observed results:
5.  When mailnews is opened, the message count on the dock icon *doubles*.
6.  As the messages are read, the dock count decreases, but due to the doubling, it only goes back down to the undoubled count and that count becomes a base count which persists until SeaMonkey is again quit and restarted.  New message may be received and read causing the dock count to go up and down, but that count will always be in addition to the erroneous base count from startup.

Expected results:
5.  The count displayed in the dock should not double on the initial opening of the mailnews window.

So it seems that this is a startup error.  Perhaps it is due to the way bug 71105 was implemented. I have been running with Check for New Messages at Startup turned off due to the clearing of New flags noted in Bug 344066.  I haven't retested that bug.
 
Changing title from "Seamonkey beta dock icon (showing total emails) does not reset" to "Seamonkey 2 beta dock icon (showing new emails) does not reset".
I suspect this is a SeaMonkey only error, not mailnews core.  Not quite sure where it belongs though.

Comment 5

[David Humphrey (:humph)]

This sounds like bug 516477.

Comment 6

[Rich Gray (:rbgray)]

I think this bug needs to be fixed, found to be an odd edge case or a suitable workaround found before SM 2.0 is released.  As it stands now, having the SM dock icon indicating there is new mail when there isn't will look Really Bad.  Requesting blocking SM 2.0.

I got tied up tonight, but will make time tomorrow night and onward to work on characterizing this bug.  
- is it a function of not having Check for New Messages at startup selected?  I suspect it is.
- If bug 344066 has gone away, this is not as much a problem.
- When I open Mailnews and manually get messages before the automatic check kicks in, there is no doubled count.
- I tried to reproduce this under TB 3.0b4, but couldn't.  

Wade: are you running 2.0rc1?  Can you describe your account settings as I did in #4?  Any other observations?

Comment 7

[Robert Kaiser]

I actually don't think we should block the release on this, but I'll ask the other council members for a second opinion.

We should really be starting the build process for RC2/final today, any day we wait for anything means slipping a day nearer towards the absolute release deadline of the end of October, we we are nearing more and more in any case.

So either be very fast on this or go for 2.0.1.

Comment 8

[David Humphrey (:humph)]

Rich, I'll be around today working on things, if you want to ping me on irc (humph in #maildev).  I know this code, but can't reproduce the bug, so if you can, perhaps we can work together to solve it.

Comment 9

[Robert Kaiser]

OK, talked with IanN on IRC and we'll not block on it, as it's apparently hard to reproduce, which means it only affects a smaller part of our already pretty small Mac user base - and then it doesn't really break anything but is just not pretty. We'll mention it in "Known Issues" in the release notes, though.

Of course, if a fix comes in before we cut RC2/final, we'll take it, and if we'd need another RC, it surely would be a candidate to be taken for that.

Comment 10

[Wade Reese]

My server settings for the test account:

[x] Check for new messages at startup
[x] Check for new messages every [1] minutes
[x] Automatically download new messages
[ ] Fetch headers only
[ ] Leave messages on server
    [ ] for at most [ ] days

I am on SM build version 2.0pre 
  
    *     Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5pre) Gecko/20091012 SeaMonkey/2.0pre

Comment 11

[TommyBee (No E-mail)]

I run into the bug with an IMAP account in RC1.

In the "Appearance" preferences category, under "When SeaMonkey starts up, open", only "Browser" is checked.  In the "Mail & Newsgroups" preferences category, I have "Only check for new mail after opening Mail & Newsgroups" unchecked.  My account settings include "Check for new messages at startup" and "Check for new messages every 10 minutes".

Just a moment ago, I launched RC1 (just showing the browser window).  Prior to launch, the account had 5 unread messages.  The dock icon immediately showed a value of 2, apparently indicating that 2 new unread messages had arrived in the inbox.

When I launched Mail & Newsgroups, I saw that the inbox unread count was 7 (the 5 original unread messages plus the 2 new ones).  However, the dock icon now displayed a value of 9:  it may be adding the count of new unread messages seen earlier to the count of actual unread messages in the inbox.

Upon reading the 2 new unread messages, the inbox unread count went down to 5, but the dock icon unread count went down to 7.

When I quit and relaunched RC1 with no new messages in the account, the dock icon did not show the unread count immediately (with only the browser open).  When I launched Mail & Newsgroups again, the dock icon correctly displayed an unread count of 5.

Comment 12

[David Humphrey (:humph)]

It's not my place to dupe this, but I really recommend this bug get collapsed into bug 516477.  They are the same issue, and share the same code.

Comment 13

[TommyBee (No E-mail)]

I did further testing on another machine with RC1 including the same IMAP account.

Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4) Gecko/20091007 SeaMonkey/2.0

Starting Point:
1 IMAP account with 5 unread messages (the account from the earlier report).
1 IMAP account with 3 unread messages.
1 POP3 account with 3 unread messages.
A total of 11 unread messages.

Action:  Launch SeaMonkey with two new messages waiting for IMAP account #1.

Settings for Test 1:
1. Only _Browser_ displayed at startup.
2. Only check for new mail after opening Mail & Newsgroups _IS_ selected.

Test 1 Result:  A browser window opens.  The dock icon does not show the unread messages at startup.  Upon launching the Mail & Newsgroups component, the two new messages arrive, bringing the unread total for Inbox #1 to 7.  The dock icon correctly displays a count of 13 unread messages.  I read both messages, and both unread counts decrease by 2, down to 5 for Inbox #1 and 11 for the dock icon (their original counts).

Settings for Test 2:
1. Only _Mail & Newsgroups_ displayed at startup.
2. Only check for new mail after opening Mail & Newsgroups _NOT_ selected.

Test 2 Result:  Mail & Newsgroups component launches immediately.  Again, the two new messages arrive, bringing the unread total for Inbox #1 to 7.  The dock icon correctly displays a count of 13 unread messages.  I read both messages, and both unread counts decrease by 2, down to 5 for Inbox #1 and 11 for the dock icon (their original counts).

Settings for Test 3 (my original settings):
1. Only _Browser_ displayed at startup.
2. Only check for new mail after opening Mail & Newsgroups _NOT_ selected.

Test 3 Result:  A browser window opens.  The dock icon shows a count of 2 for the new messages at startup.  Upon launching the Mail & Newsgroups component, the two new messages arrive, bringing the unread total for Inbox #1 to 7.  The dock icon now incorrectly displays a count of 15 unread messages (2 messages too many).  I read both messages, and both unread counts decrease by 2, down to 5 for Inbox #1 (the original count) and 13 for the dock icon (still 2 messages too many).

Comment 14

[Rich Gray (:rbgray)]

TommyBee notes that this seems to be a function of the browser window launching at startup with Only check for new mail after opening Mail & Newsgroups NOT selected, i.e. begin checking for mail in the background at startup.  I should have mentioned that that is my failure configuration too.  This would seem to make the bug a consequence of bug 71105, which added this otherwise wonderful feature.

So far, it is NOT
- a function of POP vs IMAP
- a Leopard (10.5) vs Snow Leopard (10.6)
- a function of Check Messages at Startup in the account server settings

Right?  Anything else?  I've been using my migrated profile, with multiple POP accounts (and most of them over SSL.)  I can't remember if it checked in a clean profile.  Will do so now.  Number of accounts?

(In reply to comment #12)
> It's not my place to dupe this, but I really recommend this bug get collapsed
> into bug 516477.  They are the same issue, and share the same code.

Well, this might be true, but right now, the two bugs seem to be reporting the same end result due to two different and non-overlapping conditions.  I'm seeing a solid failure at SM startup, while bug 516477 seems to occur after TB has been up a while.  So I think that keeping the two scenarios separate for now is useful.  This bug seems to be a function of an enhancement that doesn't exist in TB.  That said, if you want to dup it, go ahead, maybe it would stimulate some ideas.

It seems I missed you in #maildev this evening. (I'm in the US Eastern timezone.)

Comment 15

[Mark Banner (:standard8)]

Ok, so comment 13 is interesting, and I think makes this pretty much a SeaMonkey-only bug. Although it could help/affect bug 516477 as well.

I think the issue is with nsMessengerOSXIntegration. The service has an init function that is called when mailnews is initiated - so in the test 3 case, this would be when SM checks for new email with just the browser window open. The init function registers a folder listener for new mail.

However, it isn't until the mail-startup-done notification is sent from the observer service that nsMessengerOSXIntegration does an initialisation of the unread count. The mail-startup-done notification is only sent when the main mail window is opened.

There are two main issues:

1) The fact that mailnews can get unread mail before mail-startup-done notification is sent means that the dock icon will just show the unread messages that have come in that session until the main mail window is opened.

2) InitUnreadCount doesn't quite do what it says. It actually goes through all the folders summing the unread counts and then adds that onto mUnreadTotal - mUnreadTotal is not cleared first.


The first one explains the effect initially seen in test 3 of comment 13.

The second one then explains why when opening the main mail window that you can't then get the count down to zero - you've already had 2 messages then it goes through the folders and adds on the total unread count, including the 2 you've already received in this session.


Whilst the effect of this second part seems to be significantly SeaMonkey, I'm wondering if there's a chance that Thunderbird could be affected on slow startups which could lead to a fix for bug 516477 - it would have to be that the check for new mail occurs before mail-startup-done, which I think may be possible but I'm not sure.

I'm hoping humph can take this information and form a patch or two out of it.

Comment 16

[David Humphrey (:humph)]

Created a patch to allow debug info in the Error Console for QA/testing, see bug 516477 comment 21.  Anyone care to help me create a try server build of it for SM so people can test?

Comment 17

[David Humphrey (:humph)]

Standard8 is helping me with these try server builds (thanks!):

18:18 <%Standard9> humph: the TB builds are tagged humph-dock-debug, the SM builds are tagged humph-dock-debug-sm
18:19 <%Standard9> humph: they will start showing up on http://tinderbox.mozilla.org/showbuilds.cgi?tree=ThunderbirdTry within about 15 mins. Take about 4 hours for them all to be complete

Comment 18

[David Humphrey (:humph)]

SM build with extra debug info is done:

http://s3.mozillamessaging.com/build/try-server/2009-10-15_15:[e-mail]-humph-dock-debug-sm/[e-mail]

Test away!

Comment 19

[TommyBee (No E-mail)]

I used the build with extra debug info with the same settings that caused the problem in Test 3 in comment 13 (Browser displayed at startup, allow check for new messages prior to launch of Mail & Newsgroups) and two new messages pending for account #1.  Again, the dock icon initially displays 2 prior to launching Mail & Newsgroups, and the number goes to 15 after I launch Mail & Newsgroups when in actuality there are 7 in the first IMAP inbox, 3 in the second IMAP inbox, and 3 in the Local Folders inbox (used for the POP3 account), for a total of 13.

Here's the info from the Error Console (account names replaced):

Updated Unread Count for account/folder (IMAP Account #1)/Inbox: Folder's Old Value=5, Folder's New Value=6, Change=1, New Unread Total=1.

Updated Unread Count for account/folder (IMAP Account #1)/Inbox: Folder's Old Value=6, Folder's New Value=7, Change=1, New Unread Total=2.

Starting Initial Unread Counting...

  Initial Unread Count for folder Local Folders=3.

  Initial Unread Count for folder (POP3 Account -- uses Local Folders inbox)=0.

  Initial Unread Count for folder (IMAP Account #2)=3.

  Initial Unread Count for folder (IMAP Account #1)=7.

  Initial Unread Count for folder News & Blogs=0.

Finished Initial Unread Counting.

Comment 20

[David Humphrey (:humph)]

Nice!  So this clearly shows that we're seeing a bug related to the order of startup.  See how it shows those 2 updates before "Starting Initial Unread Counting...", that shouldn't happen.

bienvenu, we do the initial count in response to "mail-startup-done" (see http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMessengerOSXIntegration.mm#286) and clearly the other OnItemIntPropertyChanged events (e.g., for "TotalUnreadMessages") are coming in first.  So either I need to ignore these updates until init happens, or we need to make the order of these events work as it should.

Comment 21

[Rich Gray (:rbgray)]

I see the same pattern.  Picked up 3 prior to the start of initial unread counting, then found 6 winding up with 9 instead of 6.

Comment 22

[David :Bienvenu]

(In reply to comment #20)
 So either I need to ignore these
> updates until init happens,

That's what you're going to need to do, I think.

> or we need to make the order of these events work
> as it should.

We can't really control the order of those events. It would be fragile if we did.

Comment 23

[Rich Gray (:rbgray)]

>
>
> --- Comment #22 from David :Bienvenu<[e-mail]>   2009-10-15 19:41:08 PDT ---
> (In reply to comment #20)
>>   So either I need to ignore these
>> updates until init happens,
>
> That's what you're going to need to do, I think.

Careful, that sounds a lot like no dock count until the window is opened.

>> or we need to make the order of these events work
>> as it should.
>
> We can't really control the order of those events. It would be fragile if we
> did.

Seems like the problem is that some of the code still assumes initial window opening == init time.  But the true initialization time is now moved up when mail checking begins when the suite starts prior to mailnews window open...

Comment 24

[Mark Banner (:standard8)]

I think the initial quick fix could be just to get InitUnreadCount to set mUnreadCount to zero before adding any more onto it. This would then mean that a) SeaMonkey users will get some notification of new unread mails coming in (although the count would be wrong), b) we can see if it helps bug 516477 for Thunderbird.

We can then consider what to do about initialisation. I'm kinda thinking what we should do is to move the InitUnreadCount into the Init() function that gets called when mailnews is initialised, but I think that is also too early.

Is there some sort of notification after the first get new mail check or the mail accounts having been initialised that we could hook into?

Comment 25

[David Humphrey (:humph)]

Let me ask one more question before I do a fix: does SM have something earlier I could use than mail-startup-done to trigger InitUnreadCount?  If the Observe() method in nsMessengerOSXIntegration is being called, and we're getting updates on changes to unread mail, clearly it has been created before this.

Comment 26

[David Humphrey (:humph)]

One other thought I have...what if I do InitUnreadCount() based on mail-startup-done and/or when the first update event is received.  In other words, if there isn't a better initial event I can use, guard both the initial and update code with a simple check to see if the first initial count has been done yet, and do it if not.

So it's either this or something in response to my question in comment 25.  Thoughts?

Comment 27

[David Humphrey (:humph)]

Attachment: Fix for initial count and startup order

This removes the assumption that updates to folder unread counts will always come after we do initial startup and an initial count.  Now we will keep track of whether the initial count has been done, and do it before showing any count on the dock.

Comment 28

[David :Bienvenu]

Comment on attachment 406719 [details] [diff] [review]
Fix for initial count and startup order

looks good to me.

Comment 29

[Mark Banner (:standard8)]

Comment on attachment 406719 [details] [diff] [review]
Fix for initial count and startup order

This doesn't quite fully address the SeaMonkey issue - it doesn't take care of the case when browser is opened and new mail is checked for, but none is received. However it is much better than what is there presently, so sr+a=Standard8 if you also file a bug on that case.

Comment 30

[David Humphrey (:humph)]

Filed bug 523159.  This is ready to go in.  Thanks.

Comment 31

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/851df5a119c8

Comment 32

[TommyBee (No E-mail)]

Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5pre) Gecko/20091030 SeaMonkey/2.0.1pre

Looks good!  I sent two messages to one of my IMAP accounts and launched SeaMonkey with the Browser component launching at startup, and instead of the dock icon displaying "2" for the number of new messages, it displayed "9" for the total unread messages (7 in the first IMAP account, 2 in the second).  Launching Mail & Newsgroups no longer creates an incorrect dock icon count.  The count decrements correctly when I read a message.

Comment 33

[Rich Gray (:rbgray)]

(In reply to comment #29)
> (From update of attachment 406719 [details] [diff] [review])
> This doesn't quite fully address the SeaMonkey issue - it doesn't take care of
> the case when browser is opened and new mail is checked for, but none is
> received. However it is much better than what is there presently, so
> sr+a=Standard8 if you also file a bug on that case.

What is this condition??  Has it been addressed?

I just had a false count of 3 in SM 2.0.1 Mac yesterday.  It's been good up till now.   I just upgraded to 2.0.2 and will continue watching.