Closed Bug 128396 Opened 22 years ago Closed 3 years ago

blank titlebar for cyrillic text when locale is specified

Categories

(Core :: Internationalization, defect, P4)

x86
Linux
defect

Tracking

()

RESOLVED INACTIVE
Future

People

(Reporter: lesha37, Unassigned)

References

()

Details

(Keywords: intl, Whiteboard: needhelp)

Short story:

When locale is set to "ru"
  produced with: 
    localedef  -f charmaps/KOI8-R -i locales/POSIX ru
  set with (bash syntax)
    export -n LC_ALL
    export LANG=ru
Mozilla displays completely blank titlebars for Russian pages; without
the locale specification, Russian characters are filled with question marks.
With the locale specified, Mozilla should display the title bar in Russian (KOI8). 

Reproducibility: Always

Long story:


This was done on Linux 2.4.12 with XF 4.1, mozilla using 0.9.8 compiled from
source, and also with the linux binary distro of the same. 

Initially, I was trying to make copy-paste to external apps not return question
marks. I looked around, and determined that I needed to set my locale. After I
set my locale ("ru"), compiled using:
localedef  -f charmaps/KOI8-R -i locales/POSIX ru
set with (bash syntax)
export -n LC_ALL
export LANG=ru
Mozilla indeed started to copy and paste correctly. However, there were two
unpleasant side effects. Firstly, the fonts became slightly messed (the kerning
on Yandex looked weird, for instance). Secondly, the title bars of all Russian
pages became blank (this is on AfterStep). 

Further investigation of title bars:

On WindowMaker, the Russian characters are simply missing from the titlebar. 
xwininfo returns no title on the Mozilla window.
The calls to gtk_set_window_title and XChangeProperty in nsWindow::SetTitle both
received correct parameters, however (more about correctness later).
Upon restarting into AfterStep from WindowMaker, weird changes appear in the Moz
titlebar: multiple instances of /1 and koi8. xwininfo still returns no title.
Commenting out Ilya Konstantinov's change to SetTitle (XChangeProperty) has no
effect on the behavior.

On correctness: before I set the locale, I was able to make Mozilla behave 100%
correctly with a hack:
  Change line 211 of nsUNIXCharset.cpp (0.9.8 version) from 
    #if HAVE_NL_LANGINFO && defined(CODESET)
    nl_langinfo_codeset = nl_langinfo(CODESET);
    NS_ASSERTION(nl_langinfo_codeset, "cannot get nl_langinfo(CODESET)");
  to (context omitted)
    nl_langinfo_codeset = "KOI8-R";

That way, copy-paste works, and titlebars are displayed fine (with actual
Russian letters instead of question marks). The fonts are intact as well.

Even more interestingly: if I name the above locale "nl" instead of "ru" (I'd
guess this will work with any other latin-based locale as well), everything
works just like with the hard-coded hack.
Keywords: intl
QA Contact: ruixu → ylong
I can not reproduce it on linux RH7.2 when I login as Russian, the locale was
"ru_RU.KOI8-R".

There is no "ru" locale on my system.

Reporter:
Which linux system are you using?
Yuying Long:                                         
My system is a largely customized flavor of Slackware 7.1; The "ru" locale was
created using a command (localedef  -f charmaps/KOI8-R -i locales/POSIX ru)
executed from /usr/share/i18n. I've also tried using ru_RU instead of a
POSIX locale, and using the name "ru_RU.KOI8-R" instead of "ru". The result is the
same. I have even tried some pre-packaged ru_RU.KOI8-R locale files from
other distributions. If you post the associated files for your ru_RU.KOI8-R locale
(LC_* from something like /usr/share/locale/ru_RU.KOI8-R), I can give that a
try as well.
OK, I found the ru_RU locale under my /usr/share/i18n/locale. 

And I can reproduce the problem under lcoale "ru_RU".

Confirm and cc shanjian, ftang. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
-> ftang
Assignee: yokoyama → ftang
P4 future. If you have a patch to fix it , give it to me. Otherwise, I will
delay Russian specific issue. 
Status: NEW → ASSIGNED
Priority: -- → P4
Whiteboard: needhelp
Target Milestone: --- → Future
what a hack. I have not touch mozilla code for 2 years. I didn't read these bugs
for 2 years. And they are still there. Just close them as won't fix to clean up.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Mass Bug Re-Open of bugs Frank Tang Closed with no good reason. Spam is his
fault not my own
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Mass Re-assinging Frank Tangs old bugs that he closed won't fix and had to be
re-open. Spam is his fault not my own
Assignee: ftang → nobody
Status: REOPENED → NEW
QA Contact: amyy → i18n

This is verified to work today. Reopen if needed.

Status: NEW → RESOLVED
Closed: 19 years ago3 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.