Bug 12517 - REGRESSION: Tab order incorrect when input inside frame/iframe gets initial focus
Summary: REGRESSION: Tab order incorrect when input inside frame/iframe gets initial f...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P1 Normal
Assignee: Nobody
URL:
Keywords: EasyFix, HasReduction, InRadar, Regression
Depends on:
Blocks:
 
Reported: 2007-01-31 16:46 PST by David Kilzer (:ddkilzer)
Modified: 2007-02-14 19:28 PST (History)
1 user (show)

See Also:


Attachments
Test focus (no frames; works as expected) (136 bytes, text/html)
2007-01-31 16:47 PST, David Kilzer (:ddkilzer)
no flags Details
Test frame focus (does not work as expected) (403 bytes, text/html)
2007-01-31 16:48 PST, David Kilzer (:ddkilzer)
no flags Details
Test iframe focus (does not work as expected) (264 bytes, text/html)
2007-01-31 16:48 PST, David Kilzer (:ddkilzer)
no flags Details
Patch with ChangeLog and test (14.30 KB, patch)
2007-02-14 18:19 PST, Adam Roben (:aroben)
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Kilzer (:ddkilzer) 2007-01-31 16:46:16 PST
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).
Comment 1 David Kilzer (:ddkilzer) 2007-01-31 16:47:45 PST
Created attachment 12840 [details]
Test focus (no frames; works as expected)
Comment 2 David Kilzer (:ddkilzer) 2007-01-31 16:48:28 PST
Created attachment 12841 [details]
Test frame focus (does not work as expected)
Comment 3 David Kilzer (:ddkilzer) 2007-01-31 16:48:58 PST
Created attachment 12842 [details]
Test iframe focus (does not work as expected)
Comment 4 Mark Rowe (bdash) 2007-02-01 18:43:19 PST
<rdar://problem/4971227>
Comment 5 Adam Roben (:aroben) 2007-02-07 01:52:33 PST
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.
Comment 6 Adam Roben (:aroben) 2007-02-07 02:03:58 PST
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.
Comment 7 Adam Roben (:aroben) 2007-02-14 18:19:48 PST
Created attachment 13177 [details]
Patch with ChangeLog and test
Comment 8 Darin Adler 2007-02-14 18:38:53 PST
Comment on attachment 13177 [details]
Patch with ChangeLog and test

r=me
Comment 9 Adam Roben (:aroben) 2007-02-14 19:28:43 PST
Landed as r19636