tab focus skips non-visible (scrolled-off) controls in listbox

VERIFIED FIXED in mozilla1.0



Keyboard: Navigation
16 years ago
16 years ago


(Reporter: Sean Su, Assigned: Brian Ryner (not reading))




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [ADT2])


(1 attachment, 1 obsolete attachment)

3.82 KB, patch
Ben Goodger (use ben at mozilla dot org for email)
: review+
Joe Hewitt (gone)
: superreview+
Details | Diff | Splinter Review


16 years ago
Steps to reproduce:
1) run mozilla
2) bring up a mail compose window (Ctrl-M)
3) enter addressees until the scrollbar appears
4) starting with the focus on the first addressee, press the TAB key.  Notice
that once the focus reaches the last visible address field, it does not attempt
to scroll the next field into view before the focus goes to the subject textbox.

expected behavior:
Hitting (shift) tab should scroll the next address field into view and bring the
focus there.
aaronl, d'you perchance know if this has already been reported? just curious...

side note: when using shift+tab to go upwards, i noticed that --as with Sean's
case-- the focus doesn't go to previous addressee entry. instead it jumps to the
From menulist. [tested on linux rh7.2, 2002.02.08.08 comm]
Keywords: nsbeta1
OS: Windows 2000 → All
Hardware: PC → All

Comment 2

16 years ago
Nav Triage: marking nsbeta1+ - looks like this will continue to be a problem and
has relatively high visibility/accessiblity impact.
Keywords: nsbeta1 → nsbeta1+

Comment 3

16 years ago
Mass move of nsbeta1+ bugs that didn't have a valid MachV milestone to mozilla1.0.
Target Milestone: --- → mozilla1.0

Comment 4

16 years ago
ADT2 per ADT triage.
Keywords: access
Whiteboard: [ADT2]

Comment 5

16 years ago

*** This bug has been marked as a duplicate of 68359 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

i've nominated bug 68359 for nsbeta1, since this one has been dup'd against it.

Comment 7

16 years ago
Reopening, this is a separate issue from bug 68359.
Resolution: DUPLICATE → ---


16 years ago


16 years ago
Summary: Tab'ing does not work properly in a tree widget → tab focus skips non-visible (scrolled-off) controls in listbox

Comment 8

16 years ago
Created attachment 78839 [details] [diff] [review]

This fixes the problem specifically for mail compose by scrolling the listbox
when you tab between rows.  In the general case, it's tricky to make <tab> in a
listbox scroll content into view and focus it, because the focus code relies on
the frames, and listbox doesn't build frames until the content is scrolled into
view (for efficiency).

There is one remaining problem with this patch -- if you shift+tab while the
to/cc menulist popup is open, the list will not scroll up like it should.  I'm
having trouble getting a capturing event handler (to handle key events while
the popup is shown) to work.

Comment 9

16 years ago
Comment on attachment 78839 [details] [diff] [review]

You can use listBox.listBoxObject instead of doing the QI yourself.

Comment 10

16 years ago
I tried that at first, got some odd errors about the ensureIndexIsVisible
function not being defined when called from awTabFromMenulist.

Comment 11

16 years ago
Created attachment 79351 [details] [diff] [review]
patch #2

Ok, this one should work even if you have a popup open when you press tab.  I
had to add a line to the onload handler of each window that uses the addressing
widget to set up the capturing event handler on the document (this would be
much easier if the addressing widget was in XBL).
Attachment #78839 - Attachment is obsolete: true

Comment 12

16 years ago
Sarah, would you be able to give this patch some testing?

Comment 14

16 years ago
Comment on attachment 79351 [details] [diff] [review]
patch #2

Attachment #79351 - Flags: superreview+

Comment 15

16 years ago
Checked in on the trunk.  Nominating for branch checkin.
Last Resolved: 16 years ago16 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED

Comment 16

16 years ago
Esther, can you please test on trunk and update this bug?  Jean-Francois, can
you please look at the patch, and update this bug?
QA Contact: sairuh → esther
ugh, this fell off my radar. will look at this in a bit, unless esther beats me
to it. ;)
linux rh7.2 and win2k, 2002.04.18.14 commercial trunk: tab and shift+tab work
fine, using sean's test as well as the one in comment 2.

mac 10.1.4, 2002.04.18.14 comm trunk Aqua theme: tab works, but shift+tab
doesn't move upward in the listbox --shift+tabbing just cycles as follows:

* from the bottommost visible item
* to the topmost *visible* item
* jumps to the composition body (not the next non-visible listbox item)
* to the Subject field

i should note, however, that on mac using the Modern theme is *fine* (there are
known accessibility issues with using the classic or aqua themes).

Comment 19

16 years ago
Comment on attachment 79351 [details] [diff] [review]
patch #2

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #79351 - Flags: approval+

Comment 20

16 years ago
Marking adt1.0.0+ on behalf of the adt.  Please check the fix into the branch as
soon as possible and add the verified1.0.0 keyword in the status whiteboard.

Sarah, can you file a separate bug regarding the behavior on MacOsX.
Keywords: adt1.0.0 → adt1.0.0+

Comment 21

16 years ago
Checked in on MOZILLA_1_0_0_BRANCH.
Keywords: fixed1.0.0

Comment 22

16 years ago
Verified on trunk 04/22/02 and branch 04/25/02 builds - Linux, Win2K.
On Mac 10.1.3 both builds have the same old problem: no keyboard access to
To/From/Cc buttons. It is supposed to be solved by turning on new options:
System Preferences|Keyboard panel, Full Keyboard Access tab: I checked on "Turn
on full keyboard access" and radio button: "Any control". 
QA Contact: esther → olgam

Comment 23

16 years ago
Above issue on Mac is due bug 133666. 
Keywords: fixed1.0.0 → verified1.0.0

Comment 24

16 years ago
Isn't trapping the menulist keypresses at the document element overkill?
It even captures keypresses in the compose area.
I realize that onkeypress won't work because you need to capture the keypress,
I was just thinking that you could capture them nearer the menulist.

Comment 25

16 years ago
Unfortunately, that doesn't work.  I believe it's because of the way we attach
popups into the view hierarchy.  This is the same place that MenuPopupFrame
attaches its listeners for arrowing up and down.
You need to log in before you can comment on or make changes to this bug.