** Observed with 3/6/2000 Win32 build ** I make changes to font selection using Preference Window. Now I want to press "OK" and close the Pref. window, but it does not. The onyl way I can close it is by pressing Cancel. If you press "OK" first, the changes seem to hold but this is confusing. When you make changes to other parts of the Pref. window, pressing "OK" closes the window. This is probably a known but just in case. I don't think this happens on Mac.

Changing Appearance->Font the font size works OK, changing the font itself as well (I could closes prefs with OK). But changing the "fonts for" entry from Western to something else crashes the browser when hitting OK. Reproducible every time on Win95 03/05 build.

This is very interesting. I have many different profiles and with some of them I can close the Pref window and with some others, I cannot. Looking at this I see that the ones I cannot close by clicking on the OK button contain UTF-8 data for font names or some other items in prefs.js. CC'ing erik.

sebatistian, I think you should file a crashing problem as a separate bug.

OK, removing crash keyword

Adding Ben Goodger to Cc list. I think he knows something about this bug...

This is because the pref.js file probably has a sting in which the it is supposed to be an int. This will cause js to fail to load the file and the ok button will not work. A work around is to blow away your prefs.js file or change the pref that is set wrong.

The relevant people are probably already aware of this, but just in case, we shouldn't have a prefs system that is so fragile that a "broken" prefs.js file causes it to break. The code ought to be robust enough to gracefully handle the case where a user has inadvertently entered a string instead of an int using a normal text editor. We do expect people to use text editors to edit prefs.js, since we don't have UI for all prefs. So we must make the prefs code robust.

Should this bug be fixed on the front end of the backend?

I think the front-end (prefwindow code) ought to be changed so that the OK button will work even if the user has typed in a string pref instead of the expected int pref (in prefs.js).

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

Reassigning for Don

Move to M20 target milestone.

can this be fixed for beta3?

nav triage team: this is so old, we want to verify if this is still happening.

Nav triage team: No response to NEED INFO after one week... we're minusing this; if anyone cares please let us know ;)

I'm inclined to mark this bug worksforme. It seems that 9/11/2000 win build will simply delete an entry which contains a string like "18" for a pixel size int 16. I have also made values like false into "false" and that does not seem to have an effect on the OK button any more. I can use the OK button under either condition. Will mark this as worksforme -- if this is still a problem, please re-open and provide a test scenario.

This problem appears again on Win98 2000092212. (1) Open Preference dialog and select [Fonts] tab. (2) Change [Language encoding]. (3) Select [Themes] tab. (4) Select Classic or Modern and [Apply Classic]. (5) OK button becomes unresponsive.

I'm not positive how the user is able to reproduce this but this may be what they are reporting. The following is reported by Clint McIntosh on 11/15/2000 at http://www.macintouch.com/netscape6.html: After I make some adjustments within the Preference window, it will not acknowledge my mouse click on the OK button. the only way I can get out of it is to click on Cancel! and of course it doesn't retain my preferences.

I see that the steps reported by KOIKE 2000-9-12 provide a reproducible case. Just change the font settings for one language/encoding like "Unicode". And then change the theme from Modern to Classic. Afther that, you cannot use the OK button. I'm wondering, however, if this is the same as the original bug I reported, which has to do with the string value where the integer value is expected in prefs.js file.

nominating for beta1.

looks like two separate bugs - after changing theme, cannot make the OK button to take, have to hit cancel to close the prefs window. the other issue is that unable to change the encoding from western to anything else (irrespective of the theme switching). Sarah could you verify that that is the case and if so open two separate bugs on that. we saw this on 20010406 build. I think at that point, lets close this bug, and track the specific issues in their own bugs.

sorry for the delay... using 2001.04.20.1x comm bits on the 3 main platforms, i'm able to change the language encoding in prefs. moreover, theme switching in prefs doesn't prevent the OK button from working.

nav triage: based on sairuh's comments, this is a WORKSFORME.

No, I can still reproduce this bug with 2001043008/Linux. Please try the steps I wrote on 2001-09-22.

nav triage team: navigator team doesn't have the cycles to fix this, also, at this point, sounds like it may be a localized build issue. cc-ing ftang to see if he's willing to investigate this

Not being able to dismiss the prefs dialog is a pretty serious usability issue, I think. There is a cheap workaround here, which is to throw some try/catches around in the JS. You need at least to make sure always that the dialog can be dismissed, even if you drop some pref changes on the floor.

back on 0.9.1 list for a look

Adding Brian Nesse to CC list. Brian, isn't this a prefs arch issue? We should gracefully recover from bad content in a prefs.js file during prefs processing.

This isn't about reading prefs.js. It's about handling the OK button in the prefs dialog, and broken JS/XUL. Entirely frontend.

nav triage: moving to mozilla0.9.2, we can document that you must not change other prefs before switching themes. mcafee - can you add a suitable relnote to jatin's relnot bug. thanks,

Adding relnote to keywords.

nav triage: frequency and severity of this is low enough to be a non rtm stopper.

over to vishy to find an owner

->sgehani. We need to fix this for MachV. Do we have a new owner for prefs?

Moving to mozilla0.9.8.

resolving as wfm based on original report. Please file any other problems as separate bugs.

mass-verifying WorksForMe bugs. reopen only if this bug is still a problem with a *recent trunk build*. mail search string for bugspam: AchilleaMillefolium