User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2 Build Identifier: version 3.0a1pre (2007122503) When creating a new folder on an IMAP account (not a local folder), the folder you created wont appear until the application has been closed, reopened, and the IMAP folders are refreshed. Reproducible: Always Steps to Reproduce: 1. Create new folder on IMAP Account Actual Results: Folder does not appear in list of folders until reopening thunderbird

Further to this, it appears that this will only happen the first time you create a folder on an IMAP account, will test again if this happens if you create another IMAP account on an existing profile now.

Confirmed that this only happens the first time you load any IMAP account into a profile. If you create an IMAP account in a profile, and before restarting thunderbird, create a new folder in the Inbox of that account, the folder does not appear until a restart of thunderbird. Restarting thunderbird will then fix this issue.

Reopening since bug 399769 turned out to be two separate issues.

Especially if the folder doesn't have a subfolder already it seems to be 100% reproducible.

Regression window for linux builds is: 2006-09-07 -> 2006-09-09 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=2006-09-07&maxdate=2006-09-09+04%3A00%3A00&cvsroot=%2Fcvsroot Nothing stands out to me:(

I can confirm, that this happens ALWAYS, when creating a folder that shall contain subfolders, when using an UW-IMAP-server. As little workaround: You don't have to restart T-Bird. Refreshing the folder tree by closing and expanding again makes the folder appear.

fix is in bug 434920.

Unfortunately bug 434920 didn't fix this, reopening. Str: create a folder "test", and a subfolder "test2" for it. There is no indication the subfolder test2 was created until collapse/expand. If there already is one subfolder sibling, the problem isn't there.

interesting - it's as if it doesn't realize that "test" has children. This also worked fine for me with one folder w/o children, but not for an other - and interestingly, that folder turned out have had children that had been deleted a couple days ago.

Even in the case where this doesn't work, we seem to be notifying rdf about the new folder. I'm really tempted to wait until jminta kicks rdf out of the folder pane and see if this goes away.

Still reproducible on trunk. I wonder if this is what also makes the Gmail (special Gmail/[...]) subfolders not available instantly on account creation...

This is WFM now. (Since the non-rdf folder pane perhaps?)