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}

VERIFIED FIXED

Status

()

Toolkit
Crash Reporting
--
major
VERIFIED FIXED
11 years ago
a month ago

People

(Reporter: Aleksej, Assigned: ted)

Tracking

(Depends on: 1 bug, {intl})

Trunk
x86
Linux
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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

11 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}
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

11 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

11 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

11 years ago
Assignee: nobody → ted.mielczarek
Flags: blocking1.9? → blocking1.9+
(Assignee)

Comment 4

11 years ago
This is definitely caused by Breakpad somehow.  Setting "Enabled=0" in application.ini causes this bug to disappear.
(Assignee)

Comment 5

11 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

11 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
QA Contact: profile-manager-backend → breakpad.integration
(Assignee)

Comment 7

11 years ago
Created attachment 280778 [details] [diff] [review]
fix use of Append and GetNativePath

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 9

11 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

11 years ago
Attachment #280778 - Flags: review?(benjamin)
Attachment #280778 - Flags: review+
Attachment #280778 - Flags: approval1.9+
(Assignee)

Comment 10

11 years ago
Checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Reporter)

Comment 11

11 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

11 years ago
Feel free to mark verified...
(Reporter)

Comment 13

11 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
Depends on: 1423897
You need to log in before you can comment on or make changes to this bug.