Closed
Bug 82639
Opened 24 years ago
Closed 23 years ago
classic: disabled radiobutton children should not be clickable
Categories
(SeaMonkey :: Themes, defect, P3)
SeaMonkey
Themes
Tracking
(Not tracked)
RESOLVED
WORKSFORME
mozilla0.9.7
People
(Reporter: bugzilla, Assigned: hewitt)
References
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
thx to jrgm for pointing this out. this is a problem only with the classic theme, not when using modern. tested using 2001.05.24.0x bits on mac and winnt and 2001.05.23.08 bits on linux. to observe: seen in the helper app/downloading dialog: 1. go to http://mozilla.org and scroll to the download link section. 2. click on any of the links to bring up the helper app/downloading dialog. in the dialog, the first toplevel radiobutton "Use default action for this type of file" will be selected. the second toplevel radiobutton "Use a different action for this file" will be enabled, but its two children will be greyed-out [appear disabled]. 3. click in the radiobutton of either of the two children, "Save this file to disk" or "Open with application". result: clicking on the children will enable/select that child --even though the parent remains unselected! expected: as with clicking either the Choose button or typing within the application textfield, nothing should happen when clicking a disabled widget --esp if its parent is unselected.
Reporter | ||
Updated•24 years ago
|
Keywords: mozilla0.9.1,
nsbeta1
Assignee | ||
Updated•24 years ago
|
Severity: major → normal
Status: NEW → ASSIGNED
Keywords: mozilla0.9.1,
nsbeta1
Target Milestone: --- → mozilla0.9.2
Comment 1•24 years ago
|
||
themes triage: moving to 0.9.3, priority P3
Priority: -- → P3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Assignee | ||
Comment 2•24 years ago
|
||
Assignee | ||
Comment 3•24 years ago
|
||
Blake, Ben, can you review this patch? I had to remove that one "strange line", and I'm not sure who's responsible for it (since I swept the cvs blame a while ago), but I suspect it's one of you.
Comment 4•24 years ago
|
||
Eddy, was the 'strange line' something you added? I honestly can't remember.
That strange line was added by me when I was implementing the "disable xul properties when the corresponding pref is locked" feature for eClient. The radio group, not the children are associated with a preference. So when a preference corresponding to an element is locked in the pref back-end, the disabled property is set on the radiogroup. In the case of the radiogroup, the disabled property should have disabled the children. However, it was not firing the getter/setters until I used that hack. The way it was explained to me, there being two objects models (js and xul) and setting an attribute versus setting a property were different and I was trying to get the disabled property setter/getter to fire. What I don't understand was why other xul elements (textboxes, checkboxes, etc) were able to properly disable regardless of which method is used and why radiogroup doesn't. Hopefully whatever was causing the failure to fire the setter/getter works now and the line is no longer needed. Otherwise, we've got a new bug.
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → ---
Assignee | ||
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9.7
Assignee | ||
Comment 7•23 years ago
|
||
blake must have fixed this when he re-wrote radiogroups
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•