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
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.
Created attachment 494298 [details] [diff] [review] Patch (v1)
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: review?(roc) → review+
Attachment #494298 - Flags: approval2.0?
Attachment #494298 - Flags: approval2.0? → approval2.0+
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla2.0b8
blocking2.0: ? → final+
Crash Signature: [@ nsEditorUtils::IsDescendantOf]
You need to log in before you can comment on or make changes to this bug.