339322 - Add keyboard shortcut to access menus in search fields

Status: RESOLVED FIXED

(Camino Graveyard :: Accessibility, enhancement)

Description

[M. Ruegenberg]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060427 Camino/1.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060427 Camino/1.0.1

In Firefox and other browsers with this feature, one can change the search engine that is used for searches in the search field by using Command+Up/Down.

I looked in the Camino keyboard shortcuts list and couldn’t find anything similiar, so it seems, this is not there.

UI-wise, this could be a bit tricky, as Camino does not use the favicons of those search engines. I would opt for the normal menu (that opens when clicking with the mouse on the magnifier in the search field) to open once either Command+Up or Command+Down is opened and the current search engine to be marked (like it happens when mousing over one of the engines in that menu). One can then go through the menu with the Up and Down key and the currently selected search engine is used once the Command key is released.

If this funtionality is already there, it is pretty well hidden and no good UI.

Reproducible: Always

Steps to Reproduce:
1. Go in the search field
2. Try to change the used search engine with the keyboard

Actual Results:  
No success

Expected Results:  
Let the user change the search engine with the keyboard

Comment 1

[Stuart Morgan]

Command-Up/Down already have meaning OS-wide in text fields; using them would break that binding.

Opening a menu with a shortcut key would be very odd UI.  I think if there were going to be a shortcut to change engines it would be better to do something like briefly force display of the hint text that identifies the search engine when the field is empty and unfocused.

Comment 2

[Chris Lawson (gone)]

Is there any way to trigger that menu using Full Keyboard Access? Seems to me like there would be, and that would make this a WORKSFORME.

cl

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I can't find anything in FKA to cause the display of a menu in a search field (the bookmarks search field also has one); space nomally drops menus, but it's a valid character in text fields, and ctrl-F2 seems permanently bound to the OS menubar.

As odd as it is in the general OS/HIG context, for a11y purposes I think we should consider implementing a shortcut that brings up the menu in these fields, perhaps making it work only when FKA is on for HIG consistency's sake?

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Can we make the (X) and the looking glass tabable when FKA is on?  That would solve this (spacebar would drop the menu when the glass was focused) and bug 338733 from an a11y perspective.

Comment 5

[Håkan Waara]

I see no good solution here, but let's choose the least worst. :-/

Comment 6

[Håkan Waara]

This might as well be an Apple bug.  Anyone who wants to get traction on this bug: I suggest you file it to Apple, and then we can put this bug on hold until we know what they do.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The other problem with cmd-up/down selection of items (beyond violating the standard system text field behaviors) is that while it works well in search fields that indicate the selected engine/menuitem in non-standard ways, it fails in both our cases.  

In the toolbar field, we clear the engine name (hint text) when you insert the cursor, and if there's already search text in there, there's no hint text at all, so the user never knows what engine they're selecting.  Similarly, in the manager search field, we don't indicate at all (in the field) if the menu is set to All, Title, Location, etc.

We need a solution that drops the menu, not changes the current value blindly.

Comment 8

[Bryan Atwood]

What about using the method Apple implemented for the Xcode Documentation search box?  While in the search box, pressing the up or down arrow key pops up the search menu.  Pressing the up or down arrow again will scroll through the list of search targets (API Search, Full-Text search).

I've noticed this in a couple of other places, like the Script Editor dictionary search box.

Comment 9

[froodian (Ian Leue)]

