Page MenuHomePhabricator

Dead keys prevent autocomplete in search box
Open, LowPublic

Description

Summary: Autocomplete in the search box does nothing if you type a character that uses a dead key (a key that put an accent or other diacritic on the next letter you type), the Javascript "keypress" event listener doesn't get the message that anything has happened. This is true for Latin and Greek characters with dead keys. Using "onkeyup" may solve the problem.

It isn't clear what other UI elements are affected beside the search box, if any.

I'm not sure what projects this applies to, since it is a UI problem on an element used for search.

Earlier discussion from T75605:

@Xoristzatziki in T75605#3417714:

A bug, which may be related, still exists for Greek terms (in ALL projects, even in en.wiktionary) . Typing in the search box anything that ends in accented letter does not provide any suggestions that include the last letter (even if they exist ex. καλά). Copying and pasting works. Also typing anything after (ex. a space) works. It seems (to user) like the search is not done by the really typed letters, and the code is "waiting" for something.

@TJones in T75605#3421129:

... the scope is much bigger than accented Greek characters. ... I'm pretty sure this is a Javascript issue.

For my quick test, I'm on a Mac, using the American, French, and Greek keyboards, and I tested in Chrome, Safari, and Firefox. To my surprise, they all behave the same.

If you use dead keys (keys that put an accent or other diacritic on the next letter you type), the Javascript "keypress" event listener doesn't get the message that anything has happened. I tested this with both Latin and Greek letters on the Mac keyboards.

