Created attachment 254707 [details] 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.
also seen on Mac trunk build. OS, Platform -> All.
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.
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.
Sorry... it depends where you click. Index 2 is the easier to reach, since the whole area bellow it will activate it.
Fixed by bug 178324.
I can still reproduce with: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:18.104.22.168pre) Gecko/20091009 SeaMonkey/2.0pre
(In reply to comment #6) > I can still reproduce with: > Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:22.214.171.124pre) Gecko/20091009 > SeaMonkey/2.0pre How about a current version or trunk?
Eh, yeah. Sorry. My fault. I thought that that SeaMonkey version was using trunk.