370031 - Cycling through tabindex among HTML inputs only works once

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Alex Vincent [:WeirdAl]]

Attachment: testcase

I discovered this while testing a fix for bug 306058.

Steps to reproduce:
(1) Tab all the way through the document.
(2) Tab past the URL bar and search bar in the main window.
(3) Tab until you land in another HTML input.

Expected results:
You should land in the third HTML input (index 1).

Actual results:
You land in the first HTML input (no index).

requresting blocking1.9: This is actually an accessibility issue, because the next tab doesn't take you to another HTML input - but instead out of the document altogether.

Comment 1

[Alex Vincent [:WeirdAl]]

also seen on Mac trunk build.  OS, Platform -> All.

Comment 2

[Caio Tiago Oliveira (asrail)]

If I click the document with the mouse, then focus the URL bar with Control+L and go tabbing through the document, it jumps the index 1 and follow the rest of the order.

Comment 3

[Alex Vincent [:WeirdAl]]

In nsEventStateManager::GetNextTabbableContent, the stacks are identical; the only difference I can find is that the first time this method gets called, aStartFrame is null and aIgnoreTabIndex is false.  The second time, aStartFrame is not null and aIgnoreTabIndex is true.

Comment 4

[Caio Tiago Oliveira (asrail)]

Sorry... it depends where you click.
Index 2 is the easier to reach, since the whole area bellow it will activate it.

Comment 5

[Jason Bassford]

Fixed by bug 178324.

Comment 6

[hhaamu]

I can still reproduce with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.5pre) Gecko/20091009 SeaMonkey/2.0pre

Comment 7

[Worcester12345]

(In reply to comment #6)
> I can still reproduce with:
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.5pre) Gecko/20091009
> SeaMonkey/2.0pre

How about a current version or trunk?

Comment 8

[hhaamu]

Eh, yeah. Sorry. My fault. I thought that that SeaMonkey version was using trunk.