82639 - classic: disabled radiobutton children should not be clickable

Status: RESOLVED WORKSFORME

(SeaMonkey :: Themes, defect, P3)

Description

[sairuh (rarely reading bugmail)]

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.

Comment 1

[Todd Pringle]

themes triage: moving to 0.9.3, priority P3

Comment 2

[Joe Hewitt (gone)]

Attachment: patch to fix

Comment 3

[Joe Hewitt (gone)]

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

[Ben Goodger (use ben at mozilla dot org for email)]

Eddy, was the 'strange line' something you added? I honestly can't remember. 

Comment 5

[eddyk]

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.

Comment 6

[eddyk]

for reference, the bug responsible for the strange line is bug 70033

Comment 7

[Joe Hewitt (gone)]

blake must have fixed this when he re-wrote radiogroups