(In reply to comment #8)
> What about using the method Apple implemented for the Xcode Documentation
> search box?  While in the search box, pressing the up or down arrow key pops up
> the search menu.  Pressing the up or down arrow again will scroll through the
> list of search targets (API Search, Full-Text search).
> 
> I've noticed this in a couple of other places, like the Script Editor
> dictionary search box.
> 

FWIW, this annoys me almost every day.  In single-line text fields, up == beginning of line, and down == end of line.  But if everybody else likes it, we can swing with it.

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Just thinking aloud here: what if we do the same thing that we do in the location bar, where down operates normally (== end of line) unless it's already at the end of the line, at which point it drops down the autocomplete list (drops the menu in  search fields)?  Once the menu is shown, up and down navigate, space and return select+close, and Esc closes without selecting a new value.

I'm not fond of creating an ever-greater collection of slight variations on standard keystrokes, but in the absence of an OS standard, one that's reasonably familiar and which doesn't break the existing OS standards is probably going to be our best bet.

There was another solution mentioned somewhere else that I liked better, but it seems that it never made its way into this bug....

Comment 12

[Samuel Sidler (old account; do not CC)]

I agree with comment 11. Let's not wait for Apple.

Comment 13

[Christopher Henderson]

Attachment: Fix v1.0

If the down arrow key is pressed when the caret is at the end of the line, a simulated mouse click in invoked on the search field's search button. The performClick method doesn't work. Works in both the toolbar and search sheet fields.

Not sure if we need to test if the control responds to the caretIsAtEndOfLine selector before sending that message.

Comment 14

[Christopher Henderson]

Attachment: Fix v1.1

Adds the same functionality to the search field in the bookmarks manager. Since we don't use the WebSearchField class there, the delegate method is slightly different.

Comment 15

[Sean Murphy]

Comment on attachment 344795 [details] [diff] [review]
Fix v1.1

Nice patch Hendy.  Yeah, it's strange that the performClick: approach doesn't work properly on the the search field's "search button cell."  Unlike a lot of action methods, that one must be called with a valid NSView argument, otherwise it will do nothing.  With a valid argument, unfortunately, the action performed by the button cell is the equivalent to clicking return in the search field, starting the search instead of showing the menu. The workaround to display the menu is clever, I suppose we'll have to do it that way. 

I do have just a few suggestions for the patch, though.  Rather than put the |caretIsAtEndOfLine| method in WebSearchField, and then repeat all the code that does that logic again in |BookmarkViewController|, I think you should instead declare a category on NSTextView* for that method.  You can then call it on the |textView| argument in that method, which will be the field editor in use on the search field.

Also, in each |control:textView:doCommandBySelector:| delegate method, just to future proof this code, I think that you should verify that the sending control is the search field (in the browser window case, accounting for both the field or sheet), before performing the mouse click simulation.

Comment 16

[Christopher Henderson]

Attachment: Fix v1.2

Adds the category for NSTextView, and other suggestions from Sean. Includes a diff on the project file, for the new files.

Comment 17

[Christopher Henderson]

Attachment: Fix v1.3

Consarn it, forgot the AutoCompleteTextField.* files diffs.

Comment 18

[Sean Murphy]

Comment on attachment 347929 [details] [diff] [review]
Fix v1.3

Darn it, I'm sorry I held this one up for so long Hendy...

The changes look great, r=me with just a few very minor style nits below!

>+  if (command == @selector(moveDown:) && [textView caretIsAtEndOfLine] &&
>+      (control == mSearchBar || control == mSearchSheetTextField)) {
>+    NSWindow *controlWindow = [control window];

For multi-line if statements, the opening brace should go on a new line.

Otherwise, there are just a few long lines in the patch that can be wrapped, such as the coordinate conversions and comments.  We usually try to keep line length to around 80 characters or so.  In Xcode's preferences, you can turn on the handy page guide at a certain column number, under Preferences->Text Editing to keep an eye on this.

The project patch, of course, needed a refresh, and I felt bad for letting this fall off my radar so I updated that for you ;).

Comment 19

[Sean Murphy]

Attachment: Fix v1.3 (updated project)

(Patch by Hendy, I just updated the project for him.)

Comment 20

[Stuart Morgan]

Comment on attachment 351810 [details] [diff] [review]
Fix v1.3 (updated project)

Sigh. Could you file a radar with Apple for a programatic way to open the menu?

In the meantime though, I don't have any other suggestions, so fake clicks it is. sr=smorgan with murph's comments addressed.

Comment 21

[Christopher Henderson]

Attachment: Patch for checkin

Patch with updated project and Sean's comments addressed. There are one or two lines that are a bit over 80 characters in length, but I think it'll be OK.

Comment 22

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Landed on cvs trunk.

Comment 23

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #20)
> (From update of attachment 351810 [details] [diff] [review])
> Sigh. Could you file a radar with Apple for a programatic way to open the menu?

Also, please post the rdar:// number in here once the bug is filed.

Comment 24

[Christopher Henderson]

rdar://6451275