Closed Bug 557960 Opened 10 years ago Closed 10 years ago

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

Categories

(Thunderbird :: OS Integration, defect, major)

x86
macOS
defect
Not set
major

Tracking

(thunderbird3.1 beta2-fixed, thunderbird3.0 .5-fixed)

RESOLVED FIXED
Tracking Status
thunderbird3.1 --- beta2-fixed
thunderbird3.0 --- .5-fixed

People

(Reporter: jhsieh, Assigned: Bienvenu)

References

()

Details

(Whiteboard: [gs])

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us) AppleWebKit/531.22.7 (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

Already discussed this with David :Bienvenu - OS X Dock count showing twice as many new messages. DockCounts debug shows new messages being counted twice

-1610005280[160b880]: changing unread to 1 aNewValue = 1 oldValue = 0 for folder imap://first%2Elast%40foo%2Ebar@baz.gorp.com/INBOX
-1610005280[160b880]: changing unread to 2 aNewValue = 1 oldValue = 0 for folder imap://first.last%40foo.bar@baz.gorp.com/INBOX

It appears escaped/unescaped "." may be causing double counting. David requested a new bug since this is not apparently related to 551694 and 516477

Reproduced with Shredder version 3.2alpha1

Reproducible: Always

Steps to Reproduce:
1. Create an account with login of first.last
2. Login and get some new emails
3. After about 10 minutes or so, dock counts will start showing double.
Actual Results:  
Dock counts eventually became 2x as many as it should have been.  

Expected Results:  
Dock counts should match new messages in Inbox
Version: unspecified → 3.0
Status: UNCONFIRMED → NEW
Ever confirmed: true
Duplicate of this bug: 558661
I was able to recreate this - bug I only saw the issue after I selected the inbox of the account with the .' in the user name, fwiw. I wonder if we're registering a second listener with an escaped username in the uri when the folder is selected.
Assignee: nobody → bienvenu
Status: NEW → ASSIGNED
While I was debugging this, it stopped happening. I don't know why that would be, but I wonder if running older versions of TB might trigger this again.
The issue does seem to take varying amounts of time to reoccur.  Sometimes, it happens within a couple of minutes.  Sometimes, over 20 minutes.  I was hypothesizing that it has something to do with user actions such as reading mail/switching folders/deleting messages to get the double counting to happen.  I haven't yet quite figured out what I do to make it happen....
Ah, I think I caught it in the act - here's a stack trace where we're opening the db for a folder with an escaped '.' in the user name in the uri. Opening the db adds a listener to the mail session, which I think causes the duplicate notification downstream.

#0	0x14ff45e1 in nsMsgDatabase::AddListener at nsMsgDatabase.cpp:669
#1	0x1513d446 in nsImapMailFolder::GetDatabase at nsImapMailFolder.cpp:666
#2	0x14d8db6c in nsMsgDBFolder::HasMsgOffline at nsMsgDBFolder.cpp:1219
#3	0x151a1934 in nsImapService::GetUrlForUri at nsImapService.cpp:304
#4	0x154d6a66 in mime_bridge_create_draft_stream at mimedrft.cpp:2086
#5	0x154d37e2 in bridge_create_stream at nsStreamConverter.cpp:99
#6	0x154d40d8 in nsStreamConverter::Init at nsStreamConverter.cpp:702
#7	0x154d1f18 in nsStreamConverter::AsyncConvertData at nsStreamConverter.cpp:1180
#8	0x14ef8473 in nsMsgComposeService::RunMessageThroughMimeDraft at nsMsgComposeService.cpp:1640
#9	0x14ef9338 in nsMsgComposeService::LoadDraftOrTemplate at nsMsgComposeService.cpp:1549
#10	0x14eff360 in nsMsgComposeService::OpenComposeWindow at nsMsgComposeService.cpp:576
Attached patch potential fix (obsolete) — Splinter Review
I'll kick off try server builds w/ this patch, after trying it out on the mac first.
Try server build with this fix should appear in a couple hours here - http://tinderbox.mozilla.org/showbuilds.cgi?tree=ThunderbirdTry
Thanks David. Will try it and report back ASAP.
David - I think you've nailed it.  I've been running since last night and the dock counts are still accurate.  DockCounts debug no longer shows any of that escaped "." instance occurring.  If you want the (rather uninteresting) DockCounts debug log, I can email it to you.

Appreciate you getting to the bottom of this little irritant.  Though, my division by 2 skills have definitely improved... ;)
Same results here. DockCounts log looks good also. Looks like the solution!
Attached patch fix comments, and request review (obsolete) — Splinter Review
If there's a better way to do the string stuff, Neil will know it...
Attachment #438604 - Attachment is obsolete: true
Attachment #438766 - Flags: superreview?(neil)
Attachment #438766 - Flags: review?(neil)
Comment on attachment 438766 [details] [diff] [review]
fix comments, and request review

>+      if (NS_SUCCEEDED(MsgUnescapeString(Substring(folderURI, 0, atPos),
>+                                         0, userName)))
>+      {
>+        // Re-escape the username, matching the way we do it in uri's, not the
>+        // way necko escapes urls. See nsMsgIncomingServer::GetServerURI.
>+        PRInt32 userNamePos = folderURI.Find("//") + 2;
>+        folderURI.Cut(userNamePos, atPos - userNamePos);
>+        userName.Cut(0, userNamePos);
>+        nsCString escapedUsername;
>+        MsgEscapeString(userName, nsINetUtil::ESCAPE_XALPHAS, escapedUsername);
>+        folderURI.Insert(escapedUsername, userNamePos);
I don't suppose it would be possible to reorder this e.g.
nsCString unescapedName, escapedName;
MsgUnescapeString(Substring(folderURI, userNamePos, atPos), 0, unescapedName);
MsgEscapeString(unescapedName, nsINetUtil::ESCAPE_XALPHAS, escapedName);
folderURI.Replace(userNamePos, atPos, escapedName);
That should be possible, yeah. I'll have a whack at it.
I think this is what you had in mind - I had to tweak it since it seems that the string api's want length, not end positions...
Attachment #438766 - Attachment is obsolete: true
Attachment #438911 - Flags: superreview?(neil)
Attachment #438911 - Flags: review?(neil)
Attachment #438766 - Flags: superreview?(neil)
Attachment #438766 - Flags: review?(neil)
(In reply to comment #15)
> I think this is what you had in mind - I had to tweak it since it seems that
> the string api's want length, not end positions...
Sorry about that, it was a late night ;-)
Comment on attachment 438911 [details] [diff] [review]
fix addressing comments

>+        // Re-escape the username, matching the way we do it in uri's, not the
>+        // way necko escapes urls. See nsMsgIncomingServer::GetServerURI.
uris (c.f. urls), not uri's ;-)
Attachment #438911 - Flags: superreview?(neil)
Attachment #438911 - Flags: superreview+
Attachment #438911 - Flags: review?(neil)
Attachment #438911 - Flags: review+
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Attachment #438911 - Flags: approval-thunderbird3.0.5?
Attachment #438911 - Flags: approval-thunderbird3.0.5? → approval-thunderbird3.0.5+
Duplicate of this bug: 561658
fixed for 3.0.5
Whiteboard: [gs]
You need to log in before you can comment on or make changes to this bug.