simon wrote:

The behaviour of our search box drop down selection differs from google, for instance.

Google does not highlight a dropped down item when it is displayed so as to overwrite the position of the mouse, until the mouse is moved. Equally, Google then ignores a highlighted drop-down item if the return key is pressed; instead it requires the user to use the mouse button to search on the selected item.

The way Google works is more sophisticated and full-featured; so, to clarify: Text should be accepted in the text box without requiring the user to escape the dropdown or grab the mouse. The text box should not loose keyboard focus when a dynamic object happens to float under the mouse, and even when the user has intentionally hovered elsewhere on the page. "What you see in the text box is what you get when you press 'enter'." Full stop.

veryfurryfur wrote:

More background can be found here:

http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/May_2010_skin_change/Bug_reports#Search_box_selection_issue

In particular, one can read some reasons why the current implementation is objectively wrong and why Google's (and Firefox's) implementation is, indeed, correct.

I'll quote them here, trying to remove some unnecessary color in that thread:

"
The mouse is [under the search box] more often than not, [because] I have to click on [it] before I can search for something.
If I hit enter on the keyboard then it means that my right hand is not using a mouse, and I mean to search for what I have just typed. [Why] force everyone to grab the mouse and click on the magnifying glass icon, when my pinkie can hit return 100 times faster?
"

"
[Why would a mouse user] (1) stop typing, (2) grab the mouse, (3) move it to select a suggestion and then (4) move back to the keyboard and hit Enter?
"

• IMPORTANT ******

However, there is one further subtlety which is also missing from the current implementation and I think has not been identified yet. If one starts typing, and then presses the ARROW-DOWN key to pick up a suggestion, then the search box should have its contents replaced with that suggestion.

If the behavior is (correctly) changed to always use what is in the text box if ENTER is pressed, then we must also implement this other improvement, otherwise users who are currently happily using the arrow keys to select a suggestion will complain about the new behavior ignoring their choice.

• IMPORTANT ******

If I am allowed a final comment, I am a bit surprised that UAT did not pick this up. I am also even more surprised that the developers had to reinvent the wheel and roll out their own component, when I'm sure there are plenty good, time-tested libraries out there.

amiller1 wrote:

Fixed this in r68050.

As for the other comments, there's been a fair amount of discussion regarding the updating of the textinput as you scroll through suggestions. The reason it was thought best not to highlight was because of the special 'Containing...' option at the end of the suggestions. I shall quote Trevor Parscal here (from a comment on another of my revisions http://www.mediawiki.org/wiki/Special:Code/MediaWiki/64718#c7215 ):

"This was part of a redesign of the control. Howie, Parul and I worked together to figure out how to fix some of the odd bits with the UI. The problem with changing the term in the textbox as you arrow up and down is that if you reach the "containing" item, it's unclear what term you mean to use a full text search because the textbox is now filled with the last suggestion, even if you were to restore it upon reaching that item to the originally typed text, it's just not intuitive to have it changing like that. Now, the textbox only shows the term you have actually typed, making the "containing" item consistent despite the currently selected suggestion."

So that was the thinking behind it. If that doesn't jive with you guys, let us know and we can collectively reexamine that thinking.

veryfurryfur wrote:

Thank you Adam.

I assume by "fixed" you mean that when ENTER is pressed, the search will always be done on whatever is in the text box at that time, irrespective of the list selection.

Also, if I interpret your comment correctly, you did _not_ implement the change whereby the text box is filled with the selection when moving with the arrow keys, and the reason is that you don't know what to do when it comes to the "containing..." item.

My first thought is that the search bar is being given too many responsibilities. Not having read the manual, my understanding is that the "containing..." feature will display search results even if there is an exact match with an article title.
I would say this would be best done with a check box, probably in a separate "Advanced Search" page (a link for which is customary and missing).

If there is no easy way to get rid of this "containing..." item, then we could come up with a special "Search:" or "Containing:" namespace and just put "Search:foo" or "Containing:foo" in the text box when "containing..." is reached (by keyboard).

Or, although I appreciate this would be quite a drastic change, we can add a link ("Did you want to search for articles containing 'foo'?") when reaching an article via an exact search match.

A final horrible but easy work-around is to simply disallow users to reach the "containing..." item via the keyboard, making it "unselectable".

None of these alternatives is perfect, but I think each of them is better than ignoring the problem. People (especially keyboard users) _will_ come back after your fix, complaining that search suggestions broke ("Type 'pizza', arrow down twice, hit ENTER, I am taken to 'Pizza', but I wanted 'Pizza Hut'! This used to work!!1!")

veryfurryfur wrote:

I took the liberty of reopening this, because I know _I_ would be one of those keyboard users complaining that arrows don't work any more :-) Feel free to re-close if I misunderstood what's going to happen.

Another possible quick and not too horrible solution: "ENTER" means "search for whatever is in the text box, unless 'containing...' is selected _and_ that selection was reached using the keyboard".
(You will need to keep a flag around for that last check)

