Closed
Bug 516477
Opened 15 years ago
Closed 14 years ago
Dock shows a double count of unread messages
Categories
(Thunderbird :: OS Integration, defect)
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)
2.58 KB,
patch
|
Details | Diff | Splinter Review | |
113.15 KB,
image/png
|
Details | |
1.38 KB,
text/plain
|
Details | |
421.01 KB,
text/plain
|
Details | |
2.72 KB,
patch
|
standard8
:
review+
standard8
:
superreview+
standard8
:
approval-thunderbird3.0.1+
|
Details | Diff | Splinter Review |
28.76 KB,
text/plain
|
Details | |
3.20 KB,
patch
|
dmosedale
:
review+
dmosedale
:
superreview+
standard8
:
approval-thunderbird3.0.4-
|
Details | Diff | Splinter Review |
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?
Assignee | ||
Comment 1•15 years ago
|
||
there was a bug where the dock number was counting messages in saved searches, but I thought that was fixed...
Reporter | ||
Comment 2•15 years ago
|
||
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.
Comment 3•15 years ago
|
||
I think this probably needs to block (but not b4)
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0rc1
Updated•15 years ago
|
Assignee: david.humphrey → nobody
Status: NEW → ASSIGNED
Component: Folder and Message Lists → OS Integration
QA Contact: folders-message-lists → os-integration
Updated•15 years ago
|
Assignee: nobody → david.humphrey
Updated•15 years ago
|
Whiteboard: [no l10n impact]
Comment 4•15 years ago
|
||
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.
Comment 7•15 years ago
|
||
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?
Comment 8•15 years ago
|
||
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.
Comment 9•15 years ago
|
||
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.
Comment 10•15 years ago
|
||
(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?
Comment 11•15 years ago
|
||
(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.
Comment 12•15 years ago
|
||
(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)
Comment 13•15 years ago
|
||
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.
Comment 14•15 years ago
|
||
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?
Comment 15•15 years ago
|
||
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.
Comment 16•15 years ago
|
||
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.
Comment 17•15 years ago
|
||
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.
Comment 18•15 years ago
|
||
This bug is stuck; adding qawanted in the hopes of getting steps to reproduce.
Keywords: qawanted
Comment 19•15 years ago
|
||
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?
Assignee | ||
Comment 20•15 years ago
|
||
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...
Comment 21•15 years ago
|
||
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.
Comment 22•15 years ago
|
||
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 23•15 years ago
|
||
TB build with this debug stuff is done: http://s3.mozillamessaging.com/build/try-server/2009-10-15_15:10-bugzilla@standard8.plus.com-humph-dock-debug/bugzilla@standard8.plus.com-humph-dock-debug-mail-try-mac.dmg Test away!
Comment 24•15 years ago
|
||
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.
Assignee | ||
Comment 25•15 years ago
|
||
couldn't you throw away all the counts you know about when you get the mail started notification, and recalculate them?
Comment 26•15 years ago
|
||
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?
Updated•15 years ago
|
Whiteboard: [no l10n impact] → [no l10n impact] [hopefully fixed by bug 501963; waiting for confirmation]
Comment 27•15 years ago
|
||
(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.
Comment 28•15 years ago
|
||
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!).
Updated•15 years ago
|
Whiteboard: [no l10n impact] [hopefully fixed by bug 501963; waiting for confirmation] → [no l10n impact][believed fixed by bug 501963]
Comment 29•15 years ago
|
||
David, try this one.
Attachment #406539 -
Attachment is obsolete: true
Attachment #410116 -
Flags: review?
Updated•15 years ago
|
Attachment #410116 -
Flags: review? → review?(david.ascher)
Comment 30•15 years ago
|
||
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.
Updated•15 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•15 years ago
|
Whiteboard: [no l10n impact][believed fixed by bug 501963] → [no l10n impact]
Comment 31•15 years ago
|
||
> 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?
Assignee | ||
Comment 32•15 years ago
|
||
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.
Assignee | ||
Comment 33•15 years ago
|
||
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.
Comment 34•15 years ago
|
||
your wish is my command
Assignee | ||
Comment 35•15 years ago
|
||
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.
Assignee | ||
Comment 36•15 years ago
|
||
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.
Comment 37•15 years ago
|
||
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-
Comment 38•15 years ago
|
||
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).
Comment 39•15 years ago
|
||
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.
Assignee | ||
Comment 40•15 years ago
|
||
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)
Comment 41•15 years ago
|
||
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.
Assignee | ||
Comment 42•15 years ago
|
||
We know this isn't and won't be completely fixed in 3.0.
Comment 43•15 years ago
|
||
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.
Updated•15 years ago
|
Attachment #414172 -
Attachment mime type: application/octet-stream → text/plain
Comment 45•15 years ago
|
||
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 46•15 years ago
|
||
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-
Updated•15 years ago
|
Assignee: david.humphrey → bienvenu
status-thunderbird3.0:
--- → wanted
Whiteboard: [no l10n impact]
Target Milestone: Thunderbird 3.0rc1 → ---
Assignee | ||
Comment 47•15 years ago
|
||
ok, this gets rid of the duplicate checks...
Attachment #410543 -
Attachment is obsolete: true
Attachment #415252 -
Flags: superreview?(bugzilla)
Attachment #415252 -
Flags: review?(bugzilla)
Comment 48•15 years ago
|
||
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.
Assignee | ||
Comment 49•15 years ago
|
||
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 50•15 years ago
|
||
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?
Comment 51•15 years ago
|
||
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.
Assignee | ||
Comment 52•15 years ago
|
||
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 ago → 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Target Milestone: --- → Thunderbird 3.1a1
Comment 53•15 years ago
|
||
(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).
Comment 55•15 years ago
|
||
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.
Comment 56•15 years ago
|
||
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.
Assignee | ||
Comment 57•15 years ago
|
||
Yes, this fix won't in a release until 3.1, or maybe 3.01
Comment 58•15 years ago
|
||
Unfortunately, I'm still seeing this issue in the 3.0.1pre nightly. Bummer.
Comment 59•14 years ago
|
||
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+
Comment 60•14 years ago
|
||
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.
Comment 61•14 years ago
|
||
Checked into branch: http://hg.mozilla.org/releases/comm-1.9.1/rev/cc5310dc7ef2 This should be in 3.0.1pre builds from tomorrow.
Comment 64•14 years ago
|
||
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...
Comment 65•14 years ago
|
||
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
Keywords: qawanted → verified-thunderbird3.0
Comment 67•14 years ago
|
||
This problem still exists in 3.0.1 - took longer than before to occur though - approx half a day of use.
Comment 68•14 years ago
|
||
I also still have this problem on Thunderbird, although I am not using smart folders view.
Comment 69•14 years ago
|
||
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.
Comment 70•14 years ago
|
||
(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" ?
Comment 71•14 years ago
|
||
(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.
Comment 72•14 years ago
|
||
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.
Updated•14 years ago
|
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 74•14 years ago
|
||
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.
Comment 75•14 years ago
|
||
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
Comment 77•14 years ago
|
||
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.
Comment 78•14 years ago
|
||
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.
Comment 79•14 years ago
|
||
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?
Assignee | ||
Comment 80•14 years ago
|
||
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?
Comment 81•14 years ago
|
||
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?
Assignee | ||
Comment 82•14 years ago
|
||
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.
Assignee | ||
Comment 83•14 years ago
|
||
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.
Comment 84•14 years ago
|
||
: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.
Comment 85•14 years ago
|
||
> 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.
Comment 86•14 years ago
|
||
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.
Comment 87•14 years ago
|
||
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.
Assignee | ||
Comment 88•14 years ago
|
||
Marianne, do you know what kind of imap server? Is it Zimbra, perhaps?
Comment 89•14 years ago
|
||
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
Comment 90•14 years ago
|
||
@David :Bienvenu : not Zimbra, MS Exchange
Assignee | ||
Comment 91•14 years ago
|
||
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
Comment 92•14 years ago
|
||
(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.
Assignee | ||
Comment 93•14 years ago
|
||
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.
Assignee | ||
Comment 94•14 years ago
|
||
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.
Comment 95•14 years ago
|
||
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.
Comment 96•14 years ago
|
||
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.
Comment 97•14 years ago
|
||
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.
Comment 98•14 years ago
|
||
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.
Assignee | ||
Comment 99•14 years ago
|
||
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.
Assignee | ||
Comment 100•14 years ago
|
||
Assignee | ||
Comment 101•14 years ago
|
||
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.
Comment 102•14 years ago
|
||
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).
Assignee | ||
Comment 103•14 years ago
|
||
yeah, crashes for me - I doubt it's my changes since my debug build works fine, but I'll try to figure it out.
Comment 104•14 years ago
|
||
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.
Assignee | ||
Comment 105•14 years ago
|
||
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...
Comment 106•14 years ago
|
||
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.
Comment 107•14 years ago
|
||
(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.
Comment 108•14 years ago
|
||
FYI. Bug 535523 is for Gmail IMAP specific "double count for you" issue.
Comment 109•14 years ago
|
||
(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.
Comment 110•14 years ago
|
||
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...
Assignee | ||
Comment 111•14 years ago
|
||
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.
Comment 112•14 years ago
|
||
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
Assignee | ||
Comment 113•14 years ago
|
||
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?
Comment 114•14 years ago
|
||
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
Updated•14 years ago
|
blocking-thunderbird3.1: needed → rc1+
Assignee | ||
Comment 115•14 years ago
|
||
3.1 build with logging here - http://s3.mozillamessaging.com/build/try-server/2010-03-03_12:50-bienvenu@nventure.com-1267649385/bienvenu@nventure.com-1267649385-mail-try-mac.dmg - see #c101 for info about generating a log.
Comment 116•14 years ago
|
||
David, Help me out here. Where can I see #c101 info? Also what is this shredder apps suppose to do? Thanks JF
Assignee | ||
Comment 117•14 years ago
|
||
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)
Comment 118•14 years ago
|
||
OK. Just installed it and still showing twice the amount of unread email then I really have on the dock icon. JF
Assignee | ||
Comment 119•14 years ago
|
||
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.
Comment 120•14 years ago
|
||
OK let me know if I can help. JF
Assignee | ||
Comment 121•14 years ago
|
||
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.
Assignee | ||
Comment 122•14 years ago
|
||
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
Comment 123•14 years ago
|
||
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.
Comment 124•14 years ago
|
||
: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
Comment 125•14 years ago
|
||
: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
Comment 126•14 years ago
|
||
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.
Assignee | ||
Comment 127•14 years ago
|
||
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
Assignee | ||
Comment 128•14 years ago
|
||
Here's a try server build to try that may fix the issue.
Assignee | ||
Updated•14 years ago
|
Whiteboard: [has patch, waiting for dmose to try try server build]
Assignee | ||
Comment 129•14 years ago
|
||
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)
Assignee | ||
Comment 130•14 years ago
|
||
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.
Assignee | ||
Updated•14 years ago
|
Whiteboard: [has patch, waiting for dmose to try try server build] → [has patch for r/sr dmose]
Comment 131•14 years ago
|
||
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+
Comment 132•14 years ago
|
||
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]
Assignee | ||
Comment 133•14 years ago
|
||
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 ago → 14 years ago
Resolution: --- → FIXED
Whiteboard: [needs updated patch]
Target Milestone: Thunderbird 3.1a1 → Thunderbird 3.1b2
Assignee | ||
Comment 134•14 years ago
|
||
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?
Updated•14 years ago
|
status-thunderbird3.1:
--- → beta2-fixed
Comment 135•14 years ago
|
||
Will this fix apply to SeaMonkey too? (Just got a bad count this evening with SM 2.0.3)
Comment 136•14 years ago
|
||
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-
Updated•14 years ago
|
Whiteboard: [gs]
Comment 137•14 years ago
|
||
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?
Comment 138•14 years ago
|
||
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?
Assignee | ||
Comment 139•14 years ago
|
||
yes, I'm sure that's true...
You need to log in
before you can comment on or make changes to this bug.
Description
•