Closed Bug 1032654 Opened 7 years ago Closed 7 years ago
"Assertion failure: a
Builder->Get Document() == a Text Node->Owner Doc()" with <template>
Assertion failure: aBuilder->GetDocument() == aTextNode->OwnerDoc(), at /Users/jruderman/trees/mozilla-central/parser/html/nsHtml5TreeOperation.cpp:127
We are appending text to a text node that has a different owner document than the document builder. This is happening because the text node is inside a template content, and template contents are owned by a different document. From what I can tell, the assertion here is invalid and the code doesn't actually need the owner document to match. There is also other evidence that the assertion is invalid even if we ignore the template case. In the call sites: http://dxr.mozilla.org/mozilla-central/source/parser/html/nsHtml5TreeOperation.cpp#157 http://dxr.mozilla.org/mozilla-central/source/parser/html/nsHtml5TreeOperation.cpp#512 Prior to calling AppendTextToTextNode, we see: nsHtml5OtherDocUpdate update(aParent->OwnerDoc(), aBuilder->GetDocument()); This suggests that we expect the case where the text node is owned by a document that is different from the document builder. Bug 509666 suggests that it is possible for this to happen when script moves nodes around during parsing, although it doesn't look like there are tests for this which is probably why we don't currently hit the assertion.
Attachment #8450537 - Flags: review?(bugs)
Indeed, the assertion is there to make sure that the case where a script has moved nodes between documents doesn't end up running the path that was, at least prior to bug 902618, optimized for the case where a script hasn't moved nodes between documents. It's possible that the assertion was bogus even before bug 902618 landed, though, since it indeed looks like the callers make sure the update batch is open on the right doc.
Assignee: nobody → wchen
OS: Mac OS X → All
Hardware: x86_64 → All
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in before you can comment on or make changes to this bug.