Likely related to https://phabricator.wikimedia.org/T295166 as predictive text in the Samsung Keyboard is based on composition events.

im not able to reproduce this right now? was this issue fixed?

What virtual keyboard are you trying? Samsung's default one ("Samsung Keyboard") reproduces this issue reliably if predictive text is enabled in settings (default).

I see this in Firefox Nightly for Android (SwiftKey keyboard, if it matters), but not in Chrome.

Google Pixel 7

@bwang I can replicate this still.
T381289: Selecting search results on mobile website in Firefox does not work is how we fixed it with the old one. The issue related to unexpected input events being fired.

On my Pixel 8a running Android 16, using Firefox Focus, I do see updated results for every new character added; however, the results list covers up the search bar and I can't see what I've already typed / where the cursor is.

@HFan-WMF I believe this only happens on Samsung phones with predictive text turned on.

Another complaint at enwiki: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#c-Aloysius_Jr-20250901113700-Search_function_malfunction_on_mobile

Unsure how helpful this is for diagnosing, but at my workplace we're running a modified version of the TextInput component to work around Vue's composition handling (which is something close to firing key/input events only when composition is finalised).

// at the start of onKeydown and onInput handlers:
if ( event.target.composing ) {
  event.target.composing = false;
  wrappedModel.value = event.data;
}

Explicitly, the work of this ticket is to assume the same approach or class of approach that fixed T381289 will fix this - please try to apply said fix, and if it doesn't work, let the team know and we'll regroup ☺️

I did more research on this, and it's not the same approach as in T381289, this is due to how samsung keyboards on older Android devices fire input events differently, related to @Alex44019 's comment on composition. I believe the solution here should be to use compositionupdate in addition to input events in the TAHS component, this would require changes to Codex

Change #1217251 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[design/codex@main] TAHS: add composition events to SearchInput and TextInput

https://gerrit.wikimedia.org/r/1217251

@bwang Looking at your Codex patch, that's a precondition for something else to come downstream in Vector or what's the path you have in mind?

Change #1217251 merged by jenkins-bot:

[design/codex@main] TAHS: add composition events to SearchInput and TextInput

https://gerrit.wikimedia.org/r/1217251

In T393819#11465481, @Volker_E wrote:

@bwang Looking at your Codex patch, that's a precondition for something else to come downstream in Vector or what's the path you have in mind?

what do it mean something come downstream?

In T393819#11469713, @bwang wrote:

In T393819#11465481, @Volker_E wrote:

@bwang Looking at your Codex patch, that's a precondition for something else to come downstream in Vector or what's the path you have in mind?

what do it mean something come downstream?

I think the question is whether a Vector/Minerva/core patch is required to address the issue? FWIW I'm still seeing the issue on my phone and beta cluster. Is there somewhere I can test the fix on?

In T393819#11505363, @Jdlrobson-WMF wrote:

In T393819#11469713, @bwang wrote:

In T393819#11465481, @Volker_E wrote:

@bwang Looking at your Codex patch, that's a precondition for something else to come downstream in Vector or what's the path you have in mind?

what do it mean something come downstream?

I think the question is whether a Vector/Minerva/core patch is required to address the issue? FWIW I'm still seeing the issue on my phone and beta cluster. Is there somewhere I can test the fix on?

Confirmed. The issue is still present (Samsung Galaxy 8, Chrome and Firefox); iPhone doesn't display the issue.

meeting notes: waiting on a Codex release for a fix.

Change #1235058 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] Update Codex from v2.3.3 to v2.3.4

https://gerrit.wikimedia.org/r/1235058

Change #1235058 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v2.3.3 to v2.3.4

https://gerrit.wikimedia.org/r/1235058

Yay! I am seeing what looks like a fix on beta wmcloud. @Etonkovidova you should be able to test this there now!

There is a report on zhwiki (link) that the search suggestion feature is broken recently. I suspect gerrit #1217251 causes this regression.

I am able to reproduce that issue with Vector 2022 and Minerva on desktop Windows 10. It happens when typing a few alphabets into the search box first, then switch to an IME to input Chinese characters. Those /w/rest.php/v1/search/title?q=%s requests only contain the candidate Chinese characters when the IME is active (the alphabets before are not included). The full input box content is sent only after pressing backspace.

In T393819#11611413, @Bewfip wrote:

There is a report on zhwiki (link) that the search suggestion feature is broken recently. I suspect gerrit #1217251 causes this regression.

I am able to reproduce that issue with Vector 2022 and Minerva on desktop Windows 10. It happens when typing a few alphabets into the search box first, then switch to an IME to input Chinese characters. Those /w/rest.php/v1/search/title?q=%s requests only contain the candidate Chinese characters when the IME is active (the alphabets before are not included). The full input box content is sent only after pressing backspace.

Thanks for raising. Tracking this here > T417294: TypeaheadSearch search suggestion queries only include most recent IME input on desktop.

In T393819#11576301, @Jdlrobson-WMF wrote:

Yay! I am seeing what looks like a fix on beta wmcloud. @Etonkovidova you should be able to test this there now!

@Jdlrobson-WMF - the search field on any wiki (including beta wmcloud, mobile/desktop, Android/iPhone) will show search suggestions when only one search item is entered.

I re-checked the steps from the description, i.e. on iPhone Chrome and Samsung Chrome

• Visit https://doc.wikimedia.org/codex/latest/components/demos/typeahead-search.html on a Samsung mobile device, f.e. Samsung Galaxy A16 5G Chrome
• Type "Sa"
• Wait 10s
• Add a space e.g. "Sa "

To summarize:

• The issue is still present on Samsung Galaxy Chrome

• The issue is not present on iPhone 14 (Safari/Chrome)

• The issue is not present on Desktop for https://doc.wikimedia.org/codex/latest/components/demos/typeahead-search.html
• the search field on beta cluster or production doesn't display the issue.