Closed Bug 96008 Opened 24 years ago Closed 24 years ago

<radiogroup> implementation sucks!

Categories

(Core :: XUL, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla0.9.6

People

(Reporter: hyatt, Assigned: bugzilla)

References

Details

(Whiteboard: [xul1.0-widgets-radio])

The current implementation of <radiogroup> makes the assumption that the <radiogroup> has an id. This is fundamentally flawed. The impl relies on setting "group" attributes on every <radio> elt in the group. This is slow slow slow! :) If this is an attempt to deal with nested radio groups, then a helper function should just be written to walk the content model obtaining the group elts and skipping nested <radiogroup>s. It will perform way better than what's there now, since the current impl is using getElementsByAttribute, which will waste time crawling into the nested radio groups.
Blocks: 70753
Whiteboard: [xul1.0-widgets-radio]
--> me
Assignee: hewitt → blakeross
Would it be worthwile cacheing the list of radiobuttons as a property? <property name="radiobuttons"> this.getElementsByAttribute("radio", this.id); </property> Or just require ids on outer radiogroups: <property name="radiobuttons"> this.getElementsByTagName("radiogroup").length ? this.getElementsByAttribute("radio", this.id) : this.getElementsByTagName("radio"); </property>
Is this a bup of bug 96019?
Target Milestone: --- → mozilla0.9.6
Fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.