399769 - imap folders do not refresh to show new name after rename

Status: RESOLVED DUPLICATE of bug 434920

(MailNews Core :: Networking: IMAP, defect)

Description

[Magnus Melin [:mkmelin]]

If I rename an imap folder, the new name do not show up in the folder tree immediately. The rename itself seems ok, but the tree needs to refresh itself afterwards. Local folders work fine.

Trunk only, but not a very recent regression, I'd guess 1-2 months back. Maybe more. Seen both on tb and sm.

Comment 1

[Magnus Melin [:mkmelin]]

It also doesn't refresh after adding a subfolder. I guess it's the same problem.

Comment 2

[Rajasekhar]

Hi raja

Comment 3

[Rajasekhar]

eatretrw3rtywe

Comment 4

[Magnus Melin [:mkmelin]]

This bugzilla isn't for testing!! Use http://landfill.bugzilla.org/

Comment 6

[Magnus Melin [:mkmelin]]

For the subfolder creation it just happens sometimes for me - especially if the folder doesn't have a subfolder already it seems to be quite reproducible.

Comment 8

[Greg K.]

This a Core bug why?

Comment 9

[Magnus Melin [:mkmelin]]

Why wouldn't it be? SeaMonkey has the exact same problem.

Comment 10

[Magnus Melin [:mkmelin]]

Turns out these are two separate issues. Updating summary and reopening bug 409839 for the subfolder issue.

For the rename, regression window on linux is 2007-05-09 -> 2007-05-11. 2007-05-10 was seriously busted, couldn't show the imap folder listing after a refresh - think it didn't work but I'm not sure. (Also left the profile in a bad state.)

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=ThunderbirdTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-05-09+03%3A00%3A00&maxdate=2007-05-10+04%3A00%3A00&cvsroot=%2Fcvsroot

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=ThunderbirdTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-05-09+03%3A00%3A00&maxdate=2007-05-11+04%3A00%3A00&cvsroot=%2Fcvsroot

Would seem likely caused by bug 379070, possibly bug 380308.

Comment 11

[Greg K.]

Did you perhaps mean to reopen my bug 413453, which is about subfolders (rather than 409839, which is not)?

Comment 12

[WADA:World Anti-bad-Duping Agency]

To Magnus Melin(bug opener):  UW-IMAP-server? (See Bug 419780)

Comment 13

[Magnus Melin [:mkmelin]]

No, happens e.g. with gmail imap as well.

Comment 14

[WADA:World Anti-bad-Duping Agency]

Can you get IMAP protocol log and compare it with log by Bug 419780?

Comment 15

[WADA:World Anti-bad-Duping Agency]

To Magnus:
I got Gmail account yesterday, so you needn't get log with Gmail IMAP.

I could observe phenomena by myself. (Tb trunk 2008/2/29 & Semonkey 1.1.8)
 - Create [Gmail]/Sub => Immediately appeared in folder pane(no problem)
 - Create [Gmail]/Sub/Sub_Sub => problem is re-produced
 - Create [Gmail]/Sub/Sub_Sub/Sub_Sub_Sub => problem is re-produced
 - Rename [Gmail]/Sub to [Gmail]/Sub_Renamed => problem is re-produced
In any case, "folding of Gmail IMAP account then expand again" was simplest & effective workaround.
This is similar procedure to know change on subfolder by other user.
 (1) Access Gmail IMAP folders using Seamonkey.
 (2) Access same Gmail IMAP folders using Thunderbird while Seamonkey is using
 (3) Action of create/rename/delete etc. on subfolder by Thunderbird
 (4) Access Gmail IMAP folders by Seamonkey
     => created/renamed(new) subfolder won't appear automatically
     => access to renamed(old)/deleted subfolder fails due to unknown folder
 (5) Fold Gmail IMAP account then expand again by Seamonkey
     => Change by Thunderbird is recognized by Seamonkey

Comment 16

[WADA:World Anti-bad-Duping Agency]

FYI.
Folder hierarchy in Gmail IMAP is label in Gmail, and label of Gmail has length limitation. For example, when "[Gmail]/Sub_Renamed_2/Sub_Sub_Renamed",  only 3 bytes can be addded to the label. So subfolder name larger than 2 bytes can not be created via Gmail IMAP. Please be careful in testing with Gmail IMAP.  
> Maximum length of label : [Gmail]/Sub_Renamed_2/Sub_Sub_Renamed/12

Comment 17

[WADA:World Anti-bad-Duping Agency]

Attachment: IMAP log (Gmail IMAP, Tb trunk)

IMAP log of following test.
1. Start Tb(trunk 2008/2/29 build)
2. Create(New Folder) Test_1 (root level, same level as Inbox or [Gmail])
   => Test_1 automatically appeared at folder pane
3. Click Test_1, and create(New Subfolder) X1, X2, X3 under Test_1
   => Didn't appear
4. Fold Test_1, and expand Test_1 again => X1, X2, X3 appeared
5. Left click Test_1/X1, delete Text_1/X1 from context menu
   => Disappeared automatically
6. Delete Text_1/X2 from context menu (no left click)
   => X2 still remained
7. Left click Test_1/X3, rename to X3_Renamed
   => X3 still remained, X3_Renamed didn't appear
8. Left click Test_1/X2 and Test_1/X3
   => Error because X2 and X3 is unknown folder
9. Fold Test_1, and expand Test_1 again => X2, X3 still remained
10. Fold Gmail account, and expand account again
    => X2 and X3 disappeared, and X3_Renamed appeared

At any step of create/delete/rename, subscribe and/or unsubscribe is properly issued.
When create of Test_1(created Test_1 automatically appeared), "list Test_1" is issued. But when create X1/X2/X3(and X3_Renamed), "list" just after create(+subscribe) or rename(+unsubscribe+subscribe) is not issued.

No IMAP protocol level issue(incorrect sequence etc.) is not seen (from point of IMAP server view). Problems seem to be said as follows.
 (Problem-1) When create of subfolder, folder pane is not updated
 (Problem-2) When delete without open of folder, folder pane is not updated
 (Problem-3) rename == delete + create (from point of folder view)
             Rename case looks to be combination of Problem-2 & Problem-1

Comment 18

[David :Bienvenu]

searched for but didn't find this bug - fix is in bug 434920