455992 - contenteditable span misbehaves after inserting a space at the beginning of the element

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Boris Smus]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

by inserting a space followed by at least one character at the beginning of a contenteditable span, then hitting backspace repeatedly, weird behavior occurs.

Reproducible: Always

Steps to Reproduce:
1. Click into a <span> content editable element such that the cursor is before the first character inside it. Here is the simplest document I could reproduce it with:

<div/>
<span contenteditable="true">X</span>


2. Insert a space and then a character
3. Hit delete repeatedly
Actual Results:  
Behaves as if an extra space was inserted into the beginning of the span.

Expected Results:  
Should just delete the text before the cursor, as in a normal backspace.

I'm currently working around the problem by using a div with display: inline; why this works is a mystery to me, since I thought spans were exactly that: syntactic sugar for inline divs.

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase

Another STEPS TO REPRODUCE:
type SPACE at the beginning of the line => the SPACE is inserted outside
(before) the <span>.

Comment 2

[Mats Palmgren (inactive)]

Maybe same underlying bug as bug 449685?

Comment 3

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

The problem is that GetBlockNodeParent() steps out of the editable subtree
for an inline.  This patch introduces a new method that searches for the
closest block only within the editable subtree, or if there is none, uses
the subtree root.  It fixes nsWSRunObject.

It seems likely there are other GetBlockNodeParent() callers that also
should constrain the search...

Comment 4

[Mats Palmgren (inactive)]

I filed a new bug 456244 which seems like a similar problem.
Bug 449685 seems unrelated though.

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

yeah, very painful bug ; a lot of contenteditable users hit it apparently.

Comment 6

[Peter Van der Beken [:peterv]]

Comment on attachment 339631 [details] [diff] [review]
Patch rev. 1

>diff --git a/editor/libeditor/html/nsWSRunObject.cpp b/editor/libeditor/html/nsWSRunObject.cpp

>+    nsresult rv = wsBoundingParent->GetParentNode(getter_AddRefs(parent));
>+    if (NS_FAILED(rv) || !parent || !mHTMLEditor->IsEditable(parent))

No need for rv and the NS_FAILED check, checking for null should be enough.

Comment 7

[Mats Palmgren (inactive)]

Pushed with the nit fixed:
http://hg.mozilla.org/mozilla-central/rev/59cb55e08d1f

-> FIXED