Closed Bug 1060888 Opened 5 years ago Closed 5 years ago

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

Categories

(Firefox :: Search, defect, critical)

33 Branch
defect
Not set
critical
Points:
2

Tracking

()

VERIFIED FIXED
Firefox 35
Iteration:
35.2
Tracking Status
firefox32 --- unaffected
firefox33 + verified
firefox34 + verified
firefox35 --- verified

People

(Reporter: alice0775, Assigned: adw)

References

Details

(Keywords: dataloss, regression, uiwanted)

Attachments

(1 file)

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.
[Tracking Requested - why for this release]: regression
Blocks: 612453, 1028985
Severity: major → critical
Indeed, tracking. Thanks.

Ed, can you help here?
Flags: needinfo?(edilee)
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.
Ahh, forget the "clicking into the search field" vs "navigating into the search field" it is ofc triggered by this bug.
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.
(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.
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.
(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?
Flags: needinfo?(sledru)
Flags: needinfo?(mmaslaney)
Flags: needinfo?(mconnor)
Flags: needinfo?(edilee)
(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).
Flags: needinfo?(sledru)
The Autocomplete drop down list item should not be copied to the search fields when mouse over the list item.
Flags: needinfo?(mmaslaney)
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.
(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).
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.
Flags: needinfo?(philipp)
(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.
Flags: needinfo?(philipp)
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.
Flags: needinfo?(mconnor)
Flags: qe-verify?
Flags: firefox-backlog+
Blocks: 1066794
Points: --- → 2
Flags: qe-verify?
Flags: firefox-backlog+
OS: Windows 7 → All
Hardware: x86_64 → All
Assignee: nobody → adw
Status: NEW → ASSIGNED
Attachment #8490289 - Flags: review?(MattN+bmo)
Iteration: --- → 35.2
Flags: qe-verify?
Flags: firefox-backlog+
Flags: qe-verify? → qe-verify+
Attachment #8490289 - Flags: review?(MattN+bmo) → review+
https://hg.mozilla.org/mozilla-central/rev/8aa5a115ceae
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
Depends on: 1068852
Drew: just a reminder to request approval for 33/34 here.
Flags: needinfo?(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
Attachment #8490289 - Flags: approval-mozilla-beta?
Attachment #8490289 - Flags: approval-mozilla-aurora?
Flags: needinfo?(adw)
QA Contact: petruta.rasa
Attachment #8490289 - Flags: approval-mozilla-beta?
Attachment #8490289 - Flags: approval-mozilla-beta+
Attachment #8490289 - Flags: approval-mozilla-aurora?
Attachment #8490289 - Flags: approval-mozilla-aurora+
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?
Could you please file a new bug?
Sorry, I misread.  When you press the right arrow key the text should be copied to the textbox.  I read "right button."
Thanks Drew!

Verified today using Firefox 33 beta 6 (20140922173023) under all platforms.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.