27826 - font pref UI does not stick to last choice if contains non ASCII

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect, P3)

Description

[Frank Tang]

I have not try window or linux yet. 
If the font face name contains non ASCII (which is very common on non English 
Mac and Window), the Font preference UI will show those name in the menu, but it 
won't show it as default next time you open it.

Step to reproduce this
1. prepare your environment- In MacOS 8.5 and up, install multilingual support 
from the English (or other) MacOS CD, you can either do this in the system 
installation time or later. Choice custom installation and pick the language you 
want. If you have already done this then the keyboard menu in the right upper 
corner (left to the application list) will show up
2. bring up Preference 
3. click Font tab
4. Select "ja" in the "Fonts for" field
5. Select "Osaka" for the Serif font
6. Select some other font which have non ASCII name for the Monospace font
7. Click OK
8. Open the preference, click font tab, select "ja" again
Exepct result, the Serif is default to "Osaka" as the one you pick last time, 
however the Monospace is default to the non ASCII font name you pick last time 
too.
Actual result, only the Serif is default to Osaka now. The Monospace is default 
to blank.
It does not matter Serif or Monospace- the non ASCII font name won't be sticky.
I suspect it is related to UTF-8 and Pref. Somehow, the set pref and get pref 
does not round trip the UTF-8 conversion. Probably one treat it as UTF-8 and the 
other treat it as Latin 1.

Comment 1

[Frank Tang]

I try Window build in Teruko's cube. It show the same thing. It remember ASCII 
font name but not NON-ASCII font name in Japanese window.

Comment 2

[Frank Tang]

more finding. When I change the font pref to some non ASCII name, the data write
out to the pref.js is not in UTF-8. It looks like all the unicode get drop off
the high 8 bits.

Comment 3

[Erik van der Poel]

Matt, this bug concerns the way we are writing the prefs out to prefs.js.

Comment 4

[bobj]

This makes font prefs feature unusable on Japanese (and other localized)
Windows and Mac systems since the Japanese (and other language) fonts use
non-ASCII names.  Nominating for Beta1.

Comment 5

[Michael La Guardia]

Clearing PDT+ for reconsideration.  This seems like something we could release note.

Comment 6

[Frank Tang]

same issue as 28464. Need different fix. Here is the patch -
Change the Platform/OS to all
cvs server: Diffing content
Index: content/pref-fonts.js
===================================================================
RCS file: /m/pub/mozilla/xpfe/components/prefwindow/resources/content/pref-fonts
.js,v
retrieving revision 1.3
diff -c -r1.3 pref-fonts.js
*** pref-fonts.js       2000/02/11 04:41:33     1.3
--- pref-fonts.js       2000/02/25 18:15:50
***************
*** 165,171 ****
                {
                        if (pref)
                        {
!                               var selectVal = pref.CopyCharPref(fontPrefstring
);
                        }
                }
                catch(ex)
--- 165,171 ----
                {
                        if (pref)
                        {
!                               var selectVal = pref.CopyUnicharPref(fontPrefstr
ing);
                        }
                }
                catch(ex)

Comment 7

[Frank Tang]

the patch is here. Please reconsider take this as beta1

Comment 8

[Erik van der Poel]

BobJ, please raise this at PDT meeting.

Comment 9

[bobj]

Since font names on Win and Mac in Japan (and elsewhere) are non-ASCII,
this bug totally breaks the ability of users to change fonts using the font
prefs dialog.  This is bogus to release note for a Beta1.

The patch is a one-line change in the Javascript to call the correct method
to write the prefs file.

Comment 10

[tao]

Minimum risk; maximum benefit.

Voted for this bug.

Comment 11

[sairuh (rarely reading bugmail)]

->teruko's group

Comment 12

[Phil Peterson]

PDT+ assuming this is a very low risk fix

Comment 13

[tao]

Hi, Frank:


Would you provide a QA test plan for IQA so all possible paths are covered?
Since the change is in *.js, IQA shall be able to apply the patch to install
directory and run the test.

I am working from home and do not have non-English OS here.


Thanks

Comment 14

[leger]

Moving to PDT-.  Did not make the 02/25 deadline for beta1.  Putting on the 
relnote keyword.

Comment 15

[leger]

Clearing PDT-. fix in hand 02/28.  Intl REALLY wants this in!  Per bobj "This 
makes font preferences unusable for Japanese users.  This is bad,
and it's not reasonable to leave this out of Beta1!"

Comment 16

[matt]

fix in hand.
Awaiting approval.
Communications error why this didn't get checked in before.

Comment 17

[bobj]

a=bobj
thanks.

Comment 18

[matt]

fixed

sorry about that

Comment 19

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 20

[Allan Masri]

added dependency on 25556: Mac only. Since I can't save changes to font prefs 
(ok button doesn't work after making changes), I can't verify this bug fix on 
Mac.

Comment 21

[Allan Masri]

also checked on Win98-ja. Was unable to set font prefs, so I can't verify
whether this bug is fixed there, either.

Comment 22

[matt]

This change when in.
The reason ok button does not close is because
we changed browser.sreen_resolution from a string to an int.
You need to blow that pref out of your prefs.js to get the ok
window to work.  Blow your prefs.js file away if that does not work.

thx

http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/con﷒0﷓

Comment 23

[Allan Masri]

not fixed with 2000020308, Mac:

Now, neither preference is retained. after closing and reopening window, default 
fonts for ja are both .Osaka Bold, the first item in the list.

Comment 24

[matt]

i'm not sure why this is happening and not
working.  Can i push this bug off to some one else
since that last fix did not work.

Comment 25

[Katsuhiko Momoi]

Thanks, Allan. 
The font settings are not retained on Windows 3/2/2000 build,
either. If this doesn't get fixed, we won't be able to 
change fonts at all by UI. That will be terrible.

Comment 26

[Frank Tang]

I found the problem. You check in "CopyUniCharPref" but my patc is 
"CopyUnicharPref" Notice it is  Uni'c'har ,not Uni'C'har .... lower case 'c' not 
upper case 'C' . 
Once you change that line it work.
If  you don't change that line, not only the non ASCII font won't be sticky, the 
ASCII won't be sticky neither.

Check that in. r=ftang

Comment 27

[bobj]

a=bobj

Comment 28

[bobj]

*** Bug 30323 has been marked as a duplicate of this bug. ***

Comment 29

[Frank Tang]

I fix and check in for matt

Comment 30

[Allan Masri]

verified fixed on Mac 2000030508