1139655 - mouse over search engine changes search engine (too easy to inadvertently use different engine for searches)

Status: VERIFIED FIXED

(Firefox :: Search, defect, P2)

Description

[Shane Caraveo (:mixedpuppy)]

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.

Comment 2

[Shane Caraveo (:mixedpuppy)]

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?

Comment 3

[:Gavin Sharp [email: [e-mail]]]

I guess maybe not.

Comment 4

[David Lawrence [:dkl]]

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

Comment 5

[Alice0775 White]

[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

Comment 6

[Lawrence Mandel [:lmandel] (use needinfo)]

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.

Comment 7

[Cy 'kkm' K'Nnelson]

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.

Comment 10

[Alice0775 White]

This is quite terrible UI. 
The neOffButtons search UI should be backed out!!!!!!

Comment 11

[Honza Bambas (:mayhemer)]

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

Comment 12

[Cy 'kkm' K'Nnelson]

**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.

Comment 13

[Honza Bambas (:mayhemer)]

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

Comment 14

[Richard West]

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).

Comment 15

[Jeff Rivett]

(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.

Comment 18

[Sanchit Kapoor]

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!

Comment 21

[Florian Quèze [:florian]]

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

Comment 22

[Honza Bambas (:mayhemer)]

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?

Comment 23

[Mark Hammond [:markh] [:mhammond]]

(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.

Comment 24

[rpnpif]

All suggestions requests are sent to the default engine, not the desired engine. This is a leak of data.

Please modify.

Regards.

Comment 25

[Simon Lindgren]

Another observation, when adding a bookmark and creating a new bookmark folder by clicking "New Folder" in the bookmark popup, a new folder is created and the name "New Folder" is selected. Then after about a second the text is deselected again and the folder created with the default name. Seems like a similar issue to me.

Comment 26

[rpnpif]

A complete redesign of this UI about the searching function is needed to become again ergonomic.

Comment 27

[Dr. David Alan Gilbert]

(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).

Comment 28

[rpnpif]

(In reply to Dr. David Alan Gilbert from comment #27)

I said "a complete redesign" to fix the other requirements quoted in the above comments and in the other duplicated reports as suggestions requested always to the default engine instead of the wished temporary engine, the display of the name of the engine in use in the search zone, a better labelling of the engine in the list, and first for engines that have not icon, a remembering of the last engine as with FF31, your request and so on.

So I think that there are a lot of work that could do redesign a big part of the zone.

Comment 29

[Florian Quèze [:florian]]

Attachment: Patch

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.

Comment 30

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/d79fb9007765

Comment 31

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 32

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/6a018a619384

Comment 33

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/6a018a619384

Comment 34

[Ray Satiro]

How about backporting this to 38ESR?

Comment 35

[Florian Quèze [:florian]]

(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.

Comment 36

[Petruta Horea [:phorea], Desktop Test Engineering]

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