1060888 - Autocomplete drop down list item should not be copied to the search fields when mouse over the list item

Status: VERIFIED FIXED

(Firefox :: Search, defect)

Description

[Alice0775 White]

Steps to reproduce:
1. Type something(e.q., mozilla) into the search fields of about:home/about:newtab
2. Move mouse pointer to any position through autocomplete drop down list
   (regardless of an accident or intentional)

Actual Results:
An item of drop down list will be copied to the search field unexpectedly.
This fact, the term that you have typed will be lost.

Expected Results:
Autocomplete drop down list item should not be copied to the search fields when mouse over the list item.

Comment 1

[Alice0775 White]

[Tracking Requested - why for this release]: regression

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Indeed, tracking. Thanks.

Ed, can you help here?

Comment 3

[Johannes Pfrang [:johnp]]

Just as a notice: Input isn't lost, but can be restored by clicking somewhere else or moving back to the search field using the arrow keys. Somehow, contrary to my understanding, clicking into the search field doesn't do the same as moving back into the search field using the arrow keys. It simply does nothing. Probably a separate bug?

Anyway: In the SearchSuggestionUIController we're updating the search fields input value when setting selectedIndex, which happens on every onMousemove and onKeypress with KEY_DOWN/_UP. We have a seperate variable _stickyInputValue to be only touched on onMousedown and onKeypress with KEY_ENTER when the user *intentionally* selects  a suggestion. Seems to me we should only touch the search fields input value when changing the latter.

Comment 4

[Johannes Pfrang [:johnp]]

Ahh, forget the "clicking into the search field" vs "navigating into the search field" it is ofc triggered by this bug.

Comment 5

[Johannes Pfrang [:johnp]]

And if copying on set selectedIndex is intentional we should go back to the original state on mouseleave. Make things triggered by mouse movement revertible by mouse movement.

Comment 6

[Alice0775 White]