If we do this, then it doesn't really matter what you put in the text box. For example you could put back the original search term, perhaps in italics, so it's clear that it's not a kind of search that can be performed by simply typing in the box (which I think is the root of our problem, and therefore the "containing..." item should not be put in the suggestions in the first place)

Thanks again

A couple thoughts here:

(1) Would it be possible to treat "received focus from arrow keys" and "highlighted by mouse hovering" as two distinct states so that the mouse does not steal keyboard focus?

(2) Could the "Containing..." conundrum be resolved by moving it from the dropdown to a "Go" button (right-pointing arrow icon) adjacent to the "Search" button (magnifying glass icon) and making the buttons keyboard-selectable by tabbing from the textbox?

simon wrote:

As far as I can determine, the current behaviour is that:

• Having a mouse under the dropped down suggestions no longer selects (I think

we're all agreed this is good)

There are two further elements of behaviour under discussion.

1. If a suggestion has been highlighted by a mouseover, should a search invoked

using the enter key be on the search box string or the suggestion string.

Currently, google would search on the search box string. Wikipedia searches on
the highlighted item.

2. If the user uses the cursor keys to move through the suggestions, 2a) should

the currently highlighted suggestion be moved into the search box and 2b) what
should the enter key behaviour be - search on the search box string, or the
highlighted string?

Currently, google does move the item into the search box, and enter will search
on it. Wikipedia does not move the item into the search box, but on enter, will
search for the highlighted item.

Opinions vary as to what the desired behaviour should be...

veryfurryfur wrote:

Ningauble:

1. Do I understand your question correctly? Currently the "highlighted by mouse hovering" event does not steal keyboard focus, so yes, it is possible (but how would it help our problem?)

2. It's definitely one option, good thinking. One could say that Wikipedia has always had only one "I'm feeling lucky" button, and now we are trying to introduce a "Search" button as well.

tagishsimon:

I cannot agree with your analysis. It's not a matter of opinion, it's just broken. You may want to re-read the quoted excerpts in comment #3. They make perfect sense to me, and apparently they convinced Adam, too.

Given how long we've survived without this _additional_ "containing..." feature, in my opinion it should be pulled until we find a way to introduce it that does not break everything else. Until then, relegating it to the "advanced search" sounds like the best option to me.

simon wrote:

YMMV, Ichiro. For me, "it's just broken" is a fairly sterile debate. So far as the enter key is concerned, there are two approaches: that which is in the search box is searched for, or that which is highlighted is searched for. Both work. One may be more preferable than the other; I don't have a position on which is better.

Happily, I do strongly disagree that we should pull the "containing..." element of the search until we find a way ... etc. First, it does not seem to me that it is breaking anything. Second, it is the most useful element of the search for me.

Something which is broken does not work. Clearly the search does work right now, and we're discussing ways in which its UI can be improved.

veryfurryfur wrote:

I don't have access to the development environment, but my understanding of Adam's explanation of how he fixed it was that the following complaint would now apply:

"Type 'pizza', arrow down twice, hit ENTER, I am taken to 'Pizza', but I wanted 'Pizza Hut' (the second suggestion in the list)! This used to work!"

Having heard nobody denying that this would happen in the checked-in version, that's still my current understanding, but I'm happy to stand corrected.

veryfurryfur wrote:

I just had a closer look at the diff, and it looks like the fix simply consists in highlighting suggestions on a mousemove event instead of a mouseover.

My interpretation of Adam's comment was therefore incorrect, and this solution seems to address all my concerns.

Is there a testing environment I can use to try the new version?

Reclosing this bug as FIXED: the original issue (stuff breaking when mouse below search input) has been fixed. The other issue with the arrow down key is bug 23611.

(In reply to comment #9)
This is closed, and _mostly_ worksforme because inadvertent hovering is no longer such a problem. However, I would like to clarify:

..."highlighted by mouse hovering" event does not steal keyboard focus, so yes, it is possible (but how would it help our problem?)

Ok, "steal keyboard focus" overstates the case, it only steals enterkey behavior. Standard behavior in a combo textbox/listbox is that typing in the textbox and selection with arrow keys are committed by Enter or Tab, and mouse selection is committed by Left-Click. Distinguishing "highlighted by mouse hovering" as a recognizable state would help by enabling the program to avoid the error of misinterpreting Enter as a mouse action.

One could say that Wikipedia has always had only one "I'm feeling lucky" button, and now we are trying to introduce a "Search" button as well.

One could say that, but it would not be true. In the several years I used Wikipedia prior to the Usability Initiative rollout there have always been _two_ buttons: "I'm feeling lucky" (Go) and "Show list of search results" (Search), and this is still the case for projects that continue to use the Monobook skin by default.

veryfurryfur wrote:

When is this fix going to make it to Wikipedia? People are in pain. Thanks.