Apologies for the poor summary; I don't have a reduction so I don't understand what's actually broken underneath the JavaScript on this site. Will change the summary name if there are any suggestions for a better one. I frequent an online game site, www.wordsplay.net. There are two cases of incorrect behavior: 1. The site presents a login screen, where the keyboard input is focused on the "Your Email" field. Hitting tab once moves you from this field to the next one, "Password". Hitting tab again causes the browser's URL field to gain focus. This is wrong; the action should focus on the next selectable item, which is the checkbox for "This is a public or shared computer[...]" label, and the next tab-key action after that is to focus on the "Log in" button. The broken behavior is when the Tab key moves the focus to the browser's URL field. The desired behavior is when the Tab key moves the focus to the next selectable item. 2. This problem is seen again after successful login if the user chooses the "Choose Game Name" link. This results in a window that appears in the middle of the browser. This window has two fields, "Your Name" and "Your Team". The tab-key action successfully moves focus from the first to the second field, but the next action moves focus to the browser's URL field, which is incorrect. I do not know if this is a problem with WebKit or with the site itself. I can confirm that the behavior for both cases above is correct inside Camino 1.6 beta 2, Windows Firefox 2.0.x, and Windows Firefox 3.0 beta 4+. However, it is incorrect (in the same manner as described above) for Mac Firefox 2.0.x. and 3.0 beta 4+. I find it interesting that Camino is the only Mac browser to behave correctly for the above two cases. There is a final bug, perhaps belonging to the site's code and not to WebKit. Attempting to dismiss the window in case #2 fails when using the keyboard only, as the window remains up front while any _successive_ keyboard actions (including tab key) cause effects behind the window, such as rotating the game board. The user must mouse to the close button in the upper right corner of the window to actually get rid of the window.
1) is controlled by the "Full keyboard access" setting in the Keyboard & Mouse pane of System Preferences. Switching it to "All Controls" causes it to behave as you expect in Safari. I didn't bother registering for an account but it sounds like 2) would probably be resolved by the same setting. If this in fact the case then WebKit is behaving as designed. I would appreciate if you could confirm whether the setting mentioned above does resolve 2) as well. Does the third issue also occur in other browsers?
Dang, I didn't know about that keyboard option. Bless you! That seems to have solved my problem for all three issues in WebKit. In reply to your question, the third issue exists for Windows Firefox 3 and Mac Firefox 2 as well (haven't tested Windows FF2 yet). WebKit seems fine...
Wonderful! It might be worth filing a bug report against Firefox for the third issue if it reproduces, and perhaps for the first two issues if the "Full keyboard access" preference did not resolve it in Firefox too. Closing as WORKSFORME as there was no WebKit bug here.