[Webkit-unassigned] [Bug 17638] New: JavaScript-heavy game site breaks tab-key behavior

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=17638

           Summary: JavaScript-heavy game site breaks tab-key behavior
           Product: WebKit
           Version: 525+ (Nightly build)
          Platform: Macintosh
               URL: http://www.wordsplay.net
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Minor
          Priority: P2
         Component: Evangelism
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jubal-webkit at cheeze.org


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.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.