Closed
Bug 664919
Opened 13 years ago
Closed 13 years ago
Crash with document.normalize, DOMCharacterDataModified mutation event
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
VERIFIED
FIXED
mozilla7
People
(Reporter: jruderman, Assigned: sicking)
References
Details
(Keywords: crash, regression, testcase)
Crash Data
Attachments
(4 files)
534 bytes,
text/html
|
Details | |
3.00 KB,
text/plain
|
Details | |
12.15 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
984 bytes,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Reporter | ||
Comment 1•13 years ago
|
||
Comment 2•13 years ago
|
||
We crash at here: #2 0x0070d361 in nsGenericElement::Normalize (this=0x1b058240) at ../../../../mozilla/content/base/src/nsGenericElement.cpp:2791 2789 nsCOMPtr<nsIContent> sibling = GetChildAt(index + 1); 2790 2791 if (sibling->NodeType() == nsIDOMNode::TEXT_NODE) { (gdb) p sibling $2 = { mRawPtr = 0x0 } At this point index == 0 and count == 2. We used to have a null-check on |sibling|, but that got removed in bug 659539 part 4.... Jonas, can we just defer mutation event firing till after normalize() is done so we don't have to worry about this sort of gunk?
Assignee | ||
Comment 4•13 years ago
|
||
hrm.. crap.. that's not trivial since we need to fire the DOMNodeRemoved events before removing any nodes :( We could do a two-pass thing and first figure out which nodes are going to be removed, then do a second pass and actually remove them as we migrate their data to the nodes they are supposed to be merged with.
Assignee | ||
Comment 5•13 years ago
|
||
This can be simplified once we no longer have mutation events, but it'll be easier to simplify from this than from the current code anyway.
Attachment #541495 -
Flags: review?(bzbarsky)
Comment 6•13 years ago
|
||
Comment on attachment 541495 [details] [diff] [review] Patch to fix r=me
Attachment #541495 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 7•13 years ago
|
||
The previous patch failed on try. I need to reset canMerge in more code paths (i.e. even when the current node is marked as to-be-merged) if there is no following sibling.
Attachment #541760 -
Flags: review?(bzbarsky)
Comment 8•13 years ago
|
||
Comment on attachment 541760 [details] [diff] [review] interdiff r=me
Attachment #541760 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 9•13 years ago
|
||
Pushed to inbound http://hg.mozilla.org/integration/mozilla-inbound/rev/2082bbcf2ce8
Comment 10•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/2082bbcf2ce8
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
Reporter | ||
Updated•13 years ago
|
Severity: normal → critical
Updated•13 years ago
|
tracking-firefox7:
? → ---
Comment 11•13 years ago
|
||
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20100101 Firefox/7.0 I runned the testcase on 7 beta build and Firefox did not crash. Setting resolution to Verified Fixed. Thanks.
Status: RESOLVED → VERIFIED
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•