I thought I would share the following user story: I observed someone clicking repeatedly on the search icon in Firefox 34 and getting nowhere. I asked and he said he wanted to select Google Scholar, but "all the search engines had disappeared". It's worth noting that the old UI trained mouse users not well-versed in keyboard shortcuts to select the search engine first, as they would be using the mouse anyway to focus the search box, and so selecting the engine first made it unnecessary to switch back to the mouse a second time to select the engine. This has also been discussed in the comments of bug 1108488, but I thought it might be useful to file it as a UX issue separate from feature requests about keyboard shortcuts etc.

Based on the previous discussion in bug 1108488 and discussions I had with Philipp, I think the suggested behavior here is: 1. If the search field is empty, clicking the glass icon or pressing alt+down will open the search panel without the suggestions top part, but with the one-off buttons. 2. In this panel, selecting an engine by a click, or using the up/down arrow and then <enter> results in the engine's icon replacing the glass icon in the searchbar, to indicate this engine will be used for the next search. 3. When the user starts typing in the search field, the full search panel opens with suggestions. The one-off button of the engine selected in 2. is highlighted to show that it will be used to search if the user presses <enter>. 4. After the user performs a search, the engine icon in the searchbox reverts to the glass icon. Note: this addresses the case of "select engine and then starts typing". It does NOT address the "select this engine for a few searches" case, which is bug 1109851, and that we tried to somehow address by reintroducing ctrl+up/down in bug 1110678. If we wanted the changes suggested here to also help for bug 1109851, we could say that at step 2. selecting using command+click or command+enter sets the selected engine to be the new default. Philipp, is this something we want to implement?

Oops, didn't mean to clear that needinfo. FWIW, I've added this bug to the next iteration.

After some discussion with Stephen and Madhava, I think we should call this a wontfix. Here's the rationale: Florians suggestion seems to be the best way to deal with this. However, it still introduces some inconsistencies into the UI where the same button does two different things based on when it gets clicked. That effectively makes it harder to get used to the new behavior. I see some opportunity to fix this issue down the road as we evolve the search experience further (it definitely isn't forgotten), but there's just too much conceptual conflict with the current design to make it a viable option right now.

(In reply to Philipp Sackl [:phlsa] please use needinfo to make me respond from comment #3) > However, it > still introduces some inconsistencies into the UI where the same button does > two different things based on when it gets clicked. That effectively makes > it harder to get used to the new behavior. I don't follow this rationale: where is the inconsistency? With this proposal, whether the search box is empty or not, when you click on the search field you are *selecting the search engine for the next search* in both cases.

(In reply to aleth [:aleth] from comment #4) > (In reply to Philipp Sackl [:phlsa] please use needinfo to make me respond > from comment #3) > > However, it > > still introduces some inconsistencies into the UI where the same button does > > two different things based on when it gets clicked. That effectively makes > > it harder to get used to the new behavior. > > I don't follow this rationale: where is the inconsistency? With this > proposal, whether the search box is empty or not, when you click on the > search field you are *selecting the search engine for the next search* in > both cases. The difference that with an empty search box, it pre-sets the engine for the next search (it then requires additional action to actually trigger a search) while clicking it with text in the search bar it immediately triggers the search (no further action required).

(In reply to Philipp Sackl [:phlsa] please use needinfo to make me respond from comment #5) > The difference that with an empty search box, it pre-sets the engine for the > next search (it then requires additional action to actually trigger a > search) while clicking it with text in the search bar it immediately > triggers the search (no further action required). Thanks for the explanation. Maybe the least complex solution would be to simply show the one-off search buttons when clicking on the magnifying glass even when the search bar is empty? This doesn't allow pre-selecting a search engine but at least makes it obvious how to select the search engine without "changing search settings". (The only question would be what action one-off-searching for an empty string would trigger -- would the buttons be disabled? or would it lead to visiting the engine's home page?)

(In reply to aleth [:aleth] from comment #6) > The only question would be what action > one-off-searching for an empty string would trigger -- would the buttons be > disabled? or would it lead to visiting the engine's home page? The latter. (At least that's what currently happens if you open the full panel with the down arrow and the search field is empty).

Phillip, this was closed based on the only suggestion being a "when it's clicked" approach. I'm reopening based on bug 1236966 and on the discussion in the firefox-dev mailing list, which suggest more "how it's clicked" approaches: - selecting the default/current search engine if the user shift clicks the engine; to quote Mike Conley: > if the user is holding down, say Shift, while right-clicking, it > just sets the engine as default instead of showing the context menu. > > Then changing the search engine becomes two clicks with a key-hold in > there. (click to open panel, hold Shift, right-click engine). - directly when right clicking it and removing the context menu altogether; to quote myself: > right click to set default, left click to search (already does this), > ctrl+left click to search in new tab (can already do this). Mostly because > using shift+right click implies that you know that this combo exists, > which implies some degree of knowledge of what setting a default engine > entails. While ctrl+left click to open in a new tab is kind of general > browser knowledge (every browser does this right?). > > Plus, reading "set as default search engine" might be scary for more > novice users who don't fully understand what that means (sure it's a > simple and direct action, but you don't know that until... well until > you know that). Setting it directly on right click will just show the > change on screen, and it's something that is undone easily with another > click in the same place if needed. To test these suggestions (and for consistency with other features), I've integrated them into beta version 1.4b3 of my add-on [1], controlled by preference "extensions.thefoxonlybetter.rightClickEngines" with values: 0 - right click always shows context menu (original behavior) 1 - right click sets engine as default, no context menu 2 - right click shows context menu, shift-right click sets as default 3 - left click runs one-off, shift+left click sets as default Are any of these worth investigating further? Personally I like 1 and 3. :) [1] https://github.com/Quicksaver/The-Fox--Only-Better/releases/tag/v1.4b3

(In reply to Luís Miguel [:quicksaver] from comment #9) This bug is not about ways to change the default engine, but about ways to first select the engine (for the next search only) and then type the query.

(In reply to Florian Quèze [:florian] [:flo] from comment #10) > (In reply to Luís Miguel [:quicksaver] from comment #9) > This bug is not about ways to change the default engine, but about ways to > first select the engine (for the next search only) and then type the query. The user story here doesn't specify that it's for the next search *only*, only about selecting the engine before searching. At least that's how I read it after bug 1236966 being marked as a duplicate. If that's not the case then it's not really a duplicate of this I believe.

(redirecting to Stephen who is much more involved with search these days...)