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]
OS: Windows 2000 → All
Hardware: PC → All
Nav Triage: marking nsbeta1+ - looks like this will continue to be a problem and has relatively high visibility/accessiblity impact.
Keywords: nsbeta1 → nsbeta1+
Mass move of nsbeta1+ bugs that didn't have a valid MachV milestone to mozilla1.0.
Target Milestone: --- → mozilla1.0
ADT2 per ADT triage.
*** This bug has been marked as a duplicate of 68359 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
v-dup. i've nominated bug 68359 for nsbeta1, since this one has been dup'd against it.
Status: RESOLVED → VERIFIED
Reopening, this is a separate issue from bug 68359.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Summary: Tab'ing does not work properly in a tree widget → tab focus skips non-visible (scrolled-off) controls in listbox
Created attachment 78839 [details] [diff] [review] patch 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 on attachment 78839 [details] [diff] [review] patch You can use listBox.listBoxObject instead of doing the QI yourself.
I tried that at first, got some odd errors about the ensureIndexIsVisible function not being defined when called from awTabFromMenulist.
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
Sarah, would you be able to give this patch some testing?
Comment on attachment 79351 [details] [diff] [review] patch #2 firstname.lastname@example.org
Attachment #79351 - Flags: review+
Comment on attachment 79351 [details] [diff] [review] patch #2 sr=hewitt
Attachment #79351 - Flags: superreview+
Checked in on the trunk. Nominating for branch checkin.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
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 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+
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+
Checked in on MOZILLA_1_0_0_BRANCH.
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".
Status: RESOLVED → VERIFIED
QA Contact: esther → olgam
Above issue on Mac is due bug 133666.
Keywords: fixed1.0.0 → verified1.0.0
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.
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.