Closed
Bug 92358
Opened 24 years ago
Closed 24 years ago
Nested XUL radio button groups don't work.
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: smeredith, Assigned: jag+mozilla)
References
Details
Attachments
(5 files)
988 bytes,
patch
|
Details | Diff | Splinter Review | |
798 bytes,
application/vnd.mozilla.xml+xul
|
Details | |
798 bytes,
application/vnd.mozilla.xul+xml
|
Details | |
698 bytes,
patch
|
Details | Diff | Splinter Review | |
756 bytes,
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+)
Gecko/20010717
BuildID: 20010725
If you have a group of radio buttons inside another group of radio buttons,
clicking on the buttons in the nested group unselect the buttons in the outer group.
I am going to attach a patch with a simple change to
/xpfe/browser/samples/widgets.xul to demonstrate the problem.
Reproducible: Always
Steps to Reproduce:
Create a set of nested radio buttons in XUL, to looks something like this:
( ) Radio 1
(*) Radio 2
(*) SubRadio A
( ) SubRadio B
( ) Radio 3
with the 2 sets of radio buttons in different groups.
Select Radio 2
Click on SubRadio A
Actual Results: As soon as you click on SubRadio A, Radio 2 gets unselected.
Expected Results: Clicking on SubRadio A should not unselect anything in the
outer group.
I need this to work to implement bug 90989.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
Hmm, so the radiogroup binding does not anticipate a nested radiogroup, so when
the click bubbles up from the inner group to the outer group, the outer group
assumes that the radio was a member of its collection. Seems, that it would be
possible to extend the filter on the click (and mousedown and other) handler
to check that the group attribute of the event target does actually match the
id of the radiogroup that is catching this event.
Comment 3•24 years ago
|
||
Comment 4•24 years ago
|
||
Comment 5•24 years ago
|
||
*pink spins the bottle* --> jag!
Assignee: trudelle → jaggernaut
Target Milestone: --- → mozilla1.1
Reporter | ||
Comment 6•24 years ago
|
||
I am attaching a patch that fixes this. It works, but there might be a better
way.
Keywords: nsenterprise,
patch
Reporter | ||
Comment 7•24 years ago
|
||
Comment 8•24 years ago
|
||
Hmm. I don't think you want to unilaterally kill event bubbling out of this
widget. I think the right fix is what I noted above ("check that the group
attribute of the event target does actually match the id of the radiogroup
that is catching this event.") jag/blake: does that seem correct?
Reporter | ||
Comment 9•24 years ago
|
||
Reporter | ||
Comment 10•24 years ago
|
||
Oh, you mean like this? (See attached patch.) Why didn't you say so. ;-)
Comment 11•24 years ago
|
||
Yeah, that's the ticket :-]
I might be inclined to do it this way, since if it's not a radio element,
then it doesn't matter if the 'group' attribute matches the radiogroup's id.
[Excuse the bugzilla line wrapping ...]
Index: radio.xml
===================================================================
RCS file: /cvsroot/mozilla/xpfe/global/resources/content/bindings/radio.xml,v
retrieving revision 1.3
diff -u -r1.3 radio.xml
--- radio.xml 2001/07/25 06:14:25 1.3
+++ radio.xml 2001/08/04 02:04:11
@@ -129,7 +129,9 @@
<handlers>
<handler event="click" button="0">
<![CDATA[
- if (event.target.localName == "radio" && !event.target.disabled)
+ if (event.target.localName == "radio" &&
+ event.target.getAttribute("group") == this.id && // nested
radiogroups?
+ !event.target.disabled)
this.selectedItem = event.target;
]]>
blake/jag, comments, r=/sr=, etc.?
Keywords: nsBranch
Target Milestone: mozilla1.1 → ---
Comment 12•24 years ago
|
||
seems okay to me, sr=blake
Assignee | ||
Comment 13•24 years ago
|
||
r=jag on john's version of the patch. Please make sure this works in both modern
and classic.
Reporter | ||
Comment 14•24 years ago
|
||
Checked in the patch.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 15•24 years ago
|
||
Just out of interest, why does the radiogroup handle the click? Why not handle
the click on the radio element?
Comment 16•24 years ago
|
||
Should the mousedown event be updated? It may not be necessary.
Index: radio.xml
===================================================================
RCS file: /cvsroot/mozilla/xpfe/global/resources/content/bindings/radio.xml,v
retrieving revision 1.5
diff -u -r1.5 radio.xml
--- radio.xml 2001/08/16 03:14:18 1.5
+++ radio.xml 2001/08/17 08:08:41
@@ -140,7 +140,10 @@
<handler event="mousedown" button="0">
<![CDATA[
- if (event.target.localName == "radio" && !event.target.disabled)
+
+ if (event.target.localName == "radio" &&
+ event.target.group == this.id &&
+ !event.target.disabled)
this.focusedItem = event.target;
]]>
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•