If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

shift tab does not go backwards in forms

VERIFIED FIXED in Future

Status

()

Core
Event Handling
P3
normal
VERIFIED FIXED
19 years ago
3 years ago

People

(Reporter: cpratt, Assigned: joki (gone))

Tracking

(Blocks: 1 bug, {access})

Trunk
Future
x86
Windows NT
access
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [TESTCASE] erin@imaginet.com, URL)

Attachments

(3 attachments)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Assignee: shuang → don

Updated

19 years ago
Assignee: don → trudelle

Updated

19 years ago
Assignee: trudelle → karnaze

Comment 1

19 years ago
Forms only?  reassigning to karnaze.

Updated

19 years ago
Assignee: karnaze → pollmann
Target Milestone: M6

Updated

19 years ago
Assignee: pollmann → joki

Comment 2

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

Comment 3

19 years ago
Moving out to M7
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M7 → M10
(Assignee)

Comment 4

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

Updated

18 years ago
Whiteboard: makingtest erin@imaginet.com

Comment 5

18 years ago
Created attachment 824 [details]
test case for 4920

Comment 6

18 years ago
Created attachment 841 [details]
new test case

Comment 7

18 years ago
Created attachment 851 [details]
html test page

Updated

18 years ago
Whiteboard: makingtest erin@imaginet.com → [TESTCASE] erin@imaginet.com

Comment 8

18 years ago
This functionality worked for me

Comment 9

18 years ago
*** Bug 10318 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

18 years ago
Component: UE/UI → Event Handling
(Reporter)

Comment 10

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

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 11

18 years ago
This didn't work for a while with gfx widgets but seems to work for me now.
(Reporter)

Comment 12

18 years ago
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...
(Assignee)

Comment 13

18 years ago
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.
(Reporter)

Updated

18 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 14

18 years ago
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

17 years ago
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.
Status: VERIFIED → REOPENED
Keywords: 4xp
OS: other → Windows NT
Resolution: WORKSFORME → ---
Harish, I guess this is a long shot, but do you have any idea why *tabbing* 
would work differently depending on strict/quirks mode?
Target Milestone: M10 → ---
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.
Target Milestone: --- → Future
(Reporter)

Comment 18

17 years ago
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 ***
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Keywords: qawanted
Resolution: DUPLICATE → ---
Keywords: access

Updated

17 years ago
Depends on: 67404

Comment 22

17 years ago
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.

Updated

17 years ago
Depends on: 68332

Updated

16 years ago
Blocks: 83552

Comment 23

16 years ago
Closing this because all known cases work. Reopen only with a specific test 
case please
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED

Comment 24

16 years ago
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

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

Comment 26

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

Status: RESOLVED → VERIFIED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.