40611 - Tabbing in AB card dialog doesn't cycle to top

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P1)

Description

[Lakespur Roca]

This was implimented and you can no longer use tab to jump from field to field 
in the New Card dialog in the Addressbook.

Build ID: 2000052508

Comment 1

[scottputterman]

I'm able to use tab to go through the dialog the first time, but when I try to 
cycle through, tab seems to stop working. This might be a dup of another bug 
dealing with shift-tab.  reassigning to trudelle.

Comment 2

[Peter Trudelle]

couldn't find any dup, reassigning to saari as p4 for M21

Comment 3

[Lakespur Roca]

Need to have keyboard acess to all parts of the apps

Comment 4

[saari (gone)]

You can tab through the first time and shift-tab, but it doesn't cycle one it 
hits the end. Not sure why, this works in other places.

Comment 5

[Peter Trudelle]

You do have keyboard access to every field, it just doesn't cycle around. You
can still back up with shift-Tab, which is a discoverable work-around. I don't
see how that rates as UE1, but it doesn't make our cut.  nsbeta3-, please supply
details if you disagree.

Comment 6

[selmer (gone)]

Changing summary to reflect consensus of what this bug is about.  It appears 
that field to field tabbing generally works.

Comment 7

[saari (gone)]

tabbing/accessibility bug, target mozilla 0.9

Comment 8

[Becki Sanford]

When using either the Mozilla M18 baseline or build ID 20001113009, when tabbing
out of the last field, it actually moves to the first field of the next tab. 
For example, if you're on the Cellular field of Name tab and hit tab and then
type something, then click on the Address tab, you'll see your text displayed
there.

It's not that the tab isn't work, it's just that you can't SEE where it's
working...

Comment 9

[pmock]

Changing qa assign.

Comment 10

[Peter Trudelle]

-bryner. Brian - Chris is swamped, could you take this on? 
Accessiblity requirements specify stopping at the last item, and giving
appropriate feedback. I hope we don't need separate behavior for accessibility,
but if so, perhaps we could either wrap or stop, depending on some pref, yet
give feedback in either case.  cc'ing german for usability input.

Comment 11

[Brian Ryner (not reading)]

accessibility bugs -> P1.

Comment 12

[Matthew T (active 1999-2002)]

I would be highly surprised if there are any accessibility requirements which 
require stopping at the last item. I haven't seen any native Windows app do that.

Comment 13

[Brian Ryner (not reading)]

What actually seems to be happening here is that when you tab past the last
field on some pane, it's shifting focus to the first textfield in the next pane;
this pane isn't being made active though.

How do we want this to work - should it cycle through all 3 panes, then to OK
and Cancel, or should you have to manually switch panes (making the tabbing go
to OK after the last textfield) ?

Comment 14

[Matthew T (active 1999-2002)]

As with native Windows tabbed windows, (Shift+)Control+Tab should navigate 
between tab panels, and (Shift+)Tab should navigate between controls in the 
active tab. Tabbing to `Ok' and `Cancel' is not required, as they are covered by 
Enter and Escape respectively. (Actually, since this is a document window, it 
shouldn't have `Ok' and `Cancel' buttons at all.)

Implementation notes:

(1) Unlike most Control+whatever keyboard shortcuts, where Command+whatever is
    used on Mac OS instead, in this case (Shift+)Control+Tab should be used on
    both Windows and Mac OS for navigating between tabs. ((Shift+)Command+Tab on
    Mac OS is reserved for switching between applications.)

(2) This navigation should apply to the <tabcontrol> element in general, not the
    address book card window in particular. In other words, as soon as you fix
    this bug, navigation of the bookmark properties window should start working
    properly as well.

Comment 15

[timeless]

w2k my documents properties.
focus begins in target [%USERPROFILE%\My Documents]
tab=>restore default, move, find target
tab=>ok, cancel, {apply}
tab=>target
 arrow=>general, sharing 
or
 tab=>first element of current tab

Ok and Cancel *should* be in the tab sequence.  some nc4 dialogs managed to 
have tab dialogs where ok is keyboard inaccessible (enter didn't work, and 
since that's the only way to make a change, it was a major flaw), cancel was 
also not tab accessible, but who cares about canceling...

Comment 16

[fenella]

QA-assign-to fenella.

Comment 17

[Brian Ryner (not reading)]

cc'ing ben, since he appears to own <tabcontrol>.

It looks like there are two things we need to do, implementation-wise:

- prevent items in non-active panes of the <deck> from being tabbed to (this is
just a css property we set, right?)
- provide a keybinding for control+tab to change tabs (i'm xbl-ignorant... how
hard is this?)

Comment 18

[Brian Ryner (not reading)]

Attachment: patch

Comment 19

[Brian Ryner (not reading)]

This patch does two things:

- provide ctrl+tab/ctrl+shift+tab bindings to navigate between tabs in <tabcontrol>

- don't focus frames inside hidden views, this prevents tabbing to hidden panes
of the deck.

Comment 20

[Brian Ryner (not reading)]

Note that cycling through the dialog forwards works ok, but backwards does not.
 There are some other issues going on there that saari and I were investigating.

Comment 21

[saari (gone)]

r=saari for the event state manager changes, but what is the xbl doing?

Comment 22

[Ben Goodger (use ben at mozilla dot org for email)]

r=[e-mail] for the tabcontrol changes. 

Comment 23

[Blake Ross]

+    while (frameView) {
+      nsViewVisibility visib;
+      frameView->GetVisibility(visib);
+      if (visib == nsViewVisibility_kHide

Do we need |visib|'s declaration to be in the loop?

Other than that nit, r=blake for all of it.

Comment 24

[Brian Ryner (not reading)]

Is this sufficient to close out the bug?

Comment 25

[Brian Ryner (not reading)]

This is fixed based on the bug summary, but some of the comments in the bug
point to other issues, such as optionally *not* wrapping around.  Should these
be moved to new bugs?

Comment 26

[Brian Ryner (not reading)]

This is fixed, at least according to the bug summary and original complaint. 
Please file any other accessibility requirements as separate bugs.

Comment 27

[fenella]

Linux (2001-03-13-08 mtrunk)
Win32 (2001-03-13-10 mtrunk)
Mac (2001-03-13-10 mtrunk)
OK using these builds.