Closed Bug 615450 Opened 9 years ago Closed 9 years ago

Crash [@ nsEditorUtils::IsDescendantOf]

Categories

(Core :: DOM: Editor, defect, critical)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla2.0b8
Tracking Status
blocking2.0 --- final+

People

(Reporter: jruderman, Assigned: ehsan)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, crash, testcase)

Crash Data

Attachments

(3 files)

No description provided.
Attached file stack trace
I can't reproduce the crash, but I debugged this and I think I have a handle on what happens here, and in the other editor related test cases which trigger the mismatched update view count assertions (this one does that for me).

What's happening is that some operations in the editor insert and remove nodes from the document (for example, for splitting a node).  One such operation is outdenting.

When this happens, if that node is the last contenteditable node in the document, the editor will reinitialize on the document, which replaces the edit rules object, among other symptoms.

In this test case, for example, when the outdent command is in progress, we split the div element, which removes and reinserts the contenteditable span under it, which triggers a reinitialization of the editor on the document.

When this happens, the new rules object has no notion of the previous update view count and action nesting, so it will happily corrupt those values, leading into update view count mismatches (and possibly crashes).  Basically, with something like that happening, all bets are off, and anything could happen!

I have a patch which tackles one approach of preventing that from happening, I'm testing it right now...

I think this needs to block 2.0.
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Keywords: assertion
blocking2.0: --- → ?
To elaborate, this _does_ crash nightlies, it doesn't crash my local build (which has the patch to bug 612128, which I think is responsible for making the behavior more benign here).  Nevertheless, even with the fix to bug 612128, this is a bug very much worth fixing in its own right.
Blocks: 615015
Attached patch Patch (v1)Splinter Review
Attachment #494298 - Flags: review?(roc)
If we destroy an nsHTMLEditRules while its mRestoreContentEditableCount is true, doesn't that a call to ChangeContentEditableCount(-1) is lost?
(In reply to comment #5)
> If we destroy an nsHTMLEditRules while its mRestoreContentEditableCount is
> true, doesn't that a call to ChangeContentEditableCount(-1) is lost?

It would, but that shouldn't happen, since the only way for nsHTMLEditRules to be destroyed is for the editor to be reinitialized, and that is triggered by contenteditable count reaching zero.
Attachment #494298 - Flags: approval2.0?
Whiteboard: [needs landing]
http://hg.mozilla.org/mozilla-central/rev/92d0320fb62e
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla2.0b8
Crash Signature: [@ nsEditorUtils::IsDescendantOf]
You need to log in before you can comment on or make changes to this bug.