Closed Bug 516477 Opened 15 years ago Closed 14 years ago

Dock shows a double count of unread messages

Categories

(Thunderbird :: OS Integration, defect)

x86
macOS
defect
Not set
normal

Tracking

(blocking-thunderbird3.1 rc1+, thunderbird3.1 beta2-fixed, thunderbird3.0 .1-fixed)

RESOLVED FIXED
Thunderbird 3.1b2
Tracking Status
blocking-thunderbird3.1 --- rc1+
thunderbird3.1 --- beta2-fixed
thunderbird3.0 --- .1-fixed

People

(Reporter: mossop, Assigned: Bienvenu)

References

()

Details

(Whiteboard: [gs])

Attachments

(7 files, 5 obsolete files)

I'm using the smart folder view so I have the smart Inbox under which are two inboxes from different accounts. The dock number is pretty much always incorrect. I currently have 3 unread messages in one account and 1 in another. The dock says I have 7 unread. Wait it just changed, now 4 in one, 1 in another and the dock thinks 9.

As best as I can tell it is counting the number of unread messages in one of my accounts twice. Possibly coincidence but this is the account listed first in the list (Mozilla's Zimbra server).
Flags: blocking-thunderbird3?
there was a bug where the dock number was counting messages in saved searches, but I thought that was fixed...
Also seen 5,1 and 11 and then 5,2 and 12.

(In reply to comment #1)
> there was a bug where the dock number was counting messages in saved searches,
> but I thought that was fixed...

Yeah, humph asked me to file this.
I think this probably needs to block (but not b4)
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0rc1
Assignee: david.humphrey → nobody
Status: NEW → ASSIGNED
Component: Folder and Message Lists → OS Integration
QA Contact: folders-message-lists → os-integration
Assignee: nobody → david.humphrey
Whiteboard: [no l10n impact]
David [Eeek! *four* Daves here?!] errr, Humph commented on bug 509163 that it may be a dup/related to this bug.  SeaMonkey 2.0B2 is doubling the count in the dock when the initial opening of mailnews occurs.
From memory TB and SM share this part of the code so it should affect both.
Blocks: 509163
I'm working on this, but can't reproduce.  I have tried doing smart folders with inbox counting only, and all folders.  I have tried profiles with only 1 mail account, and others that combine 2 accounts into a common inbox (gmail imap + another imap).  It always gives me the right number.

What I have seen is this: when doing my testing, and making new profiles for gmail, gloda kicks in and starts indexing my sent mail, which takes a *long* time.  While that's happening, I get no notifications for changes to unread counts (I have some debug instrumentation in a build here).  If I try changing the unread count in TB, it seems to do it (e.g., marking a whole folder as read), but then on restart, gmail hasn't reported the change yet, and it goes back, causing the number to go out of sync.  The numbers are made even worse because gmail reports -1 changes for bulk unread changes, which means they trickle in if indexing is happening.

I need some more help tracking this down from those who are seeing it.  I have a hard time believing this is due to Smart Folders, as I explicitly check for that case.  Any more info?
davida says he's seeing this when in 'All Folders' mode vs. 'Smart Folders.'  I tried that, and it still works for me.  He also mentioned that he's on Zimbra for one of his servers.  Others who are seeing this, are you on Zimbra?  I wonder if this is backend trouble vs. how we report what we're told.
I'm in a pure IMAP configuration.  Two Dovecot IMAP accounts (same server) and one Gmail account.  Is it possibly related to updating the data file from TB 2.x to TB 3.x?  My install is an upgrade.

The Gmail folder is being added correctly.  Both Dovecot IMAP accounts are being counted double.
(In reply to comment #9)
> Is it possibly related to updating the data file from TB
> 2.x to TB 3.x?  My install is an upgrade.

Unlikely, since it will go to the server to ask for new counts (it will use cached values at first, though).

> The Gmail folder is being added correctly.  Both Dovecot IMAP accounts are
> being counted double.

Interesting.  This confirms what I'm seeing, at least in terms of Gmail behaving, and may point to Dovecot's impl and how we poll it.

Anyone else?
(In reply to comment #10)
> Interesting.  This confirms what I'm seeing, at least in terms of Gmail
> behaving, and may point to Dovecot's impl and how we poll it.
> 
> Anyone else?

I'm not willing to look through the source code, but what IMAP command is used to grab the count?  I'd be glad to connect by hand via telnet and post my raw results.  

Seems like two numbers are being polled, and then added together with the assumption that one or the other will always be 0.
(In reply to comment #10)
> (In reply to comment #9)
> > Is it possibly related to updating the data file from TB
> > 2.x to TB 3.x?  My install is an upgrade.
> 
> Unlikely, since it will go to the server to ask for new counts (it will use
> cached values at first, though).

David if you need access to different kind of server raise a bug against gozer. (the list of available server is at https://wiki.mozilla.org/Thunderbird/Infrastructure/MailTest minus zimbra for now)
gozer kindly set me up with accounts on the dovecot testing box, and I've done more testing against it.  I still can't reproduce this.  I don't doubt the folks in this bug are telling the truth, but this is 100% WFM no matter how I try to break it.
Very strange!  But I fixed mine!

I had my IMAP server settings set to "Check for new messages on the server every 1 minute" on the accounts that had a duplicate count.  Probably a silly value for IMAP, I guess.

I had it set to 10 minutes on Gmail.  Which did not count duplicates.

When I changed them all to 10 minutes, and quit and reopened Thunderbird - I get the correct counts!

Oddly, I changed them both back to 1 minute and I haven't had the problem come back.  Is there some kind of race condition between checking for messages on startup and the check again 1 minute later?  That doesn't sound right.

I'm sure that in terms of actually fixing things, I just made it worse by having a baffling workaround.

Can anyone else confirm that this fixes their Inbox counts?
I only test with 1 minute IMAP intervals (I'm too impatient for 10 mins!).  I don't think this value has any effect on this bug.  Also, the fact that I can't reproduce this, and that you are now not seeing it, leads me to believe that this is a symptom of some other bug vs. how we are doing the dock count itself.  My code is just responding to property changes reported by the folders, so it is possible that they are sometimes misreporting due to another bug somewhere else.  I don't think we double count, but perhaps a count double to what is correct was reported in some edge case that you guys have seen locally.

Unless others can come forward with more solid steps to reproduce this reliably, I think this is WFM.
I'm just chiming in to say I've noticed this as well [3.0b4].  One account setup, imap, unchanged timings.  The dock-reported unread count is double the true count.  No smart folders in use.
I retract my previous statement about timings.  It seems that just closing and re-opening the program corrects the numbers for a time.

It seems to be based around the program being open for a while.  I don't know if it's length of time or if it's when I'm having connectivity issues (timeouts, etc.).  

I know that it stayed at the correct count for at least an hour.  Not sure if I'll have time to watch it to see when it starts doubling.
This bug is stuck; adding qawanted in the hopes of getting steps to reproduce.
Keywords: qawanted
In bug 509163, when SeaMonkey starts, the browser window opens and mail checking begins in the background (no MN window yet.)  I see SM pick up the correct number of pending messages (sent before SM started) in the dock count.   When I open the MN window, the dock count doubles.  POP3 by the way.

Reading this bug, I don't get a sense of when the count goes wrong.  It is wrong right from the start or is there some sort of sequencing between messages arriving when all windows are closed vs open?  Do the counts get screwed up WHEN the window is opened?
If we're sending this notification every time a 3 pane window is opened, I think the message notification code should only pay attention to the first notification...
In the interest of making this easier to debug, I've done a patch to add a bunch of debug info to the Error Console.  This should show us when and why the counts are getting out of sync.  I'm hoping someone can help me figure out how to spin builds of this for TB and SM using the try server so others doing QA can help test.
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
Anyone had a chance to test this yet?  I think I have the fix for the SeaMonkey version of this, and would love to fix the TB case at the same time, in case they are different.
couldn't you throw away all the counts you know about when you get the mail started notification, and recalculate them?
We've landed a fix for bug 509163, which I'm hoping will fix this issue, too.  Can folks on nightlies who have seen this watch for it happening again?
Whiteboard: [no l10n impact] → [no l10n impact] [hopefully fixed by bug 501963; waiting for confirmation]
(In reply to comment #26)
> We've landed a fix for bug 509163, which I'm hoping will fix this issue, too. 
> Can folks on nightlies who have seen this watch for it happening again?

Seems to have fixed it for me.
Based on comment 27 (and no other comments yet) I'm closing this as fixed by bug 509163. If this still occurs, please feel free to reopen (and try and provide extra STR if possible!).
No longer blocks: 509163
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Depends on: 509163
Resolution: --- → FIXED
Whiteboard: [no l10n impact] [hopefully fixed by bug 501963; waiting for confirmation] → [no l10n impact][believed fixed by bug 501963]
David, try this one.
Attachment #406539 - Attachment is obsolete: true
Attachment #410116 - Flags: review?
Attachment #410116 - Flags: review? → review?(david.ascher)
Attached image log console screenshot
I think the attached may give us a clue: notice that the top rows (recent but not most recent) just show updates for Inbox, but just recently (as I noticed the doubling) we're seeing checks for both Inbox and INBOX.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [no l10n impact][believed fixed by bug 501963] → [no l10n impact]
> I think the attached may give us a clue: notice that the top rows (recent but
> not most recent) just show updates for Inbox, but just recently (as I noticed
> the doubling) we're seeing checks for both Inbox and INBOX.

10:03 < bienvenu> humph, so the question is how davida got two listeners registered for the same folder
10:03 < bienvenu> or rather, how there came to be two folders with basically the same uri...

This is a bug, but I'm not sure it's a bug with how we report counts.  You *actually* have two Inboxes (i.e., all folders report, but I check flags vs. the name - nsMsgFolderFlags::Inbox).  So something is wrong here, but I think we need to look elsewhere, maybe file a new bug?
If you mean the bug is in code other than the dock code, that sounds right to me. But the user-visible manifestation is here, so I'm not sure a new bug is needed.
Oh, and "INBOX" is what most imap servers tend to call the Inbox, and the string we use in the imap protocol code, and Inbox is our pretty name for it (though I'm not sure what Zimbra does). But the imap rfc is quite clear that INBOX is supposed to be case-insensitive.

It might be intersting to see davida's virtualFolders.dat to see if he has duplicate entries for the inbox.
Attached file virtualfolders.dat
your wish is my command
no duplicate entries, and it uses the "INBOX" uri, which is what I'd expect. The question becomes, where did the "Inbox" form of the URI come from. One funny thing about Zimbra is that it doesn't return the INBOX from LSUB, which may or may not be involved. I wonder if the Inbox.msf file thinks the URI should end with "/Inbox" and we create that uri during local imap folder discovery, before we connect to the server.
this is just a wild guess, but you could try running with this patch and see if that gets rid of the duplicate inboxes from the console logging.
After discussion with bienvenu, and observing that:

* we have no good reproducible test case
* the number of people seeing it (as inferred from the number of folks on the bug) appears to be small
* humph put up a try-server build with debug logging weeks ago, and noone on this bug was able to make time to try it and report back
* bienvenu has no reason to believe that the patch he posted will work; it's simply a stab in the dark
* this is Mac-only, and Mac accounts for a small percentage of Thunderbird users

I don't see how we can continue to block on this.  Marking as blocking-.

If someone seeing the problem can find the bandwidth to try the debug builds that are linked to in comment 23 and they produce useful info, we could reconsider.
Flags: blocking-thunderbird3+ → blocking-thunderbird3-
I'm still on a lowly Mac PPC machine, and the try build in #c23 doesn't seem to be universal binary..?

The fix from 509163 seems to have helped this, but I do still see double counts occasionally now (haven't figured out how to reproduce).
Just got around to this bug thread. Downloaded the build mentioned in #23 and it seems to count messages correctly for now. 3.0b4 double-counted messages in the Inbox of the first server whereas the new Shredder build seems to do the right thing for now. If I see it come back I will update with more info.
Comment on attachment 410543 [details] [diff] [review]
patch to see if this avoids the duplicate inboxes

davida says this is helping. IMAP itself specifies that INBOX be treated case-insensitively, so this shouldn't break anything in imap-land.
Attachment #410543 - Flags: superreview?(bugzilla)
Attachment #410543 - Flags: review?(bugzilla)
I've now seen this in 3.0RC1-build3. I've been trying to run with imap logging, but of course it happened when I wasn't.

My only new info is that the activity window shows 2 new messages downloaded to my main imap account, and the imap inbox says 2 new, but the icon shows 4. My other (gmail) account has no new messages.
We know this isn't and won't be completely fixed in 3.0.
Attached file imap:4 log file
I know this isn't going to be fixed for 3.0, just trying to give more info.

Attachment is my imap level 4 protocol log when I got this issue. I tried to cut off the relevant end section, let me know if some amount of previous log data is needed. 

I had no new messages, and then one showed up, and the badge had a double count.
Attachment #414172 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 410116 [details] [diff] [review]
Debug patch updated to trunk

This seems to be an obsolete review request... clearing.
Attachment #410116 - Flags: review?(david.ascher)
Comment on attachment 410543 [details] [diff] [review]
patch to see if this avoids the duplicate inboxes

Patch looks good but I think we can optimise it a bit more.

>-  rv = GetChildWithURI(uri, PR_FALSE/*deep*/, PR_FALSE /*case Insensitive*/, getter_AddRefs(msgFolder));
>+  PRBool caseInsensitive = mIsServer && name.EqualsLiteral("INBOX");
>+  rv = GetChildWithURI(uri, PR_FALSE/*deep*/, caseInsensitive /*case Insensitive*/, getter_AddRefs(msgFolder));

Further down in the function we call GetServer, and then use isServer and a LowerCaseEqualsLiteral function:

http://hg.mozilla.org/comm-central/annotate/d577d6744586/mailnews/imap/src/nsImapMailFolder.cpp#l442

Can we optimise these to use the same checks and boolean?
Attachment #410543 - Flags: superreview?(bugzilla)
Attachment #410543 - Flags: review?(bugzilla)
Attachment #410543 - Flags: review-
Assignee: david.humphrey → bienvenu
Whiteboard: [no l10n impact]
Target Milestone: Thunderbird 3.0rc1 → ---
Attached patch fix addressing comments (obsolete) — Splinter Review
ok, this gets rid of the duplicate checks...
Attachment #410543 - Attachment is obsolete: true
Attachment #415252 - Flags: superreview?(bugzilla)
Attachment #415252 - Flags: review?(bugzilla)
Anxious to try out with the patch.

One additional data point: My current count on the dock is 7: I have 3 in my imap inbox, 1 in my my gmail inbox (using it as imap) - so the count is doubled for only one account.
Attachment #415252 - Attachment is obsolete: true
Attachment #416751 - Flags: superreview?(bugzilla)
Attachment #416751 - Flags: review?(bugzilla)
Attachment #415252 - Flags: superreview?(bugzilla)
Attachment #415252 - Flags: review?(bugzilla)
Comment on attachment 416751 [details] [diff] [review]
the check should be case-insensitive...

r/sr=Standard8. This looks good for trunk.

Is there a way we could provide a some kind of unit test for this?
Attachment #416751 - Flags: superreview?(bugzilla)
Attachment #416751 - Flags: superreview+
Attachment #416751 - Flags: review?(bugzilla)
Attachment #416751 - Flags: review+
Attachment #416751 - Flags: approval-thunderbird3.0.1?
Just thought I would chime in. I see my unread message count in the Dock being doubled from the actual count in "All folders" in previous released of Thunderbird 3. I just upgraded to version 3 final and still see the same doubling of unread messages.
Potential fix checked into trunk. It should be in 3.1.

Unit test is hard to imagine since the fix is somewhat speculative.
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1a1
(In reply to comment #52)
> Unit test is hard to imagine since the fix is somewhat speculative.

I was wondering if there was a way we could get fake server to give us INBOX in the folder name and check we don't get too many folders registered (if that's possible).
I'm the person who filed Bug 534034. Thunderbird usually displays double the unread email count for me in the dock. I am using the all folders view, not smart folders. I have Thunderbird set up with one IMAP account.
Similarly, I am running vanilla TB3 on MacOs 10.6.2, using "all folders" view, but with two IMAP accounts. My dock icon displays double the actual number of unread messages across the two accounts.
Yes, this fix won't in a release until 3.1, or maybe 3.01
Unfortunately, I'm still seeing this issue in the 3.0.1pre nightly. Bummer.
Comment on attachment 416751 [details] [diff] [review]
the check should be case-insensitive...

Ok, afaik no issues from our few trunk testers (at least from the regression aspect), so lets get this in on branch over Christmas and get some more testing there.
Attachment #416751 - Flags: approval-thunderbird3.0.1? → approval-thunderbird3.0.1+
I'm experiencing a similar problem but my smart inbox shows an unread message count of "1 more than the total number of unread messages in all accounts" (formula is different :) ). When I have no new messages, my smart inbox shows 1 unread message. This happens when new mail is received. When I select the smart inbox everything goes back to normal.

I don't know if this bug is related or not, but might be. So I will until this bug resolves and file a new report accordingly if necessary.
Checked into branch:

http://hg.mozilla.org/releases/comm-1.9.1/rev/cc5310dc7ef2

This should be in 3.0.1pre builds from tomorrow.
Maybe a bit premature before (looked through the hg logs and thought it was checked in) but I'm still getting this problem with the nightly. Seems like it's happening less often, but I really don't know what to do to make it happen so...
V. Fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100107 Shredder/3.0.1pre
Status: RESOLVED → VERIFIED
This problem still exists in 3.0.1 - took longer than before to occur though - approx half a day of use.
I also still have this problem on Thunderbird, although I am not using smart folders view.
I'm trying to debug this using the trunk nightly, and the problem is definitely in the MacOSX integration code, as nsMsgMailSession::OnItemIntPropertyChanged has the correct counts, but the next and final function up the stack, nsMessengerOSXIntegration::OnItemIntPropertyChanged is where the doubled counts show up. I have to try another run from no unread to a doubled count to see if I can figure out where things are getting called twice.
(In reply to comment #65)
> V. Fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
> rv:1.9.1.7) Gecko/20100107 Shredder/3.0.1pre

(In reply to comment #67)
> This problem still exists in 3.0.1 - took longer than before to occur though -
> approx half a day of use.

Should status be changed to "REOPENED" ?
(In reply to comment #70)
> Should status be changed to "REOPENED" ?

Probably. It now shows the right number most of the time, but sometimes it still shows a double count. Before it always showed a double count for me.
This should be reopened, or 534034 should be reopened and the discussion moved there - as this bug (as titled) pertains to using smart folders, and what we're still seeing is this issue with just regular imap use and all/normal folders.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I have the same issue with mac os x leopard, using thunderbird 3.0.1
I have 2 accounts and I guess, the dual count in coming from my Gmail account. I use All folder view and I can confirm that this issue is not limited to Smar folder view.
I am only subscribed to Inbox, starred, trash , sent mail and drafts.
I'm seeing this bug on 3.0.1 with only POP accounts.  I have several POP accounts, and the number of unread messages in my entire inbox is being counted twice.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
Now I am not seeing this issue. 2 days back I am damn sure that it was there and now it seems to be coming correct.
I've been seeing this double count since switching to TB 3.  It is very annoying.  It takes a little while (maybe an hour) for it to show up and then the dock counts begin (and stays) to be a double count.  I use IMAP and local folders.  Not sure if I use smart folders, I think TB switched me to smart folders when I upgraded.
bienvenu, this appears to have lingering issues that comment 78 suggests are a regression from Tb2, so it may want to block 3.1.  Would you prefer to drive it forward here or in a new bug?
I would be very hesitant to block 3.1 on a mac-only bug that no developer seems to be able to reproduce. Dmose, are you seeing this bug?
bienvenu: I wish I knew.  My current dock count is 35, even though none of my accounts are turned blue, and this has been true for a few days.  I've been assuming my problem is unrelated to this one, but I don't actually know that.
Let me know what the best way to diagnose that problem is, and I'll do it.

Whether or not this bug blocks, there's still something going on with double counts.  Do you want to track the problem here, or spin off a new bug?
To answer that, I'd need to know if the double count bug people are seeing has to do with smart folders or not. If it does, then track the problem here, otherwise, it's a new, different bug.
The dock count is now an unread count, not a new count, so the fact that none of your accounts are blue is not necessarily an indication that you're seeing anything wrong.
:dmose
It sounds like you are talking about bug 518828. The number shown is now unread messages, not new messages, which is almost useless for me.
> I'd need to know if the double count bug people are seeing has
to do with smart folders or not.

It has not to do with smart folders, I see it even though I do not use smart folders.
Also, someone above mentionned it only happened on POP accounts; before you ask, I have this issue with an IMAP account.
I've had this issue since upgrading to Thunderbird 3. I have one IMAP account, and I do not use smart folders.

Since I have updated to 3.0.1 the problem with the double count is less frequent, although it still happens. It now seems like I have to have Thunderbird open for a little while before it occurs. With 3.0 the problem would usually occur immediately. The change made here seems to have helped some even though I do not use smart folders.

I do not know if this is related, but the email account I use is used by multiple people simultaneously. Often somebody else will erase, move, and label emails using Thunderbird on another computer while I have Thunderbird open in the background on my computer.
I have two IMAP accounts - and do *not* use smart folders view.

In my client right now the dock icon is showing "4". In one inbox there are no unread messages, in the other two.

I now click on one of the unread messages and the count in the dock icon immediately drops to "2". As I click on the second the dock count immediately disappears.

Very simple symptom, the vast majority of the time the dock shows exactly twice the number of unread messages over my two inboxes. Much more rarely it is right for a while, or weirdly sometimes it counts twice from one inbox and correctly from the other.

I am running 3.0.1 on MacOS 10.6.2, and my mail accounts are on 1&1 and Zimbra respectively. Kind regards,

Geoff.
Marianne, do you know what kind of imap server? Is it Zimbra, perhaps?
bugzilla1@matt13.com: that's not it either, as I have way more than 35 unread messages.  I'll file a separate bug for my problem.

Since the majority of recent complainants seem not to be using smart folders, I'm resetting this to new for ongoing work here.

There seem to be enough complaints here that I believe that at least some further exploration for 3.1 is warranted.  Since davida sees it on a Zimbra server, and gozer can get you access to one of those, I'm setting it to blocking: needed+ for now.
Status: REOPENED → NEW
blocking-thunderbird3.1: --- → needed
@David :Bienvenu : not Zimbra, MS Exchange
Our test zimbra server seems to be down.

I've changed the summary to remove smart folders, then.
Summary: Dock shows a double count of unread messages in smart folder view → Dock shows a double count of unread messages
(In reply to comment #69)
> I'm trying to debug this using the trunk nightly, and the problem is definitely
> in the MacOSX integration code, as nsMsgMailSession::OnItemIntPropertyChanged
> has the correct counts, but the next and final function up the stack,
> nsMessengerOSXIntegration::OnItemIntPropertyChanged is where the doubled counts
> show up. I have to try another run from no unread to a doubled count to see if

Haven't had time to try and debug this again, but my thought was that the IMAP code is sending out the wrong or double messages to recount/increment the Mac integration code?

Also, I'm seeing this against a dovecot IMAP server at bluehost.com.
the suspicion is that due to a case-name mismatch between what the imap server reports, and what we have stored locally for the INBOX name, we actually have two inbox folders, and count them twice. But I'm not able to reproduce it here.
I'm not seeing this happen with the Zimbra test account, though I don't get any new mail delivered there, so I have to copy unread messages on a different machine every once in a while.

Chris, I might try and find some time to add some extra logging for you to try, since you see this regularly.
Sorry if this has been said already but this is a long discussion.  The unread count given on the Inbox is correct even when the count given on the Dock Icon is a factor of two too high.  Thus, it would seem all that is needed is to use the value from the Inbox on the Dock Icon.  It seem funny for there two be two sets of logic for this anyhow.

Just my 2c.
The problem, as best I can figure, is that the code to update the dock badge is somehow getting called twice when the unread total goes up. I've been unable so far to figure out what's causing that.

I can see that when new mail arrives the nsMessengerOSXIntegration:OnItemIntPropertyChanged() and subsequently BadgeDockIcon() is getting called twice, but I don't know why they're getting called a second time. The call stack is the same.

That's all for now.
When I first set up thunderbird 3 with gmail and my office mail account(IMAP) I experienced this issue. But it disappeard automatically. I have the correct count coming for a past week.

The only change I think I did was in gmail I unsubscribed from all IMAP folders(labels) and INBOX was the only one I have now. 
I also noted that when count was coming wrong , wrong count was from the gmail account.
I have two gmail accounts; one shows double the number of unread messages and the other one (almost?) always shows the correct count. I don't use smart folders.

I'd be happy to help a developer test or track down the bug if they're having difficulty reproducing the issue.
I don't see why it would matter if BadgeDockIcon is called twice because we count the unread messages from scratch. I'm going to try to add some logging that shows the unread counts we're adding up, and the uri's of the folders with the unread counts.
I've requested a try server build with a new pr log module, DockCounts - the try server build should appear here in a couple hours - http://tinderbox.mozilla.org/showbuilds.cgi?tree=ThunderbirdTry - this will be a 3.1b1 nightly build with logging added.

Instructions for generating a log are here - https://wiki.mozilla.org/MailNews:Logging

and again, the logging module is DockCounts - if you can recreate the bug with logging turned on, please attach the log here.
I just tried launching Shredder with and without the DockCounts module, but it crashed every time. The file is the crash log generated when I tried launching without logging (double-clicking app bundle).
yeah, crashes for me - I doubt it's my changes since my debug build works fine, but I'll try to figure it out.
Unfortunately I'm stuck with my PPC mac for a while longer, so I can't run the try build you setup - gives me a dialog about wrong architecture and that's it.

I'll try and rig up my own patched build here.
Chris, I thought we dropped support for the PPC a while ago :-) in any case, I'll let you try to patch your own builds, then. Please let me know what you see...
IIRC, we still support PPC on 10.5 even on trunk, and on 1.9.2 even on 10.4 - not sure if try does universal builds, though.
(In reply to comment #98)
> I have two gmail accounts; one shows double the number of unread messages and
> the other one (almost?) always shows the correct count. I don't use smart
> folders.

Gmail IMAP? Or Gmail POP3?
Gmail / Gmail IMAP adds both Gmail Label of "[Gmail]/All Mail" and "Inbox" to a newly arrived mail. As mail in different IMAP mail folders are different mails for IMAP client, "a new mail at Gmail" is "at least two new mails for Tb".
If you enable "Check this folder for new messages" of "[Gmail]/All Mail" or set mail.check_all_imap_folders_for_new=true, "double count for you" is normal phenomenon.

Arash, check folder properties of folders of Gmail IMAP account please, if you use Gmail IMAP.
FYI.
Bug 535523 is for Gmail IMAP specific "double count for you" issue.
(In reply to comment #107)
> Arash, check folder properties of folders of Gmail IMAP account please, if you
> use Gmail IMAP.

I use IMAP for all my mail, and I just verified that the [Gmail]/All Mail folder does _not_ have 'Check this folder for new messages' checked.

As for Bug 535523, I think it might good to mark that as a dup of this one. There doesn't seem to be any evidence so far that Gmail is causing the problem, because many of the people watching this bug (myself included) were using TB2 to check Gmail before this occurred.
Managed to get my own build working using the patch, but none of the added logging lines show up in the designated logging file (it gets written to for some other debug stuff, but not the added lines about the dock counts). I'll go back to trying to figure things out via the debugger, but if anyone has any ideas...
Chris, the logging should work, if you're only counting inbox unread messages (the default). I generated a log myself and it showed up. If you're running a debug build, you could add printfs and run from a shell, I suppose.
Here's a potential queue that may help you guys pin point the problem?

I am using a IMAP account (only one) with a lot of emails in it (over 15,000 all mark read except when I come in the morning). When I login in the morning the new message count on my dock icons is correct however since I am sync all my folders to be use offline on my laptop, I noticed that when all my message are done syncing then the count doubles on my dock icons.

Hopes this can help.

JF
I've requested a new try server build with logging, now that the separate trunk crasher has been fixed.

JF, how do you sync your folders for offline use? With file | offline | download and sync now? Or do you let the automatic sync do its thing?
I have selected under Tools -> Account settings -> Synchronization and storage -> "keep messages for this account on this computer" after having selected a bunch of folders in the advanced option. I also have selected "sync all messages regardless of age". I then let TB do its magic.

BTW (and probably unrelated) if I select "Enable Global Search and Indexer" in the preference menu, TB goes on a loop (100% CPU) so I have to disabled it to make this work.

Hope it answers your question.

JF
blocking-thunderbird3.1: needed → rc1+
David,

Help me out here. Where can I see #c101 info? Also what is this shredder apps suppose to do?

Thanks

JF
https://bugzilla.mozilla.org/show_bug.cgi?id=516477#c101

Shredder is just what we call the nightly builds for 3.1. I could generate a 3.03 try server build with this patch if that would be better for you (much closer to the shipping 3.0.3 build - however, the nightly builds are pretty stable since we're about to ship 3.1 beta 1 off of them)
OK. Just installed it and still showing twice the amount of unread email then I really have on the dock icon.

JF
JF, yes, there's no bug fix; there's just code to generate log info to help me diagnose what's going on. That being said, I have a log from dmose and I'm looking at that, so I may not need an other log, or I may need to enhance the logging.
OK let me know if I can help.

JF
I'm going to add some more logging and generate a new 3.1 beta2 pre build for folks to try.  dmose's log was a bit confusing; we are double counting all his servers, but I'm not sure if it's because we're calling InitReadCount() twice, or because the servers somehow are in the server array twice.
Attached patch more logging (obsolete) — Splinter Review
this adds more detail about the startup count calculation, and adds log info when the count is changed. I've also submitted a try server build request, so there should be a build in a couple hours - it will be a 3.1 b2 pre Shredder build. An other log from that build would be very helpful for me.
Attachment #428921 - Attachment is obsolete: true
After a bit of playing around, it appears that I am never actually seeing the duplicate message behavior in nightly builds, but I _am_ seeing it with the two try server builds that bienvenu has generated.
:Bienvenu
I used your try build and it shows that each of my account inboxes are being checked twice on startup.  It didn't seem to log much of interest besides that.

Here is a quick screencast showing my running it:
http://screencast.com/t/OWZiNzY4Mzct
:dmose
I do see what appears to be double counting in Lanikai 3.1b2pre.  The dock badge and folder badges look mostly the same as in the try build I just linked a screencast of above.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.2pre) Gecko/20100304 Lightning/1.0b2pre Lanikai/3.1b2pre
Interestingly, I don't see the double counting in that exact same build (yesterday's build), in the same profile.  I don't see it today's build in that profile either with all my extensions or with safe mode.
from the logs, we're getting into InitUnreadCount twice. I think it's highly unlikely that it's due to multi-threaded calls, and much more likely that it's a re-entrant call. I believe the calls to calculate the unread count are generating a propertychanged notification, which makes InitUnreadCount get called recursively. dmose's most recent log is consistent with this - we get the unread count for his first account, which seems to trigger counting all of his accounts, including the first, and when that's done, we count the remaining accounts. If it were multi-threading, I'd expect to see intermixing of the updates. This patch protects against re-entrant calls by moving the setting of mDoneInitialCount to right after where we check it. I've generated a try server build with this patch.
Attachment #430510 - Attachment is obsolete: true
Here's a try server build to try that may fix the issue.
Whiteboard: [has patch, waiting for dmose to try try server build]
Comment on attachment 430732 [details] [diff] [review]
logging with possible fix

the fix is fairly trivial, moving the re-entrancy guard to the top of the method. I'm ok with checking in the logging, or not...
Attachment #430732 - Flags: superreview?(dmose)
Attachment #430732 - Flags: review?(dmose)
Comment on attachment 430732 [details] [diff] [review]
logging with possible fix

ah, I see I forgot to get rid of the re-entrancy guard setting at the end of the method. I'll fix that locally.
Whiteboard: [has patch, waiting for dmose to try try server build] → [has patch for r/sr dmose]
Comment on attachment 430732 [details] [diff] [review]
logging with possible fix

You mean you'll remove the NS_ASSERTION at the end?  Why?

r+sr=dmose; leaving in the logging seems fine to me...
Attachment #430732 - Flags: superreview?(dmose)
Attachment #430732 - Flags: superreview+
Attachment #430732 - Flags: review?(dmose)
Attachment #430732 - Flags: review+
For completeness, it should be mentioned that bienvenu convinced me over IRC that the costs outweighed the benefits to requiring a test on this bug.
Whiteboard: [has patch for r/sr dmose] → [needs updated patch]
fix checked in (I removed the extra setting of mDoneInitialCount at the end of the method, since it's not needed anymore).
Status: NEW → RESOLVED
Closed: 15 years ago14 years ago
Resolution: --- → FIXED
Whiteboard: [needs updated patch]
Target Milestone: Thunderbird 3.1a1 → Thunderbird 3.1b2
Comment on attachment 430732 [details] [diff] [review]
logging with possible fix

should consider this for 3.0.04
Attachment #430732 - Flags: approval-thunderbird3.0.4?
Will this fix apply to SeaMonkey too?  (Just got a bad count this evening with SM 2.0.3)
Blocks: 551694
Comment on attachment 430732 [details] [diff] [review]
logging with possible fix

Unfortunately our branch tracking systems have issues with two patches on one bug landing in different versions of the stable branch.

I've therefore copied this patch out to bug 551694 and given it approval there for 3.0.4.

This means we can get it on the right bug lists for 3.0.4 and tracked for QA purposes.
Attachment #430732 - Flags: approval-thunderbird3.0.4? → approval-thunderbird3.0.4-
Whiteboard: [gs]
I'm running a 3.1b2pre nightly and still having this problem. I have a dockcounts log now too. Should I post here or start a new bug?
Blocks: 558661
A quick comment about bug 557960, referenced above in comment #137, which said it was Gmail-specific. That bug's summary has been updated to read as follows:

Bug 557960  - Doubled message counts in dock *after* startup when login name contains a "."  

My non-gmail account name indeed has a "." in it, and the latest 3.0.6 nightly indeed fixes the issue for me (thus far).

Perhaps some percentage of users experiencing this bug are in fact seeing bug 557960?
yes, I'm sure that's true...
You need to log in before you can comment on or make changes to this bug.