200884 - Keyboard shortcut for changing search bar item

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, enhancement)

Description

[Guan Yang]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030405 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030405 Phoenix/0.5

I would like a keyboard shortcut of some kind to change the search item in the
search bar, i.e. if I want to change from Google search to dmoz.org search.
Right now I have to click the Google icon and select dmoz.org with the mouse.

Reproducible: Always

Steps to Reproduce:

Comment 1

[noririty]

There is a lot of missing keyboard shortcut in browser.xul.
This could be one of them and should be implemented IMHO.

-> NEW

Comment 2

[David Tenser [:djst]]

*** Bug 204403 has been marked as a duplicate of this bug. ***

Comment 3

[Simon Paquet [:sipaq]]

Taking QA Contact

Comment 4

[Mike Connor [:mconnor]]

-> taking

suggestions on what the accesskey should be?

Comment 5

[Ralf Angeli]

If you mimic the behavior of drop down menus, i.e. you can cycle throuh the
entries but the menu is not opened as a whole, maybe `Ctrl-Up/Down Arrow' with
the focus in the search text field would be an option.

Otherwise, if you want a key to open and display the menu for selection with the
arrow keys ...  Hm, `Ctrl-s' for "s"earch and `Ctrl-e' for "e"ngine are not
available anymore.  Maye `Ctrl-m' for "m"ycroft and as it is quite near to `l'
and `k'---the other keys for jumping to the location and search bar.

Comment 6

[NetVicious]

Ctrl+M to drop-down the menu would be ok ;-)

Comment 7

[Mike Connor [:mconnor]]

Attachment: patch

we're really all but out of accesskeys.  Ctrl-M won't work, because Cmd+M on
Mac should be minimize, so we'd be broken on Mac.  Ctrl-Shift-K was ruled out
by the fact that Ctrl-Shift combos break on GTK2 due to a standards compliance
issue.

Instead, Ctrl-K with the search bar already focused will bring up the menu. 
(Ctrl-K twice will focus and bring up the menu).

Comment 8

[Ben Ruppel]

Would it be a bad idea for ctrl-k repeatedly to just cycle between the available
search engines?  

Comment 9

[Daniel Jackson]

Isn't there also no way for a new user to know what the search-bar shortcut is
anyway? (without looking at the keyboard web-page, but the homepage may have
been changed if the installation was by someone else)

To solve both problems, why not add a "Search" cascaded menu under Tools with
the top item allowing you to go to the search box (and displaying the shortcut)
and (under a horizontal-separator) have a tick-list of the different search
options, and finally, the "Add engines" option.

  Tools
    ...
    Search >
             Search...    (Ctrl+K)
             ---------------------
                Find in this page
             ./ Google
                DMOZ
             ---------------------
             Add engines...



OR: 

Have a search button (similar to "Go"), with a drop-down menu that sets what
it'll do when pressed.  When the button's got the focus, pressing down (or
alt+down) will allow the user to choose.  

On my build, the 'Go' button can have the focus by a single tab from the address
bar (but it's display doesn't change), so I assume it could be the same for a
Search button.

Comment 10

[Mike Connor [:mconnor]]

To be completely and utterly honest, we do NOT need to make every single
keyboard shortcut discoverable in the UI.  Duplicate menus are cruft, and we're
not going to make the mistakes that Seamonkey made.  If a new user wants to
learn all of the keyboard shortcuts, RTFM.

Both of your suggestions add clutter to the UI, that isn't needed other than to
service the user who wants to avoid reading the documentation.  If there is a
dropmarker for the search icon, its obvious to a non-novice user that there is
an option for a selection there.

Comment 11

[David B. Harris]

Just to throw in my two cents (this is a UI improvement I'd like to see), the
two alternatives which I would prefer are:

1) Using up/down to scroll through the available engines. Since history may at
one point be implemented for the search-engine textfield, I suppose it would
have to be Ctrl+Up/Down (which has already been mentioned).
2) Having the menu pop up with the topmost engine selected when Ctrl+K is hit
and the search-engine textfield is already focused.

To go into a bit more detail about #2, I say "with the topmost engine selected"
deliberately - that way I'll always know 'Hit down three times to get to the
eBay search' and 'Hit up twice to get to the bugs.debian.org lookup' - if the
currently-selected search engine is also the currently-hilighted one when the
menu is popped up, I'll have to process that information and take appropriate
action thereafter. That kind of thing slows a user's actions down.

There is a bad side with the Ctrl+K twice way of doing things, though; people
may do the following with Ctrl+L:

1) Hit Ctrl+L.
2) Start typing stuff.
3) Realise a mistake was made very early in the URL.
4) Hit Ctrl+L again to cause what's been typed in to be re-hilighted.
5) Start over again.

That being said, however, I still prefer the "Ctrl+K twice" proposal.

Comment 12

[Pierre Chanial]

-> taking
I opted for the ctrl-K, ctrl up|down sequence over the ctrl-K twice, arrow
up|down, enter to spare two keystrokes.
the ctrl-K to toggle engine was cute, but sometimes, we don't know where the
focus is and we hit ctrl-K to be sure it goes to the search bar. It would be a
problem if the focus was already in the search bar.

Comment 13

[Pierre Chanial]

and marking fixed.

Comment 14

[noririty]

v. 20031104 on win2k.

Comment 15

[Matt McClure]

Ctrl+Up and Ctrl+Down don't work for me in Firefox 0.8 (Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8) on Windows XP. 
Instead of changing the search engine, they move through the history of search text.

Should this be reopened?  Or should there be a new bug?

Comment 16

[Mike Connor [:mconnor]]

filed bug 235131 for the regression noted

Comment 17

[NetVicious]

I confirm this bug should be reopened.