30801 - When a string pref is read into int field, prefs OK fails

Status: VERIFIED WORKSFORME

(SeaMonkey :: Preferences, defect, P2)

Description

[Katsuhiko Momoi]

** 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.

Comment 1

[Sebastian Späth]

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.

Comment 2

[Katsuhiko Momoi]

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. 

Comment 3

[Katsuhiko Momoi]

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

Comment 4

[Sebastian Späth]

OK, removing crash keyword

Comment 5

[Erik van der Poel]

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

Comment 6

[matt]

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.

Comment 7

[Erik van der Poel]

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.

Comment 8

[matt]

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

Comment 9

[Erik van der Poel]

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).

Comment 10

[matt]

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

Comment 11

[verah (gone)]

Reassigning for Don

Comment 12

[don]

Move to M20 target milestone.

Comment 13

[sairuh (rarely reading bugmail)]

can this be fixed for beta3?

Comment 14

[johng]

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

Comment 15

[verah (gone)]

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

Comment 16

[Katsuhiko Momoi]

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.

Comment 17

[Koike Kazuhiko]

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.

Comment 18

[Kathleen :Brade]

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.

Comment 19

[Katsuhiko Momoi]

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.

Comment 20

[sairuh (rarely reading bugmail)]

nominating for beta1.

Comment 21

[Viswanath Ramachandran]

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. 

Comment 22

[sairuh (rarely reading bugmail)]

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.

Comment 23

[Viswanath Ramachandran]

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

Comment 24

[Koike Kazuhiko]

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

Comment 25

[Paul Chen]

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

Comment 26

[Simon Fraser [no longer active]]

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.

Comment 27

[Chris McAfee]

back on 0.9.1 list for a look

Comment 28

[selmer (gone)]

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.

Comment 29

[Simon Fraser [no longer active]]

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

Comment 30

[Viswanath Ramachandran]

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, 

Comment 31

[Jaime Rodriguez, Jr.]

Adding relnote to keywords.

Comment 32

[Viswanath Ramachandran]

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

Comment 33

[Chris McAfee]

over to vishy to find an owner

Comment 34

[Peter Trudelle]

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

Comment 35

[Samir Gehani]

Moving to mozilla0.9.8.

Comment 36

[Peter Trudelle]

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

Comment 37

[sairuh (rarely reading bugmail)]

mass-verifying WorksForMe bugs.

reopen only if this bug is still a problem with a *recent trunk build*.

mail search string for bugspam: AchilleaMillefolium