4920 - shift tab does not go backwards in forms

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[cpratt]

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.

Comment 1

[Peter Trudelle]

Forms only?  reassigning to karnaze.

Comment 2

[Claudius Gayle]

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

Comment 3

[joki (gone)]

Moving out to M7

Comment 4

[joki (gone)]

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

Comment 5

[Erin Pierce]

Attachment: test case for 4920

Comment 6

[Erin Pierce]

Attachment: new test case

Comment 7

[Erin Pierce]

Attachment: html test page

Comment 8

[Erin Pierce]

This functionality worked for me

Comment 9

[Nick Beaudrot]

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

Comment 10

[cpratt]

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

Comment 11

[joki (gone)]

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

Comment 12

[cpratt]

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...

Comment 13

[joki (gone)]

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.

Comment 14

[cpratt]

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.)

Comment 15

[Antti Näyhä]

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.

Comment 16

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 17

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 18

[cpratt]

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.

Comment 19

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 20

[Hixie (not reading bugmail)]

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

Comment 21

[Hixie (not reading bugmail)]

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.

Comment 22

[HJ]

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.

Comment 23

[saari (gone)]

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

Comment 24

[jsp]

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.

Comment 25

[jsp]

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

Comment 26

[Madhur Bhatia]

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