Closed Bug 389636 Opened 12 years ago Closed 12 years ago
Document must be current doc of a Parent" and more with cloned <xul:richlistbox>
Loading the testcase triggers two assertions I haven't seen before: ###!!! ASSERTION: aDocument must be current doc of aParent: '!aParent || aDocument == aParent->GetCurrentDoc()', file mozilla/content/base/src/nsGenericElement.cpp, line 1931 ###!!! ASSERTION: Parent in document but flagged as forcing XBL: '!aParent || !aDocument || !aParent->HasFlag(NODE_FORCE_XBL_BINDINGS)', file mozilla/content/base/src/nsGenericElement.cpp, line 1944 It also triggers some assertions I have seen elsewhere: ###!!! ASSERTION: element not in the document: 'doc', file mozilla/layout/base/nsChildIterator.cpp, line 62 (bug 335896?) ###!!! ASSERTION: Shallow unbind won't clear document and binding parent on kids!: 'aDeep || (!GetCurrentDoc() && !GetBindingParent())', file mozilla/content/base/src/nsGenericElement.cpp, line 2082 (bug 360078 comment 8?)
We're constructing frames for a <xul:richlistbox>. One of the kids for it according to the content iterator is a <xul:scrollbox> which has a null GetCurrentDoc(). The asserts follow. Why does something with a non-null GetCurrentDoc() (the <xul:richlistbox>) have a kid with a null GetCurrentDoc()?
Oh, this is fun. The richlistbox has anon content and the NODE_FORCE_XBL_BINDINGS flag. The first time we append it, we're not appending into a document, so nothing happens. Then we remove from the <div> when appending to the <body>, don't tear down the XBL binding (because |document| is null) and unset the flag. Then we reinsert, don't bind the anonymous content, and end up in this state.
It's a little hacky... but I think it's acceptable.
Priority: -- → P2
Summary: "ASSERTION: aDocument must be current doc of aParent" and more with cloned <xul:richlistbox> → [FIX]"ASSERTION: aDocument must be current doc of aParent" and more with cloned <xul:richlistbox>
Target Milestone: --- → mozilla1.9beta2
Attachment #274033 - Flags: approval1.9+
Checked in, including the test as a "reftest". I wonder whether we could set up a mochitest here, though (e.g. still able to get the anon kids when they should be gone, or something).
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.