Summary: When an <input> element inside a <frame> or an <iframe> gets the initial focus on the page, the tabbing order is incorrect. Steps to reproduce #1: 1. Open Safari/WebKit. 2. Open one of the two attached test cases. 3. Hit Tab. Expected results #1: Next <input> element should be focused. Actual results #1: Either "nothing" happens (focus does not change), or focus changes to address bar. Steps to reproduce #2: 4. Hit Cmd-R (or the Reload button in Safari). 5. Hit Tab again. Expected results #2: Next <input> element should be focused. Actual results #2: Focus changes to address bar. Further tabs to to the Google search, then back to the initially focused <input> element again, then finally to the second <input> element. Regression: This is a regression from shipping Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037). Tested with a locally-built debug build of WebKit r19315 with afari 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037).
Created attachment 12840 [details] Test focus (no frames; works as expected)
Created attachment 12841 [details] Test frame focus (does not work as expected)
Created attachment 12842 [details] Test iframe focus (does not work as expected)
<rdar://problem/4971227>
With the frame test it takes me 3 tab presses to move focus from the first <input> to the second. With the iframe test it takes me 2 tab presses to move focus from the first <input> to the second. In both test cases, Shift-Tab first moves focus to the second <input>, then back to the first, and focus moves correctly from then on.
I suspect that the cause for this is HTMLInputElement::focus is not resulting in the focused frame getting set correctly. Should be a pretty simple fix.
Created attachment 13177 [details] Patch with ChangeLog and test
Comment on attachment 13177 [details] Patch with ChangeLog and test r=me
Landed as r19636