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



18 years ago
4 years ago


(Reporter: Katsuhiko Momoi, Assigned: Samir Gehani)


({intl, relnote})

Windows NT
intl, relnote

Firefox Tracking Flags

(Not tracked)




18 years ago
** 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

18 years ago
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.
Keywords: crash

Comment 2

18 years ago
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

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

Comment 4

18 years ago
OK, removing crash keyword
Keywords: crash

Comment 5

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

Comment 6

18 years ago
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

18 years ago
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

18 years ago
Should this bug be fixed on the front end of the backend?
Summary: Cannot close pref window when font changes are made with "OK" button → When a sting pref is read when needs int prefs fail

Comment 9

18 years ago
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).


18 years ago
Target Milestone: M16

Comment 10

18 years ago
*** Bug 25556 has been marked as a duplicate of this bug. ***
Summary: When a sting pref is read when needs int prefs fail → When a string pref is read when needs int prefs fail

Comment 11

18 years ago
Reassigning for Don
Assignee: matt → mcafee
Target Milestone: M16 → M17

Comment 12

18 years ago
Move to M20 target milestone.
Target Milestone: M17 → M21


18 years ago
Summary: When a string pref is read when needs int prefs fail → When a string pref is read into int field, prefs OK fails


18 years ago
Blocks: 40891
can this be fixed for beta3?
Keywords: correctness, nsbeta3

Comment 14

18 years ago
nav triage team:
this is so old, we want to verify if this is still happening.
Whiteboard: [NEED INFO]

Comment 15

18 years ago
Nav triage team: No response to NEED INFO after one week... we're minusing this; 
if anyone cares please let us know ;)
Whiteboard: [NEED INFO] → [NEED INFO] [nsbeta3-]

Comment 16

18 years ago
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.
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 17

18 years ago
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.
Resolution: WORKSFORME → ---

Comment 18

17 years ago
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.
Keywords: nsmac2

Comment 19

17 years ago
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.


17 years ago
Keywords: intl
nominating for beta1.
Keywords: nsbeta3 → nsbeta1
Whiteboard: [NEED INFO] [nsbeta3-]
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. 
Last Resolved: 18 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 24

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

Resolution: WORKSFORME → ---

Comment 25

17 years ago
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

17 years ago
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

17 years ago
back on 0.9.1 list for a look
Target Milestone: --- → mozilla0.9.1

Comment 28

17 years ago
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

17 years ago
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, 
Target Milestone: mozilla0.9.1 → mozilla0.9.2


17 years ago
Keywords: nsbeta1 → nsbeta1+

Comment 31

17 years ago
Adding relnote to keywords.
Keywords: relnote
Priority: P3 → P2
nav triage: frequency and severity of this is low enough to be a non rtm 
Target Milestone: mozilla0.9.2 → mozilla1.0

Comment 33

17 years ago
over to vishy to find an owner
Assignee: mcafee → vishy

Comment 34

16 years ago
->sgehani.  We need to fix this for MachV. Do we have a new owner for prefs?
Assignee: vishy → sgehani
Target Milestone: mozilla1.0 → ---


16 years ago
Target Milestone: --- → mozilla0.9.7

Comment 35

16 years ago
Moving to mozilla0.9.8.
Target Milestone: mozilla0.9.7 → mozilla0.9.8


16 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Comment 36

16 years ago
resolving as wfm based on original report. Please file any other problems as
separate bugs.
Last Resolved: 17 years ago16 years ago
Resolution: --- → WORKSFORME
mass-verifying WorksForMe bugs.

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

mail search string for bugspam: AchilleaMillefolium
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.