Bug 16928 – REGRESSION: {shift+}tabbing into a form element does not restore caret position

• Status: NEW
• Component: HTML Editing

[Eric Seidel (no email)]

tab folllowed by shift-tab does not work as expected (at least on windows)

1. Place your cursor in an editable text region (<textarea>, <iframe> document.designMode= "ON", <div contenteditable>)
2.  type some text "foo bar"
3.  place your cursor between foo and bar
4.  hit tab, followed by shift-tab.

Notice how you cursor is in the wrong place:
<textarea> : colapsed to start
<iframe> : same
<div contenteditable> : entire contents selected

FireFox and IE both get this right in all cases (your cursor is where you left it).

FocusController::advanceFocus() passes false to the element's focus() method. In fact, all callers pass false, which is somewhat strange.

(In reply to comment #1)
> all callers pass false, which is somewhat strange.

I failed to notice that true is the default value and some callers call focus(). Looking at <http://trac.webkit.org/projects/webkit/changeset/20072> it seems like the tabbing case is covered by the test from that patch, but some of the currently checked-in results say FAIL. Running the test manually I do not get the expected results in the tab test.

I suspect that a regression occurred some time after r20072.

[Ojan Vafai]

Just to clarify, Firefox and Opera get this right. IE puts your cursor at the end of the region you tab back into.

[Eric Seidel (no email)]

Per mitz's comments, marking this a Regression.  Regressions are p1.

[Adam Roben (:aroben)]

<rdar://problem/5722640>

[Justin Garcia]

hello world

[Ojan Vafai]

Created attachment 21961 [details]
test case with programmatic focus/blur that also breaks

[Ojan Vafai]

To be clear this is a more generic problem with blurring and focusing editable nodes. I attached a test case that shows a contentEditable element with the first letter selected. Then after a second it focuses another element and then focuses back on that element. In IE/FF the first letter ("f") is still selected. In WebKit, the entire contents of the contentEditable element is selected.

FWIW, I just ran into a bug this causes with the find feature of my intranet's wiki software.