661489 - Unicode coding for error reporting window dialog

Status: RESOLVED DUPLICATE of bug 602565

(Toolkit :: Crash Reporting, defect)

Description

[Raul Nicolae Malea]

Attachment: firefox error report ro

Report errors is coded on 8 bits. In Romanian language and in all laguage with diacritics /special signs  this text is displayed with question marks. (see in photo attached)

So need to recoded in Unicode.


For Romanian language more informations here: https://groups.google.com/forum/#!topic/mozilla-ro/T1E5j2F6rxk

Comment 1

[Justin Dolske [:Dolske]]

The localized crashreporter.ini looks correct in the browser (http://mxr.mozilla.org/l10n-central/source/ro/toolkit/crashreporter/crashreporter.ini). And I'm not aware of other locales having problems with 
UTF-8 characters not showing up...

I'd guess this is a problem with the default system font on not having glyphs for those characters? Not sure.

Comment 2

[Cristian Secară]

On Windows, a character with missing glyph will display a blank square.
A character with an Unicode codepoint that is outside of the current 8 bit codepage will display a question mark.

So this is a case of 8 bit control trying to display a character that has no CP-12xx equivalent (1250 in our case), specifically characters 0x0218 to 0x021B which does not exist in neither Windows codepage.

Cristi

Comment 3

[(not currently active) Ted Mielczarek]

This might be a dupe of bug 602565, but I never figured anything out there either.

Note that it's just the text in the top section, which is a rich edit control.

Comment 4

[Raul Nicolae Malea]

(In reply to Ted Mielczarek [:ted, :luser] from comment #3)
> This might be a dupe of bug 602565, but I never figured anything out there
> either.
> 
> Note that it's just the text in the top section, which is a rich edit
> control.

Bug 602565 is similar.

Comment 5

[Raul Nicolae Malea]

Any news for this bug?

Comment 6

[Raul Nicolae Malea]

Ping!

Comment 7

[(not currently active) Ted Mielczarek]

If nobody has commented, then no, there is no news for this bug.

Comment 8

[Raul Nicolae Malea]

Attachment: Bug resolved in nightly

Comment 9

[Raul Nicolae Malea]

This bug is resolved for Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121010030605 ?

about:buildconfig
Build Machine
w64-ix-slave102
Source
Built from http://hg.mozilla.org/mozilla-central/rev/ec10630b1a54
Build platform
target
i686-pc-mingw32
Build tools
Compiler 	Version 	Compiler flags
%cl InvokeClWithDependencyGeneration cl 	16.00.30319.01 	-TC -nologo -W3 -Gy -Fdgenerated.pdb -we4553 -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 -Oy-
%cl InvokeClWithDependencyGeneration cl 	16.00.30319.01 	-TP -nologo -W3 -Gy -Fdgenerated.pdb -wd4345 -wd4351 -wd4800 -we4553 -GR- -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 -Oy-
Configure arguments

--enable-update-channel=nightly --enable-update-packaging --enable-jemalloc --enable-signmar --enable-profiling --enable-js-diagnostics

Please confirm this.

Comment 10

[(not currently active) Ted Mielczarek]

Sounds like bug 602565 fixed this then. You could verify that by testing nightly builds from 2012-02-22 (right before the change landed) and 2012-02-23 (right after it landed).

Comment 11

[Raul Nicolae Malea]

Bug resolved in Nightly (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121023030553) by bug 602565. See screenshot attached.