Closed
Bug 385845
Opened 18 years ago
Closed 14 years ago
"ASSERTION: mDocElement not in doc?" if documentElement is removed during onload
Categories
(Core :: XML, defect)
Core
XML
Tracking
()
RESOLVED
FIXED
mozilla2.0b7
People
(Reporter: jruderman, Assigned: philor)
References
Details
(Keywords: assertion, intermittent-failure, testcase)
Attachments
(4 files)
###!!! ASSERTION: mDocElement not in doc?: 'mDocument->IndexOf(mDocElement) != -1', file mozilla/content/xml/document/src/nsXMLContentSink.cpp, line 343
Reporter | ||
Comment 1•18 years ago
|
||
This triggers the assertion, too.
Comment 2•18 years ago
|
||
It seems to me that the assertion is bogus; that guarantee simply doesn't exist because of scripts like this one. (XML parsing is still consistent even if the document tree is being modified as it is parsed.)
Here's another testcase (XHTML this time).
Assignee | ||
Comment 4•14 years ago
|
||
And http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1285965566.1285966438.9435.gz says that reftest/tests/layout/svg/crashtests/385840-1.svg is another testcase.
Assignee | ||
Comment 5•14 years ago
|
||
I'm way out of my depth, but I think that the state of the code in 1.8,
317 if (mDocElement) {
318 // Notify document observers that all the content has been stuck
319 // into the document.
320 // XXX do we need to notify for things like PIs? Or just the
321 // documentElement?
322 NS_ASSERTION(mDocument->IndexOf(mDocElement) != -1,
323 "mDocElement not in doc?");
324
325 mozAutoDocUpdate docUpdate(mDocument, UPDATE_CONTENT_MODEL, PR_TRUE);
326 mDocument->ContentInserted(nsnull, mDocElement,
327 // XXXbz is this last arg relevant if
328 // the container is null?
329 mDocument->IndexOf(mDocElement));
330 }
means that the assertion was related to notifying mDocument's observers about mDocElement, and not wanting to tell them about something that wasn't in their document, and so bogus or not it's no longer related to anything that's actually happening where it's being asserted.
Assignee: nobody → philringnalda
Status: NEW → ASSIGNED
Attachment #480355 -
Flags: review?(bzbarsky)
Assignee | ||
Updated•14 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
![]() |
||
Comment 6•14 years ago
|
||
Comment on attachment 480355 [details] [diff] [review]
rm
r=me
Attachment #480355 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 7•14 years ago
|
||
Comment on attachment 480355 [details] [diff] [review]
rm
Tempting to claim I can just push this, since it's an orange fix and practically speaking NPOToptB.
Attachment #480355 -
Flags: approval2.0?
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs approval]
Assignee | ||
Comment 8•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Whiteboard: [needs approval]
Target Milestone: --- → mozilla2.0b8
Assignee | ||
Updated•14 years ago
|
Attachment #480355 -
Flags: approval2.0?
Assignee | ||
Comment 9•14 years ago
|
||
And http://hg.mozilla.org/mozilla-central/rev/891a83ede325 since I somehow failed to notice the annotation about how layout/xul/base/src/crashtests/321056-1.xhtml was yet another testcase for this.
Updated•14 years ago
|
Target Milestone: mozilla2.0b8 → mozilla2.0b7
Updated•12 years ago
|
Keywords: intermittent-failure
Updated•12 years ago
|
Whiteboard: [orange]
You need to log in
before you can comment on or make changes to this bug.
Description
•