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"
taking. I believe that we currently do not support accesskeys in labels yet.
*** Bug 68899 has been marked as a duplicate of this bug. ***
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.
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.)
bug 125272 should fix the "Stop(H)" problem.
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.
Comment on attachment 73291 [details] [diff] [review] Patch r=andreww
sending to hwaara since he has a patch already...
>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.
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 on attachment 73291 [details] [diff] [review] Patch a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Not changing focus is fine with me.
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.
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