User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050206 Minefield/3.0pre
Build Identifier: Thunderbird version 3.0a1pre (2008050303)
You need to have folder with cyrillic letters in it. If you use Gmail on cyrillic language, it is there by default, like: Сва пошта. Then you need to uncheck to check new messages on startup for this account.
In that case, on starting Thunderbird this folder is labeled &BC... pretty long nonsense string. After Thunderbird refreshes IMAP Account (like after clicking on it), everything is updated and fine.
Steps to Reproduce:
Similar phenomenon can be observed on INBOX & Inbox with Gmail IMAP, with trunk.
(0) Label of Gmail Web : Inbox
(1) msf file name under ImapMail directory : INBOX.msf
(2) folder name in Subscribe : INBOX
(3) folder name in folder pane : INBOX (after restart of Tb)
(4) folder name in folder pane : Inbox (after folder click==open)
When Tb 184.108.40.206, (1)/(2)/(4) is same, but folder name is displayed as "Inbox" even after restart, at (3).
"&BC... pretty long nonsense string" is probably file name for msf.
Check Properties/General Information/Location of the folder.
Confirmed with Tb trunk 2008/5/02 build on MS Win/XP SP2, with Japanese lable name of Gmail Web(==folder name of Gmail IMAP).
- labels : Mbox/abc_1, Mbox/abc_2, ... Mbox/<Japanese_label_name>
(subfolder of abc_1, abc_2, ... <Japanese_label_name> under Mbox folder)
- After restart of Tb, file name for <Japanese_label_name> is displayed.
(looks to be modified UTF-7 defined in RFC 3501 )
( http://www.faqs.org/rfcs/rfc3501.html )
( 5.1.3. Mailbox International Naming Convention )
- When other mail box such as abc_1 under Mbox is clicked,
<Japanese_label_name> is displayed properly.
I don't think Gmail IMAP unique issue, but set dependency to meta Bug 402793 for ease of tracking.
> "&BC... pretty long nonsense string" is probably file name for msf.
> Check Properties/General Information/Location of the folder.
Yes, it is the name of the folder
I used Tb trunk(Version=3.0a2pre,BuildID=2008052203. Bug 434920 has been fixed) today for fix verification test of other bug, using same profile used by test in Comment #2. After it, I couln't reproduce this bug's problem anymore, with Gmail Imap, Japanese mail folder name, using same profile, even with old Tb trunk 2008/5/02 build.
To Ivan Icin(bug opener):
Ca you re-produce problem with latest Tb trunk nightly?
Well, I can see it for a split of second, but it doesn't require user action to get normal names, so I guess it is OK.
Problem still remains, and regression range was discovered by Bug 450754.
Closing as DUP of Bug 450754, for ease of follow-up.
*** This bug has been marked as a duplicate of bug 450754 ***