Closed
Bug 1060888
Opened 10 years ago
Closed 10 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)
Tracking
()
People
(Reporter: alice0775, Assigned: adw)
References
Details
(Keywords: dataloss, regression, uiwanted)
Attachments
(1 file)
(deleted),
patch
|
MattN
:
review+
Sylvestre
:
approval-mozilla-aurora+
Sylvestre
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•10 years ago
|
||
[Tracking Requested - why for this release]: regression
Severity: major → critical
status-firefox32:
--- → unaffected
status-firefox33:
--- → affected
status-firefox34:
--- → affected
tracking-firefox33:
--- → ?
tracking-firefox34:
--- → ?
Comment 2•10 years ago
|
||
Indeed, tracking. Thanks.
Ed, can you help here?
Comment 3•10 years ago
|
||
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•10 years ago
|
||
Ahh, forget the "clicking into the search field" vs "navigating into the search field" it is ofc triggered by this bug.
Comment 5•10 years ago
|
||
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.
Reporter | ||
Comment 6•10 years ago
|
||
(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•10 years ago
|
||
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•10 years ago
|
||
(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)
Comment 9•10 years ago
|
||
(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)
Comment 10•10 years ago
|
||
The Autocomplete drop down list item should not be copied to the search fields when mouse over the list item.
Flags: needinfo?(mmaslaney)
Comment 11•10 years ago
|
||
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•10 years ago
|
||
(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•10 years ago
|
||
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.
Updated•10 years ago
|
Flags: needinfo?(philipp)
Comment 14•10 years ago
|
||
(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)
Comment 15•10 years ago
|
||
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)
Updated•10 years ago
|
Flags: qe-verify?
Flags: firefox-backlog+
Assignee | ||
Updated•10 years ago
|
Points: --- → 2
Flags: qe-verify?
Flags: firefox-backlog+
OS: Windows 7 → All
Hardware: x86_64 → All
Assignee | ||
Comment 16•10 years ago
|
||
Updated•10 years ago
|
Iteration: --- → 35.2
Flags: qe-verify?
Flags: firefox-backlog+
Updated•10 years ago
|
Flags: qe-verify? → qe-verify+
Updated•10 years ago
|
Attachment #8490289 -
Flags: review?(MattN+bmo) → review+
Assignee | ||
Comment 17•10 years ago
|
||
Comment 18•10 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
Comment 19•10 years ago
|
||
Drew: just a reminder to request approval for 33/34 here.
Flags: needinfo?(adw)
Assignee | ||
Comment 20•10 years ago
|
||
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)
Updated•10 years ago
|
QA Contact: petruta.rasa
Updated•10 years ago
|
Attachment #8490289 -
Flags: approval-mozilla-beta?
Attachment #8490289 -
Flags: approval-mozilla-beta+
Attachment #8490289 -
Flags: approval-mozilla-aurora?
Attachment #8490289 -
Flags: approval-mozilla-aurora+
Updated•10 years ago
|
status-firefox35:
--- → fixed
Comment 21•10 years ago
|
||
Comment 22•10 years ago
|
||
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?
Assignee | ||
Comment 23•10 years ago
|
||
Could you please file a new bug?
Assignee | ||
Comment 24•10 years ago
|
||
Sorry, I misread. When you press the right arrow key the text should be copied to the textbox. I read "right button."
Comment 25•10 years ago
|
||
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.
Description
•