Bug 12517

Summary:

REGRESSION: Tab order incorrect when input inside frame/iframe gets initial focus

Product:

WebKit

Reporter:

David Kilzer (:ddkilzer) <ddkilzer>

Component:

Forms

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

KwhiteRight

Priority:

Keywords:

EasyFix, HasReduction, InRadar, Regression

Version:

420+

Hardware:

Mac

OS:

OS X 10.4

Attachments:

Description	Flags
Test focus (no frames; works as expected)	none
Test frame focus (does not work as expected)	none
Test iframe focus (does not work as expected)	none
Patch with ChangeLog and test	darin: review+

David Kilzer (:ddkilzer)

Reported 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).

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
View All Add attachment proposed patch, testcase, etc.

David Kilzer (:ddkilzer)

Comment 1 2007-01-31 16:47:45 PST

Created attachment 12840 [details] Test focus (no frames; works as expected)

David Kilzer (:ddkilzer)

Comment 2 2007-01-31 16:48:28 PST

Created attachment 12841 [details] Test frame focus (does not work as expected)

David Kilzer (:ddkilzer)

Comment 3 2007-01-31 16:48:58 PST

Created attachment 12842 [details] Test iframe focus (does not work as expected)

Mark Rowe (bdash)

Comment 4 2007-02-01 18:43:19 PST

<rdar://problem/4971227>

Adam Roben (:aroben)

Comment 5 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.

Adam Roben (:aroben)

Comment 6 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.

Adam Roben (:aroben)

Comment 7 2007-02-14 18:19:48 PST

Created attachment 13177 [details] Patch with ChangeLog and test

Darin Adler

Comment 8 2007-02-14 18:38:53 PST

Comment on attachment 13177 [details] Patch with ChangeLog and test r=me

Adam Roben (:aroben)

Comment 9 2007-02-14 19:28:43 PST

Landed as r19636

Note You need to log in before you can comment on or make changes to this bug.