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
Openhashar
ResolvedSpikenray
ResolvedSpikeVolker_E
ResolvedJdrewniak
ResolvedJdrewniak
ResolvedSpikeNone
ResolvedSpikeNone
ResolvedSpikeJdlrobson
ResolvedSpikeNone
ResolvedSpikeholger.knust
ResolvedSpikeJdlrobson
DuplicateNone
Opennray
ResolvedSpikeNiedzielski
ResolvedSpikeNiedzielski
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedSpikeVolker_E
ResolvedSpikeVolker_E
ResolvedJdrewniak
ResolvedJdlrobson
Resolvednnikkhoui
ResolvedNone
Resolvednnikkhoui
ResolvedJdlrobson
Opennnikkhoui
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedVolker_E
Resolvedphuedx
Resolved eprodromou
ResolvedEvanProdromou
ResolvedPeter.ovchyn
ResolvedPeter.ovchyn
ResolvedPeter.ovchyn
Resolved eprodromou
ResolvedPeter.ovchyn
Resolveddaniel
Resolveddaniel
Resolveddaniel
Resolvedholger.knust
Resolvedholger.knust
Resolvedholger.knust
OpenNone
OpenNone
OpenNone
ResolvedSpikeovasileva
Resolvedphuedx
ResolvedJdrewniak
Resolvedalexhollender
Resolvedovasileva
ResolvedJdlrobson
ResolvedJdrewniak
ResolvedJdrewniak
ResolvedNiedzielski
ResolvedMNeisler
Resolvedovasileva
Resolvedphuedx
Resolvedovasileva
Resolvedovasileva
Resolvednray
OpenNone
Openalexhollender
Openalexhollender
OpenNone
Resolvedovasileva
OpenJTannerWMF
OpenNone
Resolvedphuedx
Resolvedovasileva
ResolvedMNeisler
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
DuplicateNone
Resolvedalexhollender
ResolvedMNeisler
ResolvedJdlrobson
DuplicateNone
Resolvedovasileva
Resolvedovasileva
Openovasileva
OpenMNeisler
Resolvedovasileva
ResolvedEdtadros
DeclinedNone
DeclinedNone
ResolvedJdrewniak
ResolvedJdrewniak
Opennnikkhoui
Resolvednnikkhoui
ResolvedJdlrobson
Duplicateovasileva
ResolvedMNeisler
ResolvedVolker_E
Resolvedphuedx
Resolvedovasileva
Resolvedovasileva
Resolvedsbassett
Resolvedjlinehan
Openjlinehan
ResolvedNone
Resolvedjlinehan
Resolvedjlinehan
ResolvedOttomata
ResolvedOttomata
ResolvedSpikeJdlrobson
Resolvedjlinehan
Openjlinehan
Resolvedjlinehan
Resolvedjlinehan
Resolvedjlinehan
Resolvedjlinehan
ResolvedJdlrobson
Resolvedjlinehan
Resolvedjlinehan
Opendr0ptp4kt
Resolvedcolewhite
DeclinedNone
ResolvedNone
Resolvedjlinehan
OpenNone
OpenNone
Openovasileva
Resolvedphuedx
Resolvedalexhollender
Resolvedovasileva
DuplicateNone
Resolvedalexhollender
ResolvedMNeisler

Event Timeline

Framawiki added a subscriber: Framawiki.

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 added a subscriber: EBernhardson.

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.