Page MenuHomePhabricator

Help panel: typing Korean is broken in Help Panel Search bar
Closed, ResolvedPublic


How to reproduce:

Type ㅇ ㅕ ㅇ ㅇ ㅓ in Korean. (This merges to 영어, which means "English").

What's expected:

Search bar assembles to 영어.

What actually happens:

Search bar breaks it into ㅇㅕㅇ어. The first word is not merged into and that prevents search. When you delete the whole string and re-type the phrase, it works fine.


It was fine when I tested on beta-labs, namely at T214509: Help panel: testing search in Korean.


Reproduced on:

  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
  • Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36.

Event Timeline

revi created this task.Feb 14 2019, 12:39 PM
Restricted Application added a project: Growth-Team. · View Herald TranscriptFeb 14 2019, 12:39 PM
revi triaged this task as High priority.Feb 14 2019, 12:40 PM
revi moved this task from Incoming to Radar on the User-revi board.

@MMiller_WMF Didn't tag for Unbreak now! since you can (theoretically) remove the strings and re-type the word, but this should be solved ASAP.

CC: @Trizek-WMF

I can reproduce. My only hypothesis at the moment is that this might be a side-effect of setting spellcheck = true for the search input field, which isn't done in Minerva or Vector's search.

OK, the issue is not the spellcheck setting, I tested that locally just now.

Instead it looks like the commit which broke search for Korean is rEGRE89712d97571d5341210769e2ad785b26d08415cc When the user starts typing, we switch to a new input field, set its content, and focus it. This probably confuses the browser when it goes to assemble the components into a word, since typing began in one form input but then is migrated to a new one. With the example Revi provided, you can see the word assembly happens at the end (the last two input characters) but it doesn't take the whole string into account.

@MMiller_WMF the most obvious solution is to go back to the previous behavior, where focusing the search input on the home screen swaps to the search panel before the user begins typing. Let me know if we should do that at least as a short term fix.

I'm looking to see if this can be fixed with our existing logic – user has to start typing before we swap to the search panel – but so far am not getting anywhere.

We decided to try to find a real fix this morning, and decide during standup what to do for the 11 AM SWAT window.

MMiller_WMF renamed this task from Typing Korean is broken in Help Panel Search bar to Help panel: typing Korean is broken in Help Panel Search bar.Feb 14 2019, 6:11 PM
MMiller_WMF added subscribers: Etonkovidova, Catrope, SBisson and 5 others.

Change 490670 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Help Panel: Fix IME broken in help panel search

Change 490674 had a related patch set uploaded (by Thcipriani; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@wmf/1.33.0-wmf.17] Help Panel: Fix IME broken in help panel search

Change 490674 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.33.0-wmf.17] Help Panel: Fix IME broken in help panel search

Change 490670 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Help Panel: Fix IME broken in help panel search

Mentioned in SAL (#wikimedia-operations) [2019-02-14T19:42:20Z] <thcipriani@deploy1001> Synchronized php-1.33.0-wmf.17/extensions/GrowthExperiments/modules/help: SWAT: [[gerrit:490674|Help Panel: Fix IME broken in help panel search]] T216131 (duration: 00m 54s)

@Etonkovidova after QA, please move this back into the ready for development column so that we can implement a fix which adheres to the desired UX (focus on search input does nothing; inputting text swaps to search panel).

Checked in testwiki/kowiki - moving back to Ready for Development.

Roan's suggestion: use a single search input field, keep it on the home panel, toggle the search results (and other elements) on home panel if search is active or not.

kostajh claimed this task.Feb 15 2019, 7:52 PM

Change 490931 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Help Panel: Move search panel into home panel

A few things I've tried here:

  1. Use a single search input field and toggle hide/show of elements on the home panel (
    • This works but scroll is broken on the help links and the search results
  2. Keep two separate search inputs and panels. Listen to compositionstart and compositionend events, and switch to the search panel when compositionend is triggered.
    • Doesn't work, compositionend seems to be triggered after ㅇㅕ, which makes sense since that forms , but we want composition to continue so that eventually is formed.
    • Similarly, adding an event listener and checking event.isComposing won't work for the same reasons above

Probably the way forward here is to try to sort out the scrolling issues rather than spend more time working with/around composition events.

Change 490931 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Help Panel: Use single search input field for IME

The patch is merged and should fix this issue. However, there's a minor side effect that's a little annoying. Before this patch, the title bar of the help panel would briefly get the pending animation (cross-hatching) when you focus the search input. But with this patch, this happens on every key press. More specifically, on every key press, first the title bar will become pending, then it'll immediately stop being pending again, and only then will the search input itself become pending (and stay that way until the results arrive). Probably not a big deal but it looks a bit weird.

I traced the cause in the debugger, and it seems to come from calling .executeAction( 'search' ): any call to executeAction sets the pending state on the title bar.

This is not a blocker for pushing the change to the wikis. I filed the minor side effect here: T216787, which we can triage.

Etonkovidova closed this task as Resolved.Feb 22 2019, 8:26 PM