Closed Bug 40611 Opened 25 years ago Closed 24 years ago

Tabbing in AB card dialog doesn't cycle to top

Categories

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

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9

People

(Reporter: lake, Assigned: bryner)

References

Details

(Keywords: access)

Attachments

(1 file)

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
QA Contact: lchiang → esther
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.
Assignee: putterman → trudelle
couldn't find any dup, reassigning to saari as p4 for M21
Assignee: trudelle → saari
Priority: P3 → P4
Target Milestone: --- → M21
Target Milestone: M21 → Future
Need to have keyboard acess to all parts of the apps
Keywords: nsbeta3, UE1
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.
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.
Whiteboard: [nsbeta3-]
Changing summary to reflect consensus of what this bug is about. It appears that field to field tabbing generally works.
Summary: can not use keyboard to navigate the new cards dialog → Tabbing in AB card dialog doesn't cycle to top.
tabbing/accessibility bug, target mozilla 0.9
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9
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...
Changing qa assign.
QA Contact: esther → pmock
Summary: Tabbing in AB card dialog doesn't cycle to top. → [access]Tabbing in AB card dialog doesn't cycle to top.
Keywords: access
Summary: [access]Tabbing in AB card dialog doesn't cycle to top. → Tabbing in AB card dialog doesn't cycle to top
-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.
Assignee: saari → bryner
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
accessibility bugs -> P1.
Priority: P4 → P1
OS: Windows 98 → All
Hardware: PC → All
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.
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) ?
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.
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...
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
QA-assign-to fenella.
QA Contact: pmock → fenella
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?)
Attached patch patch (deleted) — Splinter Review
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.
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.
r=saari for the event state manager changes, but what is the xbl doing?
+ 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.
Is this sufficient to close out the bug?
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?
This is fixed, at least according to the bug summary and original complaint. Please file any other accessibility requirements as separate bugs.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Linux (2001-03-13-08 mtrunk) Win32 (2001-03-13-10 mtrunk) Mac (2001-03-13-10 mtrunk) OK using these builds.
Status: RESOLVED → VERIFIED
Keywords: UE1
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: