1091428 - near-null crash backspacing in contenteditable element

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[Tsubasa Iinuma]

Attachment: File that phenomenon occurs.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141027150301

Steps to reproduce:

1. Open the attached file.(index.html)
2. Click the letter "X".
3. Press the Enter key.
4. Press the Backspace key.


Actual results:

Firefox crashed.


Expected results:

Firefox does not crash.

Comment 1

[Daniel Veditz [:dveditz]]

bp-ff903983-5234-4f87-8825-2b2952141101

Signature matches bug 1057677, but that one should be fixed in Firefox 33 (I can confirm this still crashes in Firefox 33).

The steps to reproduce are similar to the Thunderbird crash bug 1066232 (backspacing in the editor) and the signatures match.

This appears to be a null deref crash, unlikely to be exploitable so I'm unhiding the bug.

Comment 2

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

The signature is different from bug 1057677.  The caller there is nsHTMLEditor::DoInsertHTMLWithContext, while the caller here is nsHTMLEditRules::WillDeleteSelection.  nsTextEditUtils::IsBreak, as currently written, will crash if passed a null node, so the caller is what's interesting.

Comment 3

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

I can't reproduce the bug in a local build.  Instead, backspacing does nothing.  This may be due to local patches that I'll check in soon (bug 1086349 and bug 1088054).  Try again on a nightly once those patches land (should be within a couple of days) and see if the crash is fixed.  The behavior is still buggy, but not a crash, and it doesn't bother me if it's <xmp>-specific.

Comment 4

[Jesse Ruderman]

Doesn't crash or assert for me using Firefox Nightly on Mac. I tried a few variants of step 2 (click before X, click after X, drag to select the X).

I filed bug 1151604 for the "backspace does nothing" issue.