textfields for deselected checkboxes shouldn't allow editing



18 years ago
10 years ago


(Reporter: sairuh (rarely reading bugmail), Unassigned)


Firefox Tracking Flags

(Not tracked)




18 years ago
if this is a dup, let me know --i noticed this in the Preferences dialog on all
three platforms, using opt comm bits from 2000.03.09.xx.

this also occurs in Communicator 4.7x, and imho it's kinda confusing UI design
--if a checkbox or radio button with an associated textfield is not selected,
the user shouldn't be able to edit the contents of that textfield.

to observe/repro:
1. open Prefs.
2. go to Mail & News > Disk Space.
3. go to a textfield that's associated with a checkbox or radio button that is
*not* selected --especially if it already has contents, eg,
"Do not store messages locally that are larger than 50 KB" or
"Automatically compact folders when it will save over 100 KB" or
"Keep the newest 30 messages"
4. remove/change the value in the textfield. eg, i replaced the three values in
step (3) with 42.
5. click OK to dismiss Prefs.
6. reopen Prefs, and read the prefs.js file...

result: you'll be able to change those unselected textfields! in fact, they're
even written to the prefs.js if you exited Prefs w/OK:

user_pref("mail.max_size", 42);
user_pref("mail.purge_threshhold", 42);
user_pref("news.keep.count", 42);

i would think that these values would be neither written to prefs.js *or*
displayed upon returning to Preferences --when they weren't even selected in the
first place.

Comment 1

18 years ago
this also occurs in 4.7x --sure sounds like it would be a long-running bug then.
however, lisa, could you tell me whether/why this would be considered expected
behavior? (if it is, okay, i might invalidate this.)

note that changing the values (in both 4.7x and seamonkey) back to their
defaults (still *without* selecting them), removes them from
preferences.js/prefs.js. odd.

Comment 2

18 years ago
if this is a valid bug, am nominating for beta1.

would send email about this issue, but the mail server is sucking big time at
the moment. :-(
Keywords: beta1

Comment 3

18 years ago
On some platforms, if you have an edit field associated with a radio button or a 
checkbox that is not selected/checked, when you edit the field, the radio button 
or checkbox should become automatically enabled.

I don't think in 4.x we had this working properly.

Comment 4

18 years ago
Putting on PDT+ radar for beta1. 
Whiteboard: [PDT+]

Comment 5

18 years ago
Ben sez he'll take care of this ...
Assignee: matt → ben
Priority: P3 → P2
Target Milestone: M14
clearing PDT+ as this is a 4.x issue as well and I think it requires some more 

yes the text fields should be disabled, but how the information that is in them 
is disabled is saved or not saved as the case may be is the important thing. We 
have two options:

1) destroy the data in prefs for prefs set by disabled fields
   cons: data loss. e.g. on windows, set up networking to use a specific IP, DNS 
server etc. save, then change to auto suppplied IP, and disable DNS. Save. 
Return and enable DNS and go to specify IP again - all previously entered data 
is lost. 

2) Maintain data last entered in field 
   better, but what if there are conflicts between these prefs remaining set and 
the disabling of the meta (owning) pref?

Whiteboard: [PDT+]

Comment 7

18 years ago
Putting on PDT- radar for beta1.
Whiteboard: [PDT-]

Comment 8

18 years ago
If this is also 4.x behavior then I don't think we need to bother with this for
beta 2 either.  Why is the severity of this bug "critical"?  Can this be reduced
to "normal" or even "enhancement"?

Priority: P2 → P5
Target Milestone: M14 → M17

Comment 9

18 years ago
I think this bug falls under 'good UI design pratice/polish', but is not a
'critical' thing for beta 2. user error is unlikely as a result of this
unpolished behavior.
with regards to Ben's ponderings for the longer run I think it is acceptable in
disabled state to keep the entries around only long enough while the prefs
dialog is open, and not save them, if this would cut down time to implement.
This behavior - while not as convenient as saving disabled entries - is at least

Comment 10

18 years ago
okay, i'll bump this down to normal. :-) but i agree w/german --this problem is
poor UI behavior...
Severity: critical → normal
not a priority, pushing out as far as possible.
Target Milestone: M17 → M20

Comment 12

18 years ago
pardon the spam: beta1 is long gone...removing this keyword. will soon replace
Keywords: beta1

Comment 13

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

Comment 14

18 years ago
so, this is no longer a problem with textfields associated with radiobuttons 
(eg, the Proxies panel). but this is still a problem with textfields associated 
with checkboxes (eg, the Composer panel).

ben/jrgm, possible to fix [soon]?

beppe, who handles the composer prefs (thought it's brade, but she's on 
sabbatical now)...?
Keywords: correctness, nsbeta3
Summary: textfields for deselected checkboxes/radio buttons shouldn't allow editing → textfields for deselected checkboxes shouldn't allow editing
Whiteboard: [PDT-]

Comment 15

18 years ago
is this only in the editor pref section or is it across all prefs? If it is 
across all prefs, then it belongs to Ben

Comment 16

18 years ago
Enabling/disabling certain widgets depending on the state of some "master" 
widget needs to done on a case-by-case basis. There is no simple way to 
develop a general purpose facility for managing this dependent behaviour
(e.g., the dependent set of widgets could be some arbitrary collection, and 
the logical relation is not apparent from the structure of the XUL).

There is a good example of how to implement JS to control enabling/disabling
of dependent widgets in chrome://communicator/content/pref/pref-proxies.

Perhaps, it would be best to just close this bug out, and sairuh find the 
places in the prefs UI where something similar needs to done, on a separate
bug-per-panel basis.

(As far as what to do with pref values written into disabled widgets, that 
would best be handled by the back-end code that acts on these pref values.
Pref values that only have meaning in a particular mode, should never be used
unless the pref that sets that mode is also turned on (although I suspect that
most back-end code already does the right thing)).

Comment 17

18 years ago
nav triage team:
nsbeta3-, M Future
Whiteboard: [nsbeta3-]
Target Milestone: M21 → Future

Comment 18

17 years ago
Eddy, can you take this?  Talk to Ben for more info.
Assignee: ben → eddyk

Comment 19

17 years ago
There are two issues in this bug:

1) disabling elements based on a master element

This has been mostly handled on an individual basis (the Mail/News disk space 
panel isn't even there anymore) and the same issues in other panels should be 
filed as new bugs.

2) Writing prefs to the prefs file when the xul element was disabled.

In my opinion, this is a front end issue, much like 1).  The nsPrefWindow code 
should not make an assumption that a disabled xul element should not be written 

I thought that this might interfere wih the eClient pref lockdown feature, but 
on second thought, as long as the front end display is not affected, we should 
be ok.  But if we're still showing the value in an element, would the user 
assume that it is saved and can be seen later?  Does this fix the problem of 
conflicting preferences?

The front end should clear the contents of an element if necessary.  While it 
seems fairly simple to modify nsPrefWindow to not write out prefs for disabled 
elements, I'm not sure if this is the right thing to do.  Please convice me if 

Comment 20

16 years ago
Assignee: eddyk → ben
Keywords: nsbeta3
Whiteboard: [nsbeta3-]

Comment 21

16 years ago
removing myself from the cc list
Product: Browser → Seamonkey
Assignee: bugs → prefs
QA Contact: bugzilla
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs

Comment 23

10 years ago
I've checked all the way back to SeaMonkey 1.0 and as far as I can tell all the specific items mentioned here have been fixed. And any not specifically mentioned should have been fixed in the toolkit preferences migration. If there are any remaining items, please file a new bug.
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.