Closed Bug 465466 Opened 12 years ago Closed 10 years ago

"ASSERTION: Form controls not ordered correctly" with label, XBL

Categories

(Core :: DOM: Core & HTML, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase)

Attachments

(1 file)

569 bytes, application/xhtml+xml
Details
Attached file testcase
###!!! ASSERTION: Form controls not ordered correctly: 'CompareFormControlPosition(aControls[i], aControls[i + 1], aForm) < 0', file /Users/jruderman/central/content/html/content/src/nsHTMLFormElement.cpp, line 1302
Hmm.  Do anonymous form controls generally register themselves with a non-anonymous form ancestor?  If so, you'll just get this all over.  Try tossing some controls into a binding.  ;)

If they do that, though, it sounds like a bug to me.  Sicking, jst, what do you think?
Component: XBL → DOM: Core & HTML
QA Contact: xbl → general
IMHO they probably should not.
Hmm.  So nsGenericHTMLElement::FindForm does check for the bindingParent, so that part is ok...
I guess in this case we're mutating the anonymous content after removing the node the binding is attached to from the document, is key.

I hate XBL.
WFM
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Crashtest: http://hg.mozilla.org/mozilla-central/rev/e5dd52dd3cb5
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.