Closed Bug 259656 Opened 20 years ago Closed 19 years ago

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

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Version:
1.7 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: info, Assigned: Bienvenu)

References

Details

(Keywords: testcase)

Attachments

(4 files, 1 obsolete file)

more logging
3.41 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
FastMail Acct. Multiple Move Attempt (Log)
4.32 KB, text/plain
Details
Multiple Sent Item Move Attempt #2 (20050321)
2.10 KB, text/plain
Details
proposed fix
1.42 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review 
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 logging
        — 
          — Splinter 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 fix
        — 
          — Splinter 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: 19 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: