Page MenuHomePhabricator

Dead keys prevent autocomplete in search box
Open, NormalPublic

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.)

Event Timeline

TJones created this task.Oct 2 2017, 8:00 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 2 2017, 8:00 PM
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 ?).

Restricted Application added projects: Discovery, Discovery-Search. · View Herald TranscriptOct 2 2017, 8:15 PM
TJones added a comment.Oct 2 2017, 9:07 PM

@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 Normal 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.