645820 - Caret sticks around after contenteditable element is removed

Status: NEW

(Core :: DOM: Editor, defect)

Description

[Sidney San Martín]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
Build Identifier: 4.0

When a contenteditable element is removed from the document, its insertion point jumps to the top left corner of the first ancestor which is still present.

Related, when a contenteditable element is made not contenteditable, it stays focused and its insertion point sticks around.

Reproducible: Always

Steps to Reproduce:
1. Create a contenteditable element
2. Remove it from the document while it has focus. (Or, for the other side of this bug, remove its contenteditable attribute while it has focus.
Actual Results:  
The insertion point sticks around, and attaches itself to the first remaining ancestor in the document. In certain styling cases, the insertion point may be HUGE (i.e. the full height of the parent element).

Expected Results:  
The element loses focus and the insertion point goes away.

Comment 1

[Sidney San Martín]

Attachment: Test case

Comment 2

[Sidney San Martín]

Attachment: Test case

Fix a typo in the test case.

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

Confirmed against Mozilla/5.0 (Windows NT 5.1; rv:2.2a1pre) Gecko/20110328 Firefox/4.2a1pre ID:20110328030450

Comment 4

[Alex Lakatos[:AlexLakatos]]

Confirmed Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.2a1pre) Gecko/20110331 Firefox/4.2a1pre

Comment 5

[(no longer active)]

We currently only hide the caret when the editable element loses focus.  This is arguably wrong, and I think we should make sure that when we're not in the caret browsing mode, we only show the caret when it's attached to an editable element.

Sidney, is this bug happening for you on a website that you own or use?

Comment 6

[Sidney San Martín]

(In reply to comment #5)
> We currently only hide the caret when the editable element loses focus.  This
> is arguably wrong, and I think we should make sure that when we're not in the
> caret browsing mode, we only show the caret when it's attached to an editable
> element.
> 
> Sidney, is this bug happening for you on a website that you own or use?

Gotcha. Yep, you can currently reproduce it at <http://distro.fm/#/find>: search for a network (e.g. eardrumnyc) and hit return. We’re going to put in a workaround eventually, but for the moment the insertion point sticks around, attached to the network’s landing page.