Bug 51211

Summary:

bluring and focusing contentEditable region doesn't preserve cursor position

Product:

WebKit

Reporter:

Nick Santos <nicksantos>

Component:

HTML Editing

Assignee:

Nobody <webkit-unassigned>

Status:

NEW

Severity:

Minor

CC:

adele, ap, darin, enrica, jparent, kalman, rniwa

Priority:

Keywords:

GoogleBug

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Attachments:

Description	Flags
An interactive demo for contentEditable cursor position	none

Nick Santos

Reported 2010-12-16 13:35:28 PST

Repro steps: 1. Select text in a contentEditable area 2. Click on a blank area of the document. 3. Call focus() on the contentEditable area from JS Expected behavior: The cursor position should be preserved. This is the behavior we see with textareas. Actual behavior: Chrome moves the cursor to the start of the region. Safari selects the region. Ojan says that Safari at trunk performs like Chrome.

Attachments
An interactive demo for contentEditable cursor position (1.37 KB, text/html) 2010-12-16 13:37 PST, Nick Santos	no flags	Details
View All Add attachment proposed patch, testcase, etc.

Nick Santos

Comment 1 2010-12-16 13:37:52 PST

Created attachment 76809 [details] An interactive demo for contentEditable cursor position

Nick Santos

Comment 2 2010-12-16 13:44:44 PST

FWIW, this bug is a reduction of a problem in Google Spreadsheets. You can repro the problem like so: 1) Go to docs.google.com 2) Create a new spreadsheet. 3) double-click on cell A1 and type "=SUM(" 4) Click a blank region at the top of the page. 5) Click cell A2 on the grid. Expected behavior The contents of the cell become "=SUM(A2" Actual behavior The contents of the cell become "A2=SUM("

Ojan Vafai

Comment 3 2010-12-16 13:47:55 PST

The fix for this would be to maintain a selection when we blur the root editable node and reselect it when we focus the root editable node. We already do this for text inputs IIRC to make selectionStart/selectionEnd work. I think this makes sense to do for contentEditable as well. This is especially frustrating for web developers because there is no blur event that reliably fires before the selection is cleared.

Ojan Vafai

Comment 4 2010-12-16 13:49:38 PST

Another case where this causes problems is making keyboard accessible toolbars for rich-text areas. The toolbar needs focus to be keyboard accessible, but that clears the selection. So you have to store the selection before it's blurred. Right now, you have to capture all the places in your code that might blur the rich-text area.

Alexey Proskuryakov

Comment 5 2011-09-19 10:15:40 PDT