(In reply to Johannes Pfrang [:johnp] from comment #3)
> Just as a notice: Input isn't lost, but can be restored by clicking
> somewhere else or moving back to the search field using the arrow keys.

During pending composition IME, it actually cleared. the workaround does not work.

Comment 7

[Johannes Pfrang [:johnp]]

Sorry, I misunderstood. When you're still typing while the search field is populated by the (accidentally selected) search suggestion (because of moving the mouse pointer below the search field), you're appending characters to the search suggestion and not to your input.

I haven't thought of this because you have to move the mouse in between typing to get such an accidental suggestion to fill the search field. There is even a comment about this in the source:

> // It's important to listen for mousemove, not mouseover or mouseenter.  The
> // latter two are triggered when the user is typing and the mouse happens to
> // be over the suggestions popup.

Comment 8

[Ed Lee :Mardak]

(In reply to Sylvestre Ledru [:sylvestre] from comment #2)
> Ed, can you help here?
sylvestre, what am I helping here? Figuring out what should happen or changing the behavior?

In terms of the dataloss keyword, I don't think that's quite accurate as you can "undo" the text box and get back the original value. It's the first context menu item or ctrl/cmd-Z.

The bug described in comment 0 is implemented as per mconnor's bug 612453 comment 23. There was also extra work done to make sure the mouse happening to hover over the menu would not trigger autocomplete unless moved per bug 612453 comment 65: "This also fixes a problem where if the mouse happened to be over the popup when it opens, then the row that the mouse is over gets injected into the input, and it's impossible to edit the text in the input because the row keeps getting injected.  The problem was using mouseover instead of mousemove, like Mike's patch did, so I switched back to mousemove."

mconnor, could you provide some context on the decision to have this functionality?

adw noted some UX inconsistencies in bug 612453 comment 86: "When you mouse over a suggestion, it's placed in the input.  Note that using the arrow keys to choose a suggestion does place it in the input, both in about:home's popup and the main search bar's."

This led to the UX bug 1047354 where mmaslaney provided some visual guidance, but the only thing I see about mouse is about how the list items should look when hovered: http://people.mozilla.org/~mmaslaney/Search/Autocomplete-dropdown-spec.png

mmaslaney, what should the textbox behavior be when hovering over items?

Comment 9

[Sylvestre Ledru [:Sylvestre]]

(In reply to Ed Lee :Mardak from comment #8)
> (In reply to Sylvestre Ledru [:sylvestre] from comment #2)
> > Ed, can you help here?
> sylvestre, what am I helping here? Figuring out what should happen or
> changing the behavior?
Yes, I wasn't expecting it was on purpose since this behavior is quite unusual (at least for me).

Comment 10

[Michael Maslaney [:mmaslaney] ([e-mail])]

The Autocomplete drop down list item should not be copied to the search fields when mouse over the list item.

Comment 11

[Johannes Pfrang [:johnp]]

So this would make it impossible to edit a search suggestion on about: pages but having to first visit the search provider before completing the search string (after clicking on the first word of your search for example) or (after experiencing the instant loading behaviour first) to not use the suggestions as long as it doesn't fit perfectly. That were my thoughts on possibly leaving the behaviour but just restoring onmouseout, because the selection already has to be done on purpose by mouse movement and deselection could then be done as easily. ofc I'm no UI expert so that's just FYI.

Comment 12

[Ed Lee :Mardak]

(In reply to mmaslaney from comment #10)
> The Autocomplete drop down list item should not be copied to the search
> fields when mouse over the list item.
mmaslaney, to be clear, there should be no way to edit a search suggestion with the mouse as desired in comment 11? The user would still be able to select and edit suggestions with the keyboard (down, delete).

Comment 13

[Johannes Pfrang [:johnp]]

Ed, no desire really, just a thought. Doing it like you both suggest will be the same behavior as other dropdown suggestion fields like that on Google Search which would understandably be a good UI decision. The incentive leading to my thought was just the "disruption" caused by navigating to the search provider. In any way, as ed says, one can still select&edit using the keyboard, which would understandably be good enough. Just remembering Google from the time, before typing into the search field automatically directed you to the search result view without reload (which now effectively nullifies the disruption), must have had the same behavior as far as I remember.

Comment 14

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to mmaslaney from comment #10)
> The Autocomplete drop down list item should not be copied to the search
> fields when mouse over the list item.

Exactly. Summing up:

User moves the mouse over an entry: Entry is highlighted. Text in textbox doesn't change.
User clicks on an entry: Textbox value is changed to match that entry and a search is triggered immediately.
User uses arrow keys to move through the list: Textbox reflects the currently selected item.

This behavior is also used by the major search providers on their sites.

Comment 15

[Mike Connor [:mconnor]]

Honestly, I have no idea why I built it this way.  Maybe Google was doing it at the time?  Seems sort of silly, and we shouldn't do it.

Comment 16

[Drew Willcoxon :adw]

Attachment: search-suggestion-no-mouseover-1060888

Comment 17

[Drew Willcoxon :adw]

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

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8aa5a115ceae

Comment 19

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

Drew: just a reminder to request approval for 33/34 here.

Comment 20

[Drew Willcoxon :adw]

Comment on attachment 8490289 [details] [diff] [review]
search-suggestion-no-mouseover-1060888

Approval Request Comment
[Feature/regressing bug #]: search suggestions in about:home/newtab (bug 612453)
[User impact if declined]: search suggestions popup in about:home/newtab will behave a little differently from the main search bar's popup
[Describe test coverage new/current, TBPL]: automated testing
[Risks and why]: low risk, only changes mouseover behavior of about:home/newtab suggestions
[String/UUID change made/needed]: none

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/39e02526888e
https://hg.mozilla.org/releases/mozilla-beta/rev/6975bbd6c73a

Comment 22

[Petruta Horea [:phorea], Desktop QA]

Verified as fixed on latest Aurora 34.0a2 (20140922004004) and latest Nightly 35.0a1 (20140921030208) under Win 7, 64-bit, Ubuntu 12.10 32-bit and Mac OSX 10.9.5. 

Drew, the text from mouse over is copied in the textbox when the right arrow is pressed. It this ok?

Comment 23

[Drew Willcoxon :adw]

Could you please file a new bug?

Comment 24

[Drew Willcoxon :adw]

Sorry, I misread.  When you press the right arrow key the text should be copied to the textbox.  I read "right button."

Comment 25

[Petruta Horea [:phorea], Desktop QA]

Thanks Drew!

Verified today using Firefox 33 beta 6 (20140922173023) under all platforms.