Bug 46856 – [Chromium] Tabbing into page doesn't always select the first element

• Component: Platform
• Status: RESOLVED FIXED

[Avi Drissman]

Upstream of http://code.google.com/p/chromium/issues/detail?id=57344 :

What steps will reproduce the problem?
1. Load http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/focus/typical_page.html
2. Click in the omnibox
3. Press [tab] once

Result: search field has focus (correct).

4. Click in the omnibox
5. Press [tab] once

Result: the search button has focus (incorrect).

Every time you tab into a web view, the first element in that view should gain focus (or the last element, if you reverse-tab in).

The bug: in WebViewImpl::setInitialFocus (WebKit/WebKit/chromium/src/WebViewImpl.cpp), just a tab keystroke is fired off. That works the first time when the page is initially loaded since no page object has the focus, but in subsequent calls it just advances the focus (incorrectly).

Compare to WebKit/WebKit/win/WebView.cpp's version which explicitly calls setFocusedNode(0) to reset the focus before advancing using the focus controller.

Broken on all platforms but the Mac (in which this initial focus code is even _more_ broken; see http://code.google.com/p/chromium/issues/detail?id=49738).

[Avi Drissman]

Created attachment 69278 [details]
Patch to fix; modeled after win/WebView.cpp and mac/WebHTMLView.mm

[Kenneth Russell]

Comment on attachment 69278 [details]
Patch to fix; modeled after win/WebView.cpp and mac/WebHTMLView.mm

This looks OK to me based on comparison to mac/WebView/WebHTMLView.mm and win/WebView.cpp.

[WebKit Commit Bot]

Comment on attachment 69278 [details]
Patch to fix; modeled after win/WebView.cpp and mac/WebHTMLView.mm

Clearing flags on attachment: 69278

Committed r68765: <http://trac.webkit.org/changeset/68765>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.