Closed Bug 259656 Opened 20 years ago Closed 20 years ago

Moving multiple msg from IMAP Sent items folder to Local folder doesn't work

Categories

(MailNews Core :: Networking: IMAP, defect)

1.7 Branch
x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: info, Assigned: Bienvenu)

References

Details

(Keywords: testcase)

Attachments

(4 files, 1 obsolete file)

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; (R1 1.3); .NET CLR 1.0.3705; .NET CLR 1.1.4322) Build Identifier: Moving one message from the Sent Items folder of an IMAP account works fine. But selecting two or more and you can't move (or copy) them to a local mail folder Reproducible: Always Steps to Reproduce: 1. 2. 3.
Rob, can you try generating an imap protocol log with tomorrow's nightly trunk thunderbird build? http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap I've added some more logging to help diagnose this.
Assignee: mscott → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Rob, can you try generating an imap protocol log with tomorrow's nightly trunk thunderbird build? http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap I've added some more logging to help diagnose this.
Attached file Multiple Sent Item Move Attempt (Log) (obsolete) —
I have attached a log detailing what happens when multiple 'Sent' items are selected and a move attempt made into a local subfolder. (Refer to 'Multiple Sent Item Move Attempt (Log)')
Comment on attachment 177862 [details] Multiple Sent Item Move Attempt (Log) Build tag: 20050317
this looks like yet another case where a user name with non alphanumeric characters is causing the problem. I'll try that angle again.
(In reply to comment #6) > this looks like yet another case where a user name with non alphanumeric > characters is causing the problem. I'll try that angle again. In the meantime, I'll try an IMAP account without special characters.
I don't suppose you could set me up with a test account that has this problem, with a user name similar to yours? My imap server doesn't allow non alpha-numeric user names.
(In reply to comment #8) > I don't suppose you could set me up with a test account that has this problem, > with a user name similar to yours? My imap server doesn't allow non > alpha-numeric user names. I created an account @ Fastmail that I'm able to reproduce the problem with. I emailed you the details.
Attached patch more loggingSplinter Review
resurrect the "validUrl" flag from 4.x - my theory is that maybe we're having trouble parsing the url because of the user name. If we fail to parse the url, we won't set the imap action, and we won't do anything in ProcessCurrentUrl...this won't fix the problem, but might help diagnose it.
Attachment #177907 - Flags: superreview?(mscott)
Attachment #177907 - Flags: superreview?(mscott) → superreview+
I can't reproduce this problem on my home machine with 1.0 (20041206) loaded (same IMAP account, etc.) Will try: 1. Newer build 2. Same prefs.js as laptop 3. Banging head on wall
Ok, here's my steps to reproduce: 1. Start Thunderbird 2. Add IMAP account (go through wizard) with username with a \ (hex: EC) character present. 3. Retrieve Inbox/Sent item headers - Verify that dragging multiple messages works fine. 4. Alter account to use / (hex: 2F) instead of \ (hex: EC) character. NOTE: Exchange is not that sensitive on slash usage, it appears. 5. Retrieve Inbox/Sent item headers (re-input password). 6. Try dragging multiple messages from 'Sent' folder to local folders. Problem reproduced. --- I will try compiling Thunderbird using the latest nightly tar w/ the proposed patch applied and provide feedback. Thanks.
Adding Rafael as QA contact, since he wants to help resolve this issue.
QA Contact: r.rivera
Attached new log with a snip of: a) Opening of the 'Test Msgs' folder in the said FastMail account b) Attempt of moving three messages within' this folder to local folder (should show near bottom but nothing happens) Attempts in compiling w/ proposed patch (which applies successfully) failed (I'm a compile newbie) - Will bring up imapd and/or Exchange server for David to conduct more testing.
was this new log from a new trunk build, with a litle extra bit of logging?
The log was from version 1.0+ (20050317).
oh, could you try a 03/19 build? I checked in some more logging code on 03/18, which would show up in the 03/19 build...
Added log snip from version 1.0+ (20050321).
Attachment #177862 - Attachment is obsolete: true
OK, I can reproduce this now, so I should have a fix, I hope by tomorrow. Thx so much for the test case!
(In reply to comment #19) > OK, I can reproduce this now, so I should have a fix, I hope by tomorrow. Thx so > much for the test case! Great - What was the root of the problem, if you don't mind me asking?
Keywords: testcase
OK, the problem has to do with the user name in the uri getting escaped. When we get to GetMessage in nsCopyMessageStreamListener, the escaped username prevents us from finding the msg hdr, and this in turn causes nsCopyMessageStreamListener::OnStartRequest to return an error. This in turn cancels the request, so that we get DeathSignalReceived in the imap protocol code. It's not clear to me that failure to get the header should abort the url, but I have a fix that will allow us to get the header - passing in a uri for the first msg hdr in nsImapService::CopyMessages + mData 0x04e2dce8 "imap-message://bug_259656%40fastmail.us@mail.messagingengine.com/INBOX/Test Msgs#16" + mData 0x050cc380 "imap-message://bug_259656%40fastmail%2Eus@mail.messagingengine.com/INBOX/Test Msgs#16" // user name not escaped with this stack trace, because uri comes from aSrcMailboxUri nsImapUrl::SetUri(nsImapUrl * const 0x092e4954, const char * 0x0915ea88) line 1269 nsImapService::CreateStartOfImapUrl(const char * 0x0915ea88, nsIImapUrl * * 0x0012b394, nsIMsgFolder * 0x039698c8, nsIUrlListener * 0x00000000, nsCString & {...}, unsigned short & 0x002e) line 1225 nsImapService::CopyMessage(nsImapService * const 0x0384104c, const char * 0x0915ea88, nsIStreamListener * 0x04f45b90, int 0x00000000, nsIUrlListener * 0x00000000, nsIMsgWindow * 0x0381f820, nsIURI * * 0x00000000) line 753 + 69 bytes nsMsgLocalMailFolder::CopyMessageTo(nsISupports * 0x08d1ce30, nsIMsgFolder * 0x039318f0, nsIMsgWindow * 0x0381f820, int 0x00000000) line 2853 nsMsgLocalMailFolder::CopyMessages(nsMsgLocalMailFolder * const 0x039318f0, nsIMsgFolder * 0x039698c8, nsISupportsArray * 0x08c5d438, int 0x00000000, nsIMsgWindow * 0x0381f820, nsIMsgCopyServiceListener * 0x00000000, int 0x00000000, int 0x00000001) line 1776 + 69 bytes // failure case, uri is escaped, because CopyMessages doesn't pass in a uri to CreateStartOfImapUrl nsImapUrl::SetUri(nsImapUrl * const 0x09274654, const char * 0x00000000) line 1269 nsImapService::CreateStartOfImapUrl(const char * 0x00000000, nsIImapUrl * * 0x0012b350, nsIMsgFolder * 0x039698c8, nsIUrlListener * 0x00000000, nsCString & {...}, unsigned short & 0x002e) line 1225 nsImapService::CopyMessages(nsImapService * const 0x0384104c, nsMsgKeyArray * 0x0012b488, nsIMsgFolder * 0x039698c8, nsIStreamListener * 0x09111908, int 0x00000000, nsIUrlListener * 0x00000000, nsIMsgWindow * 0x0381f820, nsIURI * * 0x00000000) line 796 + 67 bytes nsMsgLocalMailFolder::CopyMessagesTo(nsISupportsArray * 0x091f2490, nsIMsgWindow * 0x0381f820, nsIMsgFolder * 0x039318f0, int 0x00000000) line 2804 nsMsgLocalMailFolder::CopyMessages(nsMsgLocalMailFolder * const 0x039318f0, nsIMsgFolder * 0x039698c8, nsISupportsArray * 0x091f2490, int 0x00000000, nsIMsgWindow * 0x0381f820, nsIMsgCopyServiceListener * 0x00000000, int 0x00000000, int 0x00000001) line 1763 + 75 bytes
Status: NEW → ASSIGNED
Attached patch proposed fixSplinter Review
as described in previous comment, pass in the uri for the first message to CreateStartOfImapUrl, so that GetUri will return a uri with an escaped user name.
Attachment #178253 - Flags: superreview?(mscott)
thx very much to Rafael for the test case - the fix should be in tomorrow's (3/23) build.
Attachment #178253 - Flags: superreview?(mscott) → superreview+
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Component: Mail Window Front End → Networking: IMAP
Product: Thunderbird → Core
Version: unspecified → Trunk
Comment on attachment 178253 [details] [diff] [review] proposed fix this is a much-duplicated bug and the fix is localized to the case of copying multiple imap messages.
Attachment #178253 - Flags: approval1.7.7?
*** Bug 267927 has been marked as a duplicate of this bug. ***
Comment on attachment 178253 [details] [diff] [review] proposed fix a=sspitzer, thanks david!
Attachment #178253 - Flags: approval1.7.7? → approval1.7.7+
Doesn't this also need to land for aviary 1.0.3?
*** Bug 244530 has been marked as a duplicate of this bug. ***
*** Bug 275836 has been marked as a duplicate of this bug. ***
*** Bug 254505 has been marked as a duplicate of this bug. ***
*** Bug 242424 has been marked as a duplicate of this bug. ***
*** Bug 261978 has been marked as a duplicate of this bug. ***
Comment on attachment 178253 [details] [diff] [review] proposed fix resetting approval flag to requested. drivers need to re-evaluate in the context of upcoming security releases.
Attachment #178253 - Flags: approval1.7.7+ → approval1.7.7?
Verified working in nightly aviary (20050323). Thanks.
Component: Networking: IMAP → Mail Window Front End
Product: Core → Thunderbird
Version: Trunk → 1.0
Component: Mail Window Front End → Networking: IMAP
Product: Thunderbird → Core
Version: 1.0 → 1.7 Branch
Comment on attachment 178253 [details] [diff] [review] proposed fix this might be good for the 1.7 branch
Attachment #178253 - Flags: approval1.7.9?
*** Bug 297161 has been marked as a duplicate of this bug. ***
*** Bug 298899 has been marked as a duplicate of this bug. ***
Comment on attachment 178253 [details] [diff] [review] proposed fix 1.7.9 has already shipped. unsetting nomination.
Attachment #178253 - Flags: approval1.7.9?
*** Bug 304157 has been marked as a duplicate of this bug. ***
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: