Closed
Bug 390127
Opened 17 years ago
Closed 17 years ago
Non-ASCII characters in profile names are saved incorrectly; also in file:// listings; in builds since 2007062904, 0724, and 0725 (UTF-8 and UTF-16 problems). {Chinese, Cyrillics, Greek, Russian, German, umlauts, letters}
Categories
(Toolkit :: Crash Reporting, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: Aleksej, Assigned: ted)
References
(Depends on 1 open bug)
Details
(Keywords: intl)
Attachments
(1 file)
7.91 KB,
patch
|
benjamin
:
review+
benjamin
:
approval1.9+
|
Details | Diff | Splinter Review |
Debian GNU/Linux Lenny, LANG=en_GB.UTF-8.
Happens in Firefox, Thunderbird, Seamonkey trunk nightly builds from 20070729.
StR:
1. Create a profile with a non-ASCII character like “α”, “ü”, or “а” in its name (in this case, single characters were used).
...if you start Firefox with that profile now, the interface would look incorrectly.
2. Look at the profile's directory on disk and into profiles.ini
Expected results:
The character in UTF-8 in the directory name, Name, and Path variables in profiles.ini.
Actual Results (Minefield 2007072904)
When creating the profile from GUI:
PM: α (03b1) | ü (00fc) | а (0430)
IniName ceb1 (03b1) | c3bc (00fc) | b0d0 (0430) | CORRECT
Disk: b1 | fc | 30
IniPath c2b1 (00b1) | c3bc (00fc) | 30 (0030)
The most significant byte from the UTF-16 representation is lost, the rest is used in the directory name on disk, and 00+rest is converted from UTF-16 into UTF-8 and used in the Path variable in profiles.ini.
CLI
CL: α (03b1)
IniName ceb1 (03b1) | CORRECT
Disk: ceb1 (03b1) | CORRECT
IniPath c38ec2b1 (ce00b100)
The UTF-8 representation of the character gets 00s added to its bytes, and that is used in the Path variable in profiles.ini.
Regression ranges:
http://tinyurl.com/32osb2
Minefield:
2007062804(?) - WFM
2007062904 - happens
http://tinyurl.com/26qvjz
Thunderbird
2007072303 - WFM
2007072403 - happens
http://tinyurl.com/3cffoy
Seamonkey:
2007072402 - WFM
2007072501 - happens
Reporter | ||
Updated•17 years ago
|
Summary: Non-ASCII characters in profile names are saved incorrectly in builds since 2007062904, 0724, and 0725 (only the right byte is used). {Chinese, Cyrillics, Greek, Russian, German, umlauts, letters) → Non-ASCII characters in profile names are saved incorrectly in builds since 2007062904, 0724, and 0725 (UTF-8 and UTF-16 problems). {Chinese, Cyrillics, Greek, Russian, German, umlauts, letters}
Comment 1•17 years ago
|
||
Hmm.... nothing in the ranges jumps out at me, and they're all different. Could this have been some sort of build config change?
Flags: blocking1.9?
Comment 2•17 years ago
|
||
Yep, it was due to enabling Breakpad on each platform (via adding MOZILLA_OFFICIAL to various Makefiles). (We figured this out in #breakpad on IRC, but I guess it never made it back to this bug.)
Reporter | ||
Comment 3•17 years ago
|
||
Minefield file:// listings also don't support UTF-8 since that build.
Summary: Non-ASCII characters in profile names are saved incorrectly in builds since 2007062904, 0724, and 0725 (UTF-8 and UTF-16 problems). {Chinese, Cyrillics, Greek, Russian, German, umlauts, letters} → Non-ASCII characters in profile names are saved incorrectly; also in file:// listings; in builds since 2007062904, 0724, and 0725 (UTF-8 and UTF-16 problems). {Chinese, Cyrillics, Greek, Russian, German, umlauts, letters}
Updated•17 years ago
|
Assignee: nobody → ted.mielczarek
Flags: blocking1.9? → blocking1.9+
Assignee | ||
Comment 4•17 years ago
|
||
This is definitely caused by Breakpad somehow. Setting "Enabled=0" in application.ini causes this bug to disappear.
Assignee | ||
Comment 5•17 years ago
|
||
So uh, it breaks on this line:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/crashreporter/nsExceptionHandler.cpp&rev=1.26#351
If I stick a return NS_OK; right before that line, everything works. If I stick one right after that line, I see the bug. So confused.
Assignee | ||
Comment 6•17 years ago
|
||
It turns out that calling nsIFile::Append pre-XPCOM startup gets us into this situation. Using AppendNative works. Patch coming up.
Status: NEW → ASSIGNED
Component: Profile: BackEnd → Breakpad Integration
Product: Core → Toolkit
Updated•17 years ago
|
QA Contact: profile-manager-backend → breakpad.integration
Assignee | ||
Comment 7•17 years ago
|
||
I haven't tested this out on Mac/Windows yet, I have a build going on the TryServer currently. This fixes the issue on Linux, and also fixes some other areas that weren't unicode-safe on Windows.
Assignee | ||
Comment 8•17 years ago
|
||
You can test with this build:
https://build.mozilla.org/tryserver-builds/95-tmielczarek@mozilla.com-firefox-try-linux.tar.bz2
Assignee | ||
Comment 9•17 years ago
|
||
Comment on attachment 280778 [details] [diff] [review]
fix use of Append and GetNativePath
Doesn't break compiling on other platforms, and fixes the bug here.
Attachment #280778 -
Flags: review?(benjamin)
Updated•17 years ago
|
Attachment #280778 -
Flags: review?(benjamin)
Attachment #280778 -
Flags: review+
Attachment #280778 -
Flags: approval1.9+
Assignee | ||
Comment 10•17 years ago
|
||
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 11•17 years ago
|
||
Seems to WFM with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007091704 Minefield/3.0a8pre and "æабцaαü".
Assignee | ||
Comment 12•17 years ago
|
||
Feel free to mark verified...
Reporter | ||
Comment 13•17 years ago
|
||
Verified also with
Thunderbird version 3.0a1pre (2007091703)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007091701 SeaMonkey/2.0a1pre
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•