27428 - Can't dismiss preferences if no font prefs changed

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect, P1)

Description

[Richard Zach]

If the font preferences are selected, clicking OK doesn't close the preference
panel.

To reproduce:
1. Edit | Preferences
2. Choose fonts
3. Click OK

Actual result: Prefs panel not dismissed.  Console output:

*** VALUE=x-western
*** VALUE=16
*** VALUE=times
*** VALUE=courier
*** VALUE=16
*** elementObject.elType = Radio
*** going to set int pref: browser.chrome.toolbar_style = 2
*** elementObject.elType = Radio
*** elementObject.elType = Radio
*** elementObject.elType = select-one
*** going to set int pref: font.size.variable.x-western = 16
*** elementObject.elType = select-one
*** going to set int pref: font.size.fixed.x-western = 16
*** elementObject.elType = Radio
*** going to set int pref: browser.use_document_fonts = 1
*** elementObject.elType = Radio
JavaScript Error: uncaught exception: [Exception... "Component returned failure
code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPref.SetCharPref]"  nsresult:
"0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://pref/content/pref.js :: PREF_ParsePref :: line 226"  data: no]

Expected result: Prefs panel closes

This happens even if no font prefs were changed.

Linux build 2000.02.11.11

Comment 1

[leger]

Bulk move of all Pref UI component bugs to new Preferences component.  Pref UI 
component will be deleted.

Comment 2

[sairuh (rarely reading bugmail)]

i now get a crash on all three platforms when i go through the steps above.
tested w/opt comm bits, 2000022308.

Talkback report for linux:
http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=39&cp=3&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=5845326

Talkback report for winNT:
http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=39&cp=3&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=5845392

Talkback report for mac:
http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=39&cp=3&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=5845444

Comment 3

[leger]

Putting on PDT+ radar for beta1.

Comment 4

[don]

Ugh, when did this break?

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

erm.. this works for me. Assuming matt has since made changes to this panel that 
fixed this problem... 

Comment 6

[Richard Zach]

I still get the same results on Linux build 2000.02.27.09 as originally
reported.  No crash though.

Comment 7

[sairuh (rarely reading bugmail)]

very odd. unable to repro this on linux, winNT... and only once on mac did i
manage to hang seamonkey (but not reproducible --otherwise fine). very odd.
tested w/opt comm bits 2000022808. wonder what changed...

Comment 8

[Richard Zach]

I have the browser.screen_resolution pref set to 120.  If I remove that line, I
don't get the JS error and the panel closes.  I filed bug 27432 a while back
problems with the screen resolution pref (it's not read from nor saved to
prefs.js).  If that is fixed, this problem will probably go away.  Mark as dup
if you like.

Comment 9

[matt]

i set my screen resolution to 126.
It still dismisses the prefs pane from me.
Try deleting that item in your prefs.js.
I can't reproduce this for some reason.

Comment 10

[matt]

can you try deleting your prefs.js file.
And see if that helps at all?
i can't reproduce this.

Comment 11

[Richard Zach]

Ok, here we go: if my prefs.js says
  user_pref("browser.screen_resolution", "120");
it works fine.  I had the following line in there:
  user_pref("browser.screen_resolution", 120);
(note: no quotes around 120).  With that line, I get the JS error and can't
close the panel.  The problem is that *with* the quotes, I don't get the right
screen resolution (i.e., the fonts are too small)!

Comment 12

[matt]

ok thanks to your help i have a fix.
Looks like browser.screen_resolution is
a int and it was put here as a string.
Is this right Eric...
Can you review the change Eric?
Just to be warning you that everyone will have to change their
pref to a string. now that i have changed this to a int.

Index: fontScalingOverlay.xul
===================================================================
RCS file: /cvsroot/mozilla/xpfe/components/prefwindow/resources/content/fontScal
ingOverlay.xul,v
retrieving revision 1.4
diff -r1.4 fontScalingOverlay.xul
38c38
<         <html:input type="text" id="browserScreenResolution" pref="true" preft
ype="string"
---
>         <html:input type="text" id="browserScreenResolution" pref="true" preft
ype="int"



Index: fontScalingOverlay.xul
===================================================================
RCS file: /cvsroot/mozilla/xpfe/components/prefwindow/resources/content/fontScal
ingOverlay.xul,v
retrieving revision 1.4
diff -r1.4 fontScalingOverlay.xul
38c38
<         <html:input type="text" id="browserScreenResolution" pref="true" preft
ype="string"
---
>         <html:input type="text" id="browserScreenResolution" pref="true" preft
ype="int"

Comment 13

[Richard Zach]

Will this also fix bug 27432?

Comment 14

[matt]

yes this will fix that bug.

Comment 15

[matt]

*** This bug has been marked as a duplicate of 27432 ***

Comment 16

[matt]

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

Comment 17

[matt]

reversed duped.
Reopening

Comment 18

[matt]

fixed...

You will need to blow away this preference
since it will be a read as a string but it is actaully
a integer.  Easy way is just remove the pref.js file
if the pref does not seem to load.

Comment 19

[matt]

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

Comment 20

[Richard Zach]

Verified on Linux build 2000.03.01.08.

Comment 21

[sairuh (rarely reading bugmail)]

also looks good on winNT [comm] and mac [mozilla] (as well as the comm bits of
linux), using 2000.03.01.08.