There are a number of different issues here: - keyboard selection of a search engine, followed by mouse hover over a search engine, followed by enter - keyboard selection of a search engine, followed by mouse hover over a suggestion, followed by enter - keyboard selection of a suggestion, followed by mouse hover over a search engine, followed by enter - keyboard selection of a suggestion, followed by mouse hover over a suggestion, followed by enter and then for each of these, one could potentially add more keyboard navigation after the mouse hover, before hitting enter. What we need to know is: - what happens when you hit enter (which suggestion and which engine get used) (- potentially: how does the hover affect any keyboard selection after it's happened) - how do we visualize this as the user hovers/further-keyboard-navigates It's not obvious what the answers here are. For the location bar we only have one list of 'things', and while it shows hover as 'selection', enter will use the keyboard-inputted (and completed into the input box) item. Only clicks activate the item indicated by the mouse. We could try to do the same here, but you run into the fact that: - the search engine is not visible / put in the search box like the URL/search is - showing two items as selected is confusing - having two lists means that manipulating both items with both forms of inputs quickly gets confusing. The one thing we seem to agree on so far is that the current behaviour (hover always influences everything) is unintuitive and messes things up esp. when unintentional mouse moves happen. Philipp, can you untangle this? :-)

Related: bug 1118691

Forwarding this to Aislinn so that it doesn't get stuck on me (I'm out next week). Meanwhile, here are a few spontaneous thoughts: - We are currently conflating two things: feedback that a thing is clickable (hover) and showing what is selected through keyboard input. - The value inside the text box is another piece of feedback to consider. - Whatever behavior we decide on here, we should also transfer it to the awesomebar - Chrome and Safari have two very different, but internally consistent behaviors here. In Chrome, hovering just gives feedback without selecting anything, in Safari, hovering changes the selection *including* the text in the box. - I find Chromes behavior a lot clearer. It also prevents all those accidental selection bugs.

Draft 1 of rules around hover. Not quite sure around state when keyboard select a provider then hover over another. To be consistent think we should respect the keyboard select but the feedback is pretty minimal given its just the 'search for with' text.

Hi Aislinn, can you provide a point value.

(In reply to Marco Mucci [:MarcoM] from comment #4) > Hi Aislinn, can you provide a point value. 5 points

Comment on attachment 8578871 [details] hover bug v1.png (In reply to agrigas from comment #3) > Created attachment 8578871 [details] > hover bug v1.png > > Draft 1 of rules around hover. Not quite sure around state when keyboard > select a provider then hover over another. To be consistent think we should > respect the keyboard select but the feedback is pretty minimal given its > just the 'search for with' text. Looks good! As for the case you described: I agree that the feedback is minimal, but in the majority of cases (moving the mouse by accident) that won't really matter. Note: We should implement the same behavior (where applicable) for the awesomebar as well.

(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #6) > Comment on attachment 8578871 [details] > hover bug v1.png > > (In reply to agrigas from comment #3) > > Created attachment 8578871 [details] > > hover bug v1.png > > > > Draft 1 of rules around hover. Not quite sure around state when keyboard > > select a provider then hover over another. To be consistent think we should > > respect the keyboard select but the feedback is pretty minimal given its > > just the 'search for with' text. > > Looks good! > As for the case you described: I agree that the feedback is minimal, but in > the majority of cases (moving the mouse by accident) that won't really > matter. > > Note: We should implement the same behavior (where applicable) for the > awesomebar as well. I'm confused. AIUI the suggestion here is that if you keyboard-select a different provider and then mouse-hover over a suggestion, and then hit enter, you would search with the default provider? That seems wrong to me...

Hm, it probably depends on which case we prioritize: - If the user moves the mouse accidentally or very shortly before pressing enter, using the selected engine makes most sense - If a lot of time passes between the user selecting and pressing enter (possibly with other actions like typing happening in between), using the default makes more sense I think the second case is a lot rarer, so I would agree that using the selected engine makes more sense. Or am I missing something there, Ash?

(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #8) > Hm, it probably depends on which case we prioritize: > - If the user moves the mouse accidentally or very shortly before pressing > enter, using the selected engine makes most sense > - If a lot of time passes between the user selecting and pressing enter > (possibly with other actions like typing happening in between), using the > default makes more sense > > I think the second case is a lot rarer, so I would agree that using the > selected engine makes more sense. > Or am I missing something there, Ash? Yes, I think the spec mis-stated the behavior for that use case. Keyboard select is our strongest indication of intent, so that engine should be used for the clicked on suggestion.

Would you consider a pref that submitting a search by pressing Enter always uses the search engine displayed immediately below the bar vs. the hovered search engine? Reason being that I tend to type very fast and submit using Enter, and I do not look for the blue highlight during that time. Perhaps as a result of bumping the mouse, I have accidentally sent health-related and other personal searches to ecommerce and social sites, which I consider a problem from a privacy perspective.

(In reply to Jefferson from comment #10) > Would you consider a pref that submitting a search by pressing Enter always > uses the search engine displayed immediately below the bar vs. the hovered > search engine? Reason being that I tend to type very fast and submit using > Enter, and I do not look for the blue highlight during that time. Perhaps as > a result of bumping the mouse, I have accidentally sent health-related and > other personal searches to ecommerce and social sites, which I consider a > problem from a privacy perspective. No, we should just fix the dependent implementation bugs. We know what interaction is required here, we just haven't been able to find time to implement it.