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).
Created attachment 69278 [details] Patch to fix; modeled after win/WebView.cpp and mac/WebHTMLView.mm
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.
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>
All reviewed patches have been landed. Closing bug.