Closed Bug 82639 Opened 24 years ago Closed 23 years ago

classic: disabled radiobutton children should not be clickable

Categories

(SeaMonkey :: Themes, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
mozilla0.9.7

People

(Reporter: bugzilla, Assigned: hewitt)

References

Details

Attachments

(1 file)

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.
Blocks: 78106
Severity: major → normal
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
themes triage: moving to 0.9.3, priority P3
Priority: -- → P3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Attached patch patch to fixSplinter Review
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.
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.
for reference, the bug responsible for the strange line is bug 70033
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → ---
Target Milestone: --- → mozilla0.9.7
blake must have fixed this when he re-wrote radiogroups
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: