User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b4) Gecko/20090427 Fedora/3.5-0.20.beta4.fc11 Firefox/3.5b4 Build Identifier: 3.0b3pre using Fedora 11-release of 3.0b3pre Upon renaming inside Thunderbird foldernames appear with specialchars as they are stored on the IMAP-server ("Köln" is "K&APY-ln"). Reproducible: Always Actual Results: e.g. "Köln" is "K&APY-ln"
Do the names fix themselves when you restart?
Does the "K&APY-ln" appear at folder pane of Tb? Or you are talking local file name of "K&APY-ln" which is created/used by Tb? If former, Bug 450754 is already fixed by Tb 3.0b1... New problem upon rename which should be listed in Dependency tree for Bug 497199? What is date of the "Tb 3.0b3pre"? If latter, read thru Bug 450754, please.
Folders created before / using a different program show up okay. Folders created with the new thunderbird even appear broken after restart, so I assume they are created wrong on the IMAP-server (worked with TB 2.x). Current version shipped for Fedora 11 claims to be: thunderbird-3.0-2.4.b3pre.hg.6a6386c16e98.fc11.x86_64
Phenomenon was observed with 2009.6.21 build. > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090621 Shredder/3.0b3pre When K&APY-ln was displayed as folder name after rename, name in folder properties was K&APY-ln, but Köln was properly displayed in subscription list. After two consecutive "collapse/re-expand of IMAP account", Köln was displayed at folder pane. No restart was required. Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I see this.
Keywords: regression, regressionwindow-wanted
Summary: IMAP-foldernames with specialchars appear wrong → non-ascii IMAP-folder names appear wrong after rename
Target Milestone: --- → Thunderbird 3.0b3
taking - I'll try to reproduce this
Assignee: nobody → bienvenu
Status: NEW → ASSIGNED
yes, ok, we're not converting back from imap-mod utf7 on rename. We are doing it correctly on new folder creation, so this bug is a little less serious than I thought...
Created attachment 385435 [details] [diff] [review] trivial fix the new name is in imap mod-utf7, so convert it correctly to unicode. If I had to guess, I would guess this broke way early in the 3.0 process, probably when we got rid of nsFileSpec, or perhaps did some of the string reworking.
Comment on attachment 385435 [details] [diff] [review] trivial fix >- CopyASCIItoUTF16(newName, newNameString); >+ nsCString utf7LeafName; >+ rv = CopyMUTF7toUTF16(PromiseFlatCString(newName), newNameString); >+ NS_ENSURE_SUCCESS(rv, rv); You're not using utf7LeafName. r/sr=Standard8 with that removed. A unit test would be nice, but not needed for getting this patch in.
fix checked in, with nit addressed. Yes, a unit test of all of our imap mod utf7 handling would be a good thing.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.