str - type something in search box and hit enter (seeding the search box as it often is for me) - click on search box - move mouse to hover of non-default search engine - type something in search box and hit enter I found I'm inadvertently doing this, resulting in an ebay search rather than a search with my default engine. I tend to click into the search box to replace the previous search. I also tend to "move the mouse cursor out of the way" after I've clicked. If it ends up on a search engine icon, I type something and hit enter, the search goes to the highlighted search engine. This is not what I expect to happen and confused me the first couple times it happened.

While the underlying issue might be the same, bug 1113731 seems to be about search terms and that the wrong search term gets used inadvertently. This is about the wrong search engine getting used inadvertently based on a mouseover. Still feel it is a dup?

I guess maybe not.

Mistakenly filed against Firefox 38 and should be instead 38 Branch. Sorry for the spam. dkl

[Tracking Requested - why for this release]: [Tracking Requested - why for this release]: [Tracking Requested - why for this release]: Actually this is UX regression. Pushlog: https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=cb757c948bc0&tochange=ab00a9cbd01b Suspect: Bug 1124904

This doesn't seem significant enough to track as we have already shipped with this issue and there is an easy workaround. I would be happy to take a safe uplift request when a fix become available. I have nomed for the Firefox backlog for this work to be prioritized by the desktop team.

I am having the same issue. For a long while, I was thinking that Firefox just randomly selected a different search engine instead of the default one because of a bug. I also tracked it down to the mouse pointer positioned "just right" to happen to be over over the button. Then vibration of the table from my typing caused the mouse to report a movement... and there you go. This certainly violates the Least Surprise Principle of the UI design. I believe that a click to select a different search engine instead of hover would be much less surprising.

:D Yeah, I'm hitting this _several times a day_. This is an enormously annoying bug.

**TEMPORARY WORKAROUND**: Remove all search engines from the configuration but one that you use the most. Firefox hides all search engine boxes at the bottom of the drop-down, so the bug will not affect .you YMMV, but works for me.

I think this is a general problem. The same "select on hover" applies to form autocomplete and address bar suggestions.

I also find this annoying - I assume a lot of users encounter this and just assume it's a random occurrence or bug. It certainly took me a while to realise it was related to mouse pointer positioning. I think the answer is to change the design so that just pressing enter always searches with the default search engine, and a mouse click or exlicit selection via the keyboard is required to search with an alternative (not simply hovering).

(In reply to Richard West from comment #14) > I think the answer is to change the design so that just pressing enter > always searches with the default search engine, and a mouse click or exlicit > selection via the keyboard is required to search with an alternative (not > simply hovering). Exactly. I was tempted to say 'duh', but that's just not productive, and it's not very nice. Anyway, how this feature ever got past testing, if indeed it was ever tested at all, remains a mystery.

Hello, I want to solve this bug as I am starting out on solving bugs on Mozilla. So I would like to work on it. Thanks!

Raising the priority a bit; this seems to affect lots of people.

A note: I can see the same behavior also with autocomplete drop-downs - annoying the same way. We may want to fix this more generally. Could the focus change come directly from native widgets?

(In reply to Honza Bambas (not reviewing) (:mayhemer) from comment #22) > A note: I can see the same behavior also with autocomplete drop-downs - > annoying the same way. We may want to fix this more generally. > > Could the focus change come directly from native widgets? This is a little messy :( All auto-complete dropdowns do have similar issues with their "list" part - the Awesomebar, form autocomplete popups, and the "search suggestions" list in the search dropdown all do slightly strange things on hover. However, I think the "search engines" part of the search box is a slightly unique case that doesn't apply to these other popups. I think something like comment 14 would solve the worst part of this bug. It would still leave some strangeness on the "list" part of the popups, including the search suggestions part of this one (eg, what "DEL" does will still suddenly change just because you hovered a suggestion) but it would still be a significant improvement to the search dropdown.

(In reply to rpnpif from comment #26) > A complete redesign of this UI about the searching function is needed to > become again ergonomic. I'm not sure if that's necessary; to my mind all we need is to stop letting the buttons in the drop down take keyboard focus. If we click them with a mouse then fine, or if we use tab to explicitly change focus, then fine; but I don't think they should be reacting to the return-key except if we've explicitly changed focus. (I suspect that's a little hairy to change, but it would have minimal visible change and I don't think it would break any behaviours anyone is expecting).

With this patch, pressing enter in the searchbar will ignore button selections from the mouseover handler. This reverts the partial fix from bug 1140440, and implements the solution suggested in comment 14 / comment 23 here.

Backing out Bug 1184220 wasn't enough to fix the bustage, apparently, so I'm backing out everything else from that push to hopefully get back to a clean slate. https://hg.mozilla.org/integration/fx-team/rev/1199232e985b

How about backporting this to 38ESR?

(In reply to Ray Satiro from comment #34) > How about backporting this to 38ESR? I don't intend to work myself on any uplift of this, but if someone wants to do it, I'm not against it.

Verified as fixed using Firefox 43 beta 1 under Win 7 64-bit and Mac OS X 10.9.5.