As I understand it, the Greek keyboard uses a dead key to add ´ and ¨ to vowels. Similarly in the Mac American keyboard has dead keys for several diacritics (I use ´ ¨ ˆ ` ˜ regularly). If I type resumé to search on English Wiktionary, I also don't get any more suggestions for the final é. (BTW, it happens for non-final letters, too, if you pause, but it's easy to miss if you keep typing).

On the French keyboard, é has its own key, and when I type resumé using that keyboard, it behaves as expected.

On the Mac Greek keyboard (so this probably does not apply to Windows or Linux), I can type ά by typing option+shift+α. If I type καλά this way it gets suggestions as expected. Similarly, you can use option+shift+<x> to type other accented vowels: 1/έ 2/ί 3/ή 4/ό 0/ύ ./ώ —I didn't see any precomposed versions with diaeresis (i.e, ϊ or ϋ ). These non-dead-key versions generate new suggestions.

So, the problem isn't accented characters per se, but rather characters that have to be typed with dead keys, at least on a Mac keyboard. I'm not familiar with the UI code that's handling all this, so I have no idea how easy it would be to fix, but searching online shows a lot of people complaining about this, but no obvious solutions.

@Xoristzatziki in T75605#3651879:

The problem is in the code for sure. The accent in dead keys in Greek keyboard are typed first so the last key pressed is a non dead key. onkeyup works in my tests.

(See link for attachments.)

Related Objects

StatusSubtypeAssignedTask
OpenNone
Resolvedovasileva
ResolvedJdlrobson
ResolvedNone
Resolvedkostajh
ResolvedSpike nray
ResolvedSpikeVolker_E
ResolvedJdrewniak
ResolvedJdrewniak
ResolvedSpikeNone
ResolvedSpikeNone
ResolvedSpikeJdlrobson
ResolvedSpikeNone
ResolvedSpike holger.knust
ResolvedSpikeJdlrobson
DuplicateNone
Resolved nray
ResolvedSpike Niedzielski
ResolvedSpike Niedzielski
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedSpikeVolker_E
ResolvedSpikeVolker_E
ResolvedJdrewniak
ResolvedJdlrobson
Resolved nnikkhoui
ResolvedNone
Resolved nnikkhoui
ResolvedJdlrobson
Resolved nnikkhoui
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedVolker_E
Resolvedphuedx
Resolved eprodromou
ResolvedEvanProdromou
ResolvedPeter.ovchyn
ResolvedPeter.ovchyn
ResolvedPeter.ovchyn
Resolved eprodromou
ResolvedPeter.ovchyn
Resolveddaniel
Resolveddaniel
Resolveddaniel
Resolved holger.knust
Resolved holger.knust
Resolved holger.knust
OpenNone
OpenNone
OpenNone
ResolvedSpikeovasileva
Resolvedphuedx
ResolvedJdrewniak
Resolved alexhollender_WMF
Resolvedovasileva
ResolvedJdlrobson
ResolvedJdrewniak
ResolvedJdrewniak
Resolved Niedzielski
ResolvedMNeisler
Resolvedovasileva
Resolvedphuedx
Resolvedovasileva
Resolvedovasileva
Resolved nray
OpenNone
Resolvedovasileva
ResolvedVolker_E
ResolvedAnneT
ResolvedStevenSun
DeclinedNone
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedphuedx
Resolvedovasileva
ResolvedMNeisler
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
DuplicateNone
Resolved alexhollender_WMF
ResolvedMNeisler
ResolvedJdlrobson
DuplicateNone
Resolvedovasileva
Resolvedovasileva
Declinedovasileva
Resolvedovasileva
Resolvedovasileva
ResolvedEdtadros
DeclinedNone
DeclinedNone
ResolvedJdrewniak
ResolvedJdrewniak
Resolved nnikkhoui
Resolved nnikkhoui
ResolvedJdlrobson
Duplicateovasileva
ResolvedMNeisler
ResolvedVolker_E
Resolvedphuedx
Resolvedovasileva
Resolvedovasileva
Resolvedsbassett
Resolved jlinehan
ResolvedTgr
ResolvedNone
Resolved jlinehan
Resolved jlinehan
ResolvedOttomata
ResolvedOttomata
ResolvedSpikeJdlrobson
Resolved jlinehan
OpenNone
Resolved jlinehan
Resolved jlinehan
Resolved jlinehan
Resolved jlinehan
ResolvedJdlrobson
Resolved jlinehan
Resolved jlinehan
ResolvedTgr
Resolvedcolewhite
DeclinedNone
ResolvedNone
Resolved jlinehan
ResolvedTgr
ResolvedBUG REPORTTgr
OpenNone
DeclinedNone
Resolvedphuedx
Resolved alexhollender_WMF
Resolvedovasileva
DuplicateNone
Resolved alexhollender_WMF
ResolvedMNeisler

Event Timeline

Framawiki subscribed.

Interesting issue ! I don't know if it's a MediaWiki-Search or a CirrusSearch one (if Cirrus is the backed, it's probably the original MW JS code that is concerned ?).

@Framawiki, I'm not even sure this is a search issue, or if the properties and hooks of the search box are defined by UI code elsewhere.

The code for this is in resources/src/jquery/jquery.suggestions.js (mostly defines the behavior of the suggestions) and resources/src/mediawiki/mediawiki.searchSuggest.js (mostly defines how to get data from the API and emits some analytics events). The interesting parts are:

jquery.suggestions.js
					.keydown( function ( e ) {
						// Store key pressed to handle later
						context.data.keypressed = e.which;
						context.data.keypressedCount = 0;
					} )
					.keypress( function ( e ) {
						context.data.keypressedCount++;
						$.suggestions.keypress( e, context, context.data.keypressed );
					} )
					.keyup( function ( e ) {
						// The keypress event is fired when a key is pressed down and that key normally
						// produces a character value. We also want to handle some keys that don't
						// produce a character value so we also attach to the keydown/keyup events.
						// List of codes sourced from
						// https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode
						var allowed = [
							40, // up arrow
							38, // down arrow
							27, // escape
							13, // enter
							46, // delete
							8 //   backspace
						];
						if ( context.data.keypressedCount === 0 &&
							e.which === context.data.keypressed &&
							$.inArray( e.which, allowed ) !== -1
						) {
							$.suggestions.keypress( e, context, context.data.keypressed );
						}
					} )

And also this in the other file (which probably should be in the first one…)

mediawiki.searchSuggest.js
			.on( 'paste cut drop', function () {
				// make sure paste and cut events from the mouse and drag&drop events
				// trigger the keypress handler and cause the suggestions to update
				$( this ).trigger( 'keypress' );
			} )
This comment was removed by matmarex.

As a side note, in OOjs UI, we bind all of the following events to catch all the possible ways to change the contents of an input field: keydown mouseup cut paste change input select. (The suggestions code here doesn't use OOjs UI; but this might be useful to know when looking for a solution here.)

debt triaged this task as Medium priority.Oct 5 2017, 5:22 PM
debt moved this task from needs triage to Up Next on the Discovery-Search board.
debt added subscribers: Jdrewniak, debt.

This might be something that @Jdrewniak can take a look at.

EBernhardson subscribed.

Without any front end engineers on the team anymore it's unlikely Search Platform will be able to assist with this.

CBogen lowered the priority of this task from Medium to Low.Aug 27 2020, 9:58 PM

In Korean language, there is not this issue in Vue.js search experience.

MPhamWMF subscribed.

Closing out low/est priority tasks over 6 months old with no activity within last 6 months in order to clean out the backlog of tickets we will not be addressing in the near term. Please feel free to reopen if you think a ticket is important, but bare in mind that given current priorities and resourcing, it is unlikely for the Search team to pick up these tasks for the indefinite future. We hope that the requested changes have either been addressed by or made irrelevant by work the team has done or is doing -- e.g. upgrading Elasticsearch to a newer version will solve various ES-related problems -- or will be subsumed by future work in a more generalized way.

RhinosF1 removed a project: Discovery-Search.
RhinosF1 subscribed.

Re-opening tasks and removing from team workboard per IRC feedback given yesterday and discussion with MPham.