Closed Bug 1293300 Opened 3 years ago Closed 3 years ago

Accidental one-off search if mouse pointer hovers over a search engine when typing in location bar and pressing enter

Categories

(Firefox :: Search, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 51
Tracking Status
firefox51 + verified

People

(Reporter: Mardak, Assigned: adw)

References

Details

Attachments

(1 file)

The search engine is being used if the pointer happens to be in the wrong place.

This breaks common flows of just typing in the location bar and hitting enter.

I would assume this is not intended, as a user moving the pointer to where the search engine will appear to search is probably not a desired user flow.
(In reply to Ed Lee :Mardak from comment #0)
> I would assume this is not intended

Right, thanks for filing this Ed.
Assignee: nobody → adw
Status: NEW → ASSIGNED
I think I've been hitting this too, I've had a few mysterious instances of typing something in the URL bar (and intending to search or select a result), and instead getting a search from an apparently-random search engine instead...
I think we should change the mouseover to a mousemove.  The one-off UI in about:newtab/home uses mousemove: https://hg.mozilla.org/mozilla-central/annotate/e78975b53563d80c99ebfbdf8a9fbf6b829a8a48/browser/base/content/contentSearchUI.js#l884

I vaguely recall Nihanth mentioning he used mousemove there because of this exact problem.
(In reply to Justin Dolske [:Dolske] from comment #2)
> I think I've been hitting this too

(Yep -- happened again, and this time I noticed the mouse happened to be over the Wikipedia icon, which is where the unexpected search went.)

Mousemouse should definitely improve things, although...

* It's not too hard to accidentally trigger a slight mouse movement by brushing a touchpad or jiggling a mouse (I'M TYPING WITH MY FISTS!!!). Maybe this should at least be a mouseenter, to more strongly indicate that the user is making a significant movement and explicit choice? [ie, you've moved the mouse from outside the icon.]

* But, really, why is this mouse-position based at all? I'm not sure of the UX thinking here. Seems like the normal approach would be to click on the icon, triggering a search with that provider. The hover-UI only seems useful if you want to start typing something, select a different provider, and then type some more to finish the search... But that seems like a odd use-case, and is physically awkward (moving hands from keyboard to mouse then back to keyboard). I could see wanting to allow selecting a provider before typing anything -- but that would seem easy to special-case by having the click basically make the provider the (temporary) default, without triggering the search immediately.
Comment on attachment 8779125 [details]
Bug 1293300 - Accidental one-off search if mouse pointer hovers over a search engine when typing in location bar and pressing enter.

https://reviewboard.mozilla.org/r/70172/#review67662

The problem is in the handleCommand method in urlbarBindings.xml. We should be using selectedButton for keyboard events (the enter key), visuallySelectedButton is only for when the user is clicking the one-off button.
Attachment #8779125 - Flags: review?(florian) → review-
(In reply to Justin Dolske [:Dolske] from comment #5)
> Mousemouse should definitely improve things, although...
> 
> * It's not too hard to accidentally trigger a slight mouse movement by
> brushing a touchpad or jiggling a mouse (I'M TYPING WITH MY FISTS!!!).

This is not new, we've had this behavior forever for normal autocomplete results. I don't think it makes much sense to treat these "buttons" or whatever they are differently.

(In reply to Florian Quèze [:florian] [:flo] from comment #6)
> The problem is in the handleCommand method in urlbarBindings.xml. We should
> be using selectedButton for keyboard events (the enter key),
> visuallySelectedButton is only for when the user is clicking the one-off
> button.

Maybe so, but "visually" selecting a button just because the mouse pointer happened to be there before the popup opened is still confusing, so we should still be using mousemove.
(In reply to Dão Gottwald [:dao] from comment #7)

> (In reply to Florian Quèze [:florian] [:flo] from comment #6)
> > The problem is in the handleCommand method in urlbarBindings.xml. We should
> > be using selectedButton for keyboard events (the enter key),
> > visuallySelectedButton is only for when the user is clicking the one-off
> > button.
> 
> Maybe so, but "visually" selecting a button just because the mouse pointer
> happened to be there before the popup opened is still confusing, so we
> should still be using mousemove.

Well, I'm not against changing the handler to mousemove, but it doesn't fully fix the problem, as Justin pointed out in comment 5.
Duplicate of this bug: 1294110
OK, I see.  Updating the popup's searchengine results with the visually selected engine is also wrong then.  Instead they should reflect the "logically" selected engine.

This patch also fixes a typo:

> -                  action.params.engineName = engine.name;
> +                  action.params.engineName = selectedOneOff.engine.name;
Moving the nom over from Bug 1294110 - makes sense to track this for 51.
Comment on attachment 8779125 [details]
Bug 1293300 - Accidental one-off search if mouse pointer hovers over a search engine when typing in location bar and pressing enter.

https://reviewboard.mozilla.org/r/70172/#review68700
Attachment #8779125 - Flags: review?(florian) → review+
Pushed by dwillcoxon@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/89ba380478e3
Accidental one-off search if mouse pointer hovers over a search engine when typing in location bar and pressing enter. r=florian
Duplicate of this bug: 1292695
https://hg.mozilla.org/mozilla-central/rev/89ba380478e3
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
I have reproduced this bug with Nightly 51.0a1(2016-08-08) on Windows 10, 64 bit.

The Bug's fix is now verified on latest Nightly 51.0a1

Build ID 	20160824030337
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0

[bugday-20160824]
I have reproduced this bug with Nightly 51.0a1 (2016-08-08) on Elementary OS 64bit. 

This bug's fix is now verified on Latest Nightly 51.0a1

Build ID 	20160825030226
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0

[bugday-20160824]
Thank you both!
Status: RESOLVED → VERIFIED
Flags: qe-verify+
I can also confirm the fix. I used Fx 51.0b10 on Windows 10 x64.
You need to log in before you can comment on or make changes to this bug.