Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090105 Shredder/3.0b2pre Actually, it might be more appropriate to describe it as not finding new subfolders below the first level between reboots when the mail client is set to not require subscribed subfolders. However I have a workaround. To reproduce: 1) On two systems (client1 and client2) login to an IMAP account so they have a current list of IMAP folders, and log out. Both should be set to not require subscribed folders. 2) create on IMAP client 1 a new folder below the 1st level (e.g. root\Parent\Child). 3) On IMAP client2, login to the same account. Expected behavior: 4) Client 2 should now have a subfolder expander twisty on Parent, and expanding should show "Child". Actual behavior: 4) Client 2 does not show the twisty on Parent, and can't see the new folder Child. Workaround: Setting client to require subscribed folders, quitting, logging in, then setting to not use subscribed folders, quitting, and then logging in again shows all folders missing.

You can also collapse and expand one folder up, and it will refresh the list for that folder. I'm guessing this was a performance decision -- getting a full list of folders each time TB connects to the server could get expensive if the account has lots of folders, especially since the folder list probably doesn't change all that often for most people.

Actually, that no longer works with TB3; I assumed that was a design decision as they appear to do a full server lookup for folders at startup (looking at the IMAP logs), even though quitting and restarting does not help this particular bug. This is what I used to do with TB2. Should TB3 also refresh folder listings when the parent folder is collapse/expanded? If not, I should probably list another bug for that.

TB 3 should refresh child folder listings when parent is expanded - that was lost with the new js-driven folder pane and needs to be fixed, so a new bug would be good (or we can just use this bug - I believe that's basically the issue with this bug)

wanted+ - the fix is to call perform expand on the folder that's opened.

I'm seeing an issue that is very like both this, and #369964. I can't decide which is more appropriate. Maybe neither. I have gone so far as to delete my profile, keeping only prefs.js, and this is what I'm seeing (courier imapd 4.4.1, btw): The subscription dialog does not display folders deeper than two levels. Folder list does not display more than two levels deep. ex: INBOX.Lists.Tech where there are many folders and subfolders beneath Tech. When emptying my profile, I noticed an odd behavior when the new ImapMail folder was created. Previously where I had a "servername" directory with .msf files and .sbd folders, I now had a "servername" and "servername.sbd". The "servername" folder contains only "INBOX.sbd\Archives.msf" and msgRules. All other msf files go into the "servername.sbd" directory. Maybe it's a conglomeration of both of these bugs? It definitely appears that the folder list is not being refreshed when hitting spinners, but the full folderlist does not appear when using the subscription dialog, either. The symptoms I'm seeing are definitely a blocking bug.

Actually, the deeper I dig, the more my issue looks like a regression of #219498 - Shredder is issuing: list "" "INBOX.%.%" but never a: list "" "INBOX.%.%.*"

The way this used to work before the new js folder pane was that expanding a collapsed level in the hierarchy would issue a two-level deep list of that folder's children. It looks like the new js folder pane doesn't do this. It only affects the non-imap subscription case. I will try to resurrect the code that did this.

this is what the old folder pane did: http://mxr.mozilla.org/mozilla/source/mail/base/content/msgMail3PaneWindow.js#381 so I'm just restoring that.

Comment on attachment 364526 [details] [diff] [review] restore old behavior It's unfortunate that the front-end has to know so many details about the back-end impl.

actually, it's unfortunate that the backend has to know what's happening in the front end :-) it's really just a notification.

it's also unfortunate that we need imap-specific notifications - fix checked in