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)
SeaMonkey
MailNews: Address Book & Contacts
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: lake, Assigned: bryner)
References
Details
(Keywords: access)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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•25 years ago
|
||
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
Comment 2•25 years ago
|
||
couldn't find any dup, reassigning to saari as p4 for M21
Assignee: trudelle → saari
Priority: P3 → P4
Target Milestone: --- → M21
Updated•24 years ago
|
Target Milestone: M21 → Future
Reporter | ||
Comment 3•24 years ago
|
||
Need to have keyboard acess to all parts of the apps
Comment 4•24 years ago
|
||
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•24 years ago
|
||
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-]
Comment 6•24 years ago
|
||
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.
Comment 7•24 years ago
|
||
tabbing/accessibility bug, target mozilla 0.9
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9
Comment 8•24 years ago
|
||
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...
Updated•24 years ago
|
Summary: Tabbing in AB card dialog doesn't cycle to top. → [access]Tabbing in AB card dialog doesn't cycle to top.
Updated•24 years ago
|
Keywords: access
Summary: [access]Tabbing in AB card dialog doesn't cycle to top. → Tabbing in AB card dialog doesn't cycle to top
Comment 10•24 years ago
|
||
-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
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•24 years ago
|
OS: Windows 98 → All
Hardware: PC → All
Comment 12•24 years ago
|
||
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.
Assignee | ||
Comment 13•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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-]
Assignee | ||
Comment 17•24 years ago
|
||
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?)
Assignee | ||
Comment 18•24 years ago
|
||
Assignee | ||
Comment 19•24 years ago
|
||
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.
Assignee | ||
Comment 20•24 years ago
|
||
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•24 years ago
|
||
r=saari for the event state manager changes, but what is the xbl doing?
Comment 22•24 years ago
|
||
r=ben@netscape.com for the tabcontrol changes.
Comment 23•24 years ago
|
||
+ 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.
Assignee | ||
Comment 24•24 years ago
|
||
Is this sufficient to close out the bug?
Assignee | ||
Comment 25•24 years ago
|
||
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?
Assignee | ||
Comment 26•24 years ago
|
||
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
Comment 27•24 years ago
|
||
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
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•