when you are tabbing through the elements on a page, pressing shift-tab should take you to the previous input field or element or what have you. although pressing tab at the url above correctly takes you to the next field, pressing shift-tab does nothing.

Forms only? reassigning to karnaze.

QA assigning several orphaned UI/UE bugs. cpratt, I'm giving you the ones you wrote :-), and I'll take the rest.

Moving out to M7

It does kinda work on simple pages. Need to work out the more complex behavior. Changing milestone.

This functionality worked for me

*** Bug 10318 has been marked as a duplicate of this bug. ***

I'm guessing that the assigned component was incorrect. This functionality is missing entirely from the 1999082616 build using GFX widgets under NT.

This didn't work for a while with gfx widgets but seems to work for me now.

I haven't been able to tab through form elements in aeons on Windows. I suppose I'll eventually be able to verify this fix when that's working...

I just tried tabbing again last night and it works for me. There are still occasional issues with gfx text fields and selects but rods is working on those.

This is fixed. 1999092909 build, NT. (And I was able to tab all along; the problem is that tabbing always goes from the text input control to the first item on the page and not the next t.i.c... caveat emptor/user.)

Shift+Tab mostly doesn't work on my 2000-08-09-08 build (WinNT4 SP6a). This happens on several test cases, including the attached one called 'html test case'. There are some pages where Shift+Tab does work, but only in Strict mode. For example, see http://bugzilla.mozilla.org/showattachment.cgi?attach_id=712 Shift+Tab works on that one, but stops working if you change the DOCTYPE to a Transitional one. Somehow I don't think this is an intentional quirk. Reopening and adding '4xp' keyword.

Harish, I guess this is a long shot, but do you have any idea why *tabbing* would work differently depending on strict/quirks mode?

This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

If this is not fixed, NS6 remains completely unusable for myself and others. OTOH I understand that there may be little to no support for those unable or unwilling to use pointing devices in the first release - so if you feel this is unimportant, that's your call.

We are aware of this. Unfortunately there are simply too many focus-related bugs to get them all fixed by 6.0. Or at least it appears to be so. However, a lot of focus issues ARE being addressed as well, so it could be that as things settle down for nsbeta3, it might be we could revisit focus and accessibility issues for rtm. But don't hold your breath.

*** This bug has been marked as a duplicate of 51196 ***

oops, this is now the third time I've done that. Terribly sorry. What I *meant* to do, was say: I've looked at this bug, and I've made testcases and played around and pressed tab, and clicked while holding shift, and all sorts of things. My conclusions are as follows (Windows 2000 commercial build 6.0.18.2000090508): 1. Floats confuse tabbing, especially backwards tabbing. 2. Shift+Tab does work in many cases, like the Bugzilla form. 3. We do funky things with the "align" attribute of the <input> element. 4. If you click while shift is held down, then things are more likely to go wrong -- in my tests, it would make a normal tab go backwards sometimes. 5. This bug is not always directly dependant on the page. I have had pages that both work and don't work, depending on other factors such as resizing the window, refreshing the page, and switching focus to other applications and back. cpratt: I think we need some better testcases here, because at the moment I, for one, can't tell what the exact problem is. If you can narrow the problem down, especially if you can find exact ways to reproduce it, then this has a better chance of being fixed.

shift-tab should work with and without tabindex activated and that's not the case. shift-tab isn't limited to tabindex, so that should work also.

Closing this because all known cases work. Reopen only with a specific test case please

I'll let someone else decide whether to reopen. One of the attachments for bug 68332 (http://bugzilla.mozilla.org/attachment.cgi?id=24910&action=view) works fine when tabbing forward, but back-tabbing into the content skips two of the three links on the page.

Almost forgot...I'm running Mozilla 2001100103 in Windows 2000.

wfm on win200 buildID : 2001-10-03-05-0.9.4 (branch build) marking verified.