Search Messages UI: missing some access keys/mnemonics

VERIFIED FIXED

Status

SeaMonkey
MailNews: Message Display
VERIFIED FIXED
16 years ago
9 years ago

People

(Reporter: laurel, Assigned: Håkan Waara)

Tracking

(Blocks: 1 bug, {access})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
Using jan24 commercial trunk build

Search UI spec: http://www.mozilla.org/mailnews/specs/search/

After revision(s) from bug 91753, there are a couple places in the Search
Messages UI missing mnemonics/access keys as shown in spec.

Missing:
1.  mnemonic "e" in Search Subfolders checkbox line
2.  mnemonic "a" in  radio option "Match all of the following"
3.  mnemonic "o" in radio option "Match an of the following"

Comment 1

16 years ago
taking. I believe that we currently do not support accesskeys in labels yet. 
Assignee: naving → andreww
(Assignee)

Comment 2

16 years ago
*** Bug 68899 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Status: NEW → ASSIGNED

Updated

16 years ago
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.9

Comment 3

16 years ago
The mnemonics are there, but there is no infrastructure to support mnemonics in
labels at this time. Bug 959 should add this support. Approved nomination
because we need the mnemonics for section 508 compliance. 
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Depends on: 959
Keywords: nsbeta1 → access, nsbeta1+
Resolution: --- → REMIND

Comment 4

16 years ago
Bug 959 is now fixed, and most of the accesskeys work.  Remaining problems with
accesskeys in the message search dialog:

1. The accesskey for the location dropdown should be "i" for "in" instead of
"s", and the accesskey for the Search button should be "s" instead of "h".  In
English, fixing this would also fix the problem that the "Stop" button appears
as "Stop(H)".

2. The accesskey (currently "s") for the location dropdown does not work.  I
think it should focus the dropdown and make the menu appear.

3. The accesskeys are not visible in the labels for radio buttons and
checkboxes.  The accesskeys (e, a, o) do work, however.

4. If one of the radio buttons is focused and I hit the accesskey for the other
one, the focus ring disappears.  If I hit the same accesskey again, it reappears.

5. There doesn't seem to be an easy way to focus the search results tree.  Two
possible solutions:
- Put a label "Results:" at the far right of the dialog, in the blank space to
the right of the "More" and "Fewer" buttons.  Give the accesskey R to the tree.
- Focus the results list after the search is finished.  (This is what OE does.)
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Target Milestone: mozilla0.9.9 → ---

Comment 5

16 years ago
bug 125272 should fix the "Stop(H)" problem.

Comment 6

16 years ago
#1 is bug 125272, as jglick pointed out.
#3 is bug 68841.

Updated

16 years ago
Blocks: 129179
(Assignee)

Comment 7

16 years ago
#1 is bug 125272
#3 and #4 are bug 68841

#2 and #5 will be fixed by an upcoming patch.
(Assignee)

Comment 8

16 years ago
Actually, #4 is not literally that bug, but radiobuttons have a lot of problems
with accesskeys, so it's not a bug in this dialog per se.
(Assignee)

Comment 9

16 years ago
Created attachment 73291 [details] [diff] [review]
Patch

Comment 10

16 years ago
Comment on attachment 73291 [details] [diff] [review]
Patch

r=andreww
Attachment #73291 - Flags: review+

Comment 11

16 years ago
sending to hwaara since he has a patch already...
Assignee: andreww → hwaara
Status: REOPENED → NEW
>5. There doesn't seem to be an easy way to focus the search results tree.

you can tab into it.

let's let jglick decide if she wants us to switch focus to the results pane 
after a search.

off the top of my head, I'd say no.  We've had other bugs in the past about us 
moving focus on the user, and the general idea has been that it's bad.

(See the bug about moving focus to the thread pane on loading a folder)

the part of the patch to SearchDialog.xul looks ok.  sr=sspitzer on that part, 
but not the other part.
(Assignee)

Comment 13

16 years ago
Focus stuff can be terrible to debug, and I agree that it makes sense to mess
around with the user's focus.  I too vote for leaving out that change.

Comment 14

16 years ago
Comment on attachment 73291 [details] [diff] [review]
Patch

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

Comment 15

16 years ago
fixed.
Status: NEW → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 16

16 years ago
Not changing focus is fine with me.
(Reporter)

Comment 17

16 years ago
OK using mar14 commercial trunk: win98, linux rh6.2
Accesssing all mnemonics seems to be okay, can tab to all areas in dialog.
With the limitiations set forth in comment #7 and comment #8. 
Using keyboard access to the File button is confusing because of bug 121679.
Access to the criteria section is a little confusing because sometimes it
highlights the row and sometimes not (I think we have an older bug about
selecting the row).
Access to the results area is a little awkward, no obvious focus indicator/ring.

Any further specifics regarding keyboard access in search will be/have been
logged separately.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 18

16 years ago
Added info:  tested in both Modern and Classic themes. OK linux and win98.
Note:  tested keyboard access via tabbing on Mac... works in Modern, but not
Classic.  Logged bug 131325
Product: Browser → Seamonkey

Updated

9 years ago
Component: MailNews: Search → MailNews: Message Display
QA Contact: laurel → search
You need to log in before you can comment on or make changes to this bug.