Random erasing of search query on Chrome 92 Android

[nitech]

Description

When running on Android Chrome 92, I get weird behavior. When I enter a search string, everything works fine until I hit a certain letter. Then everything in the search field is removed.

It varies which letter causes the glitch. Check out the video below for an example:

https://www.youtube.com/watch?v=rYf5dsW5KKQ

I am using the following versions:

"@algolia/autocomplete-js": "^1.3.0",
"@algolia/autocomplete-plugin-algolia-insights": "^1.3.0",
"@algolia/autocomplete-plugin-query-suggestions": "^1.3.0",
"@algolia/autocomplete-plugin-recent-searches": "^1.3.0",
"@algolia/autocomplete-theme-classic": "^1.3.0",
"algoliasearch": "^4.10.5",
"algoliasearch-helper": "^3.5.5",
"htm": "^3.1.0",
"instantsearch.css": "^7.4.5",
"instantsearch.js": "^4.28.0",

Example (as shown in the video): I enter "se" in the search field. As soon as I enter "k", "se" is removed and "k" is the only thing appearing in the search field.

When I inspect the state-object with the onStateChange event of Autocomplete, I find the the prevState does contain the first letters while the current state only contains the new letter.

I am actually seeing the same behavior in this official autocomplete-js example: https://l7tzs.csb.app/ (which is linked from the "See live demo" button on the page https://www.algolia.com/doc/guides/building-search-ui/ui-and-ux-patterns/autocomplete/js/

Here is a video where I demonstrate the bug on this specific sandbox example:
https://youtu.be/rSbl26XJ828

Also asked about this on the community forum:
https://discourse.algolia.com/t/possible-bug-on-chrome-android-erases-everything-in-input/13346

Environment

• OS: Android
• Browser: Chrome 92
• Autocomplete version: 1.3.0

[nitech]

It might be a bug that only manifestes when autocomplete is used with instantsearch, because this official sandbox has the bug (and uses instantsearch.js - and autocomplete 1.3.0):

https://codesandbox.io/s/github/algolia/autocomplete/tree/next/examples/instantsearch?file=/src/app.ts

While this one does not use instantsearch.js - but uses autocomplete 1.3.0) and works fine:
https://codesandbox.io/s/github/algolia/autocomplete/tree/next/examples/query-suggestions?file=/app.tsx

[francoischalifour]

Thanks for this detailed issue @nitech.

Can you confirm that this bug only happens in detached mode?

[nitech]

I am not able to verify that until the 6th of September. iPhone family… not many androids laying around 🤪 (but I imagine you guys have a few?)

I will update you if I am able to verify this before.

Please note that you need a real device to reproduce the issue. Browserstack, for instance, won’t reproduce.

[nitech]

@francoischalifour This happens both in detached and attached mode. Please see the two links I added in my second comment.

[nitech]

@francoischalifour Any news on this?

[francoischalifour]

I am unable to reproduce the behavior, even on the Autocomplete with InstantSearch sandbox, what are the exact steps there?

Would you be able to copy the code you have in your app onto a basic sandbox?

[nitech]

Quirky issue this one. As I wrote in this comment:

It might be a bug that only manifestes when autocomplete is used with instantsearch, because this official sandbox has the bug (and uses instantsearch.js - and autocomplete 1.3.0):

https://codesandbox.io/s/github/algolia/autocomplete/tree/next/examples/instantsearch?file=/src/app.ts

While this one does not use instantsearch.js - but uses autocomplete 1.3.0) and works fine:
https://codesandbox.io/s/github/algolia/autocomplete/tree/next/examples/query-suggestions?file=/app.tsx

The bug is present on the official sandbox when it combines Autocomplete.js with Instantsearch.js. As soon as Instantsearch.js is not present, the bug is not there.

These are the reproduction steps:

1. Open https://codesandbox.io/s/github/algolia/autocomplete/tree/next/examples/instantsearch?file=/src/app.ts on a physical Samsung S10 running Android and Chrome 93 (latest).
2. Enter "se" in the search field. As soon as you enter "k", "se" is removed and "k" is the only thing appearing in the search field.

I just re-tested on the following models:

Model	Result
Samsung Galaxy S10 Chrome 93	Bug
Samsung Galaxy S20 Chrome 93	OK
Samsung Galaxy S21 Chrome ?	Bug
Samsung Galaxy S10e	Bug

[tkrugg]

Hi @nitech thanks for your patience. I was not able to get a hold of physical device. The closest I could get to was Samsung Galaxy S10 Chrome 91.0.4472.120 on Browserstack. Still I didn't manage to reproduce it.

The underline I'm seeing on your recording reminds me of the predictive features of samsung phones which in most cases depend on your device configuration and locale, as far as I know.

Can you try to disable thoses features and try again? I guess that would help us rule out this reason

[nitech]

Thanks for getting back to me @tkrugg. I have tested the device with predictive text on and off. With predictive text off, there is still a bug present, although it behaves a little different. Here is a recording:

https://youtu.be/3VRKRzTQlDI

[tkrugg]

Thank you @nitech on your video it looks like you're using chrome desktop. Is this correct? could you clarify the steps to reproduce this on a desktop env?

[nitech]

I am using a desktop env on Windows 10. I will post reproduction steps in a new post. But basically it’s just a Samsung Galaxy S10 connected to the Pc via usb and remotes via Chrome’s Remote Inspect tool.

[nitech]

Hi @tkrugg, how to reproduce:

1. Use a physical Samsung Galaxy S10 or S20 on latest Android and latest Chrome (I am using Chrome 93).
2. Go to this URL https://l7tzs.csb.app/ (or Click the See Live Demo-button on the Building a Search UI example page. It brings you to the same URL)
3. Type "ama" in the search box (a little fast - not slow) and watch how the search box sometimes equals "aa", "ama", "aama" and sometimes just "aa".

You don't need to connect the S10 to a PC. You can test this directly on the phone.
You need to use a real device. You cannot use an emulator or remotely operated unit like that on Browserstack.

[nitech]

Seems to be the same bug as #753, which was fixed in release 1.4.1. Testing now.

[nitech]

I can confirm that it was fixed in #753

[nitech]

We celebrated a little too soon. The bug is still there (not present when I closed the issue). It seems the bug comes and goes a little (although present 100% of the time now).

[nitech]

I forked the official sandbox example, upgraded all packages, and added som trace in console, but the problem is still there.

https://gi0t4.csb.app/

Please have a look. Since it's hard for you to reproduce this problem, please feel free to let one of your developers contact me directly on simon@amatec.no so we can schedule a Teams or Zoom meeting so you can see the problem in real life.

[nitech]

Updated fork to v 1.5. Still same problem. @tkrugg are you following this issue?

[francoischalifour]

@nitech Thank you again for your patience and for the detailed reports. Since we don't have access to physical Samsung Galaxy S10 or S20, this problem is hard to debug.

Here's what I suggest:

1. Since (according to your testing) the bug only shows with the InstantSearch integration, it could be that the state is concurrently updated because of time out issues. Can you try to remove all the debouncing and directly use the state update functions? (e.g., debouncedSetInstantSearchUiState → setInstantSearchUiState)
2. It may not be the answer we're hoping for, but this might be a Samsung software issue. I searched on Google for this specific problem and multiple users complain about Predictive Text problems on Samsung Galaxy S20.

If (1) doesn't solve the problem, I'm afraid we won't be able to fix this, because it's a bug coming from certain Samsung phones.

[nitech]

Hi @francoischalifour. Thanks for your reply.

1. I tested debouncedSetInstantSearchUiState, however, it did no difference
2. I also tested actually excluding instantsearch.js from the build, but the bug was still there - so my assumption that "the bug only shows with the InstantSearch integration" was wrong. There must be something else that differs between the two sandboxes that makes the bug present in this sandbox while this sandbox doesn't have the bug (I just re-tested and can verify that these two sandboxes still behave as written)

[FabienMotte]

Hello there! 👋

After some investigations, we found out that the issue is related to the fact that we internally update the enterKeyHint property on the input element. Basically, we set it to "go" when there is an active item and it has a getItemUrl function defined, and we set it to "search" when it doesn't. In many cases, this doesn't show up but a typical trigger scenario is when you no longer have results: there is no active item anymore, so we switch back to "search" while we were previously set on "go".

We observed this behavior only on Chrome Android. On Safari iOS, Chrome iOS and Firefox Android, things work fine.
But Chrome Android seems to fully reset the input value when we change enterKeyHint.

We reproduced the issue without Autocomplete on this minimal CodeSandbox: https://codesandbox.io/s/boring-shockley-pjnzj7?file=/src/index.js

We tried deferring the DOM update using promises and requestAnimationFrame but no luck with vanilla JavaScript so far, we only made it work in a React app (maybe due to how React handles and schedules DOM updates?).

We're actively investigating and working with our Android specialist coworkers. We know this is frustrating so thank you for bearing with us, we'll let you know on this ticket whenever we make progress.

[sarahdayan]

So, it looks like an issue caused by Predictive Text but only on Android Chrome. @FabienMotte deactivated it and it works fine without. Oddly, Android Firefox works fine with and without Predictive Text.

After a quick research, it looks like Samsung doesn't honor the spellcheck attribute so we unfortunately can't deactivate the feature in Autocomplete. I have no idea if they're ever gonna do it, but I don't expect it anytime soon.

My suggestion is to detect Samsung mobile platforms (via user agents) and use a fixed "enter" value for enterKeyHint on these devices.

[nitech]

I thought the world of quirk was gone with IE11, but it seems the spirit lives on, just manifesting in new ways. Perhaps the rendering engine of Android Chrome is in fact IE11?

Anyway. Looking forward to testing this out. It has been a quirky thing to figure out, and I admire the work that must have been put into locating and fixing the bug.

[FabienMotte]

Hi @nitech and sorry for the wait
This issue should be fixed in the latest release v1.5.5
Thanks for raising this issue and your investigations!

[nitech]

Great @FabienMotte, I've been following the work closely ;-) Looking forward to trying it out on our site.

[nitech]

I tested on Chrome. The bug was gone. However, it is not gone on "Samsung Internet" (bundled chromium?) with the following user agent string:

Mozilla/5.0 (Linux; Android 8.0.0; SAMSUNG SM-G930F) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/16.2 Chrome/92.0.4515.166 Mobile Safari/537.36

[FabienMotte]

Hello @nitech!

Thanks for catching this, Samsung Browser is excluded from the isChrome util: https://github.com/algolia/autocomplete/blob/next/packages/autocomplete-core/src/utils/isChrome.ts#L3

I'll open a PR to remove the check on Chrome browser and only keep the one on Samsung devices.

[FabienMotte]

Hi @nitech!

The issue concerning Samsung Browser should be fixed in the latest release v1.5.7
Feel free to reopen if that's not the case

Thank you!

[nitech]

Thanks. It works.

[cristianbarb]

Hi!

We implemented autocomplete with instantsearch, and the issue is still reproducible on the following Samsung devices:

1. Samsung Galaxy S21 Phone using Chrome (works using Edge)
2. Samsung Galaxy S22 Ultra on Chrome
3. Samsung Galaxy S20 FE on Chrome
4. Samsung Galaxy S23 Ultra on Chrome

We are using the following versions:

 "@algolia/autocomplete-js": "^1.8.3",
 "@algolia/autocomplete-plugin-query-suggestions": "^1.8.3",
 "@algolia/autocomplete-plugin-recent-searches": "^1.8.3",
 "@algolia/autocomplete-theme-classic": "^1.8.3",
 "instantsearch.js": "^4.37.3"
 "vue-instantsearch": "^3.8.1",
 "algoliasearch": "^4.16.0",

I expected the issue to be fixed if the "autocomplete-js" version is greater than 1.5.7.

Any help or direction is greatly appreciated.

Thank you!

[dhayab]

Hi @cristianbarb, recent updates in Chrome limit the ability for us to reliably detect Samsung devices, which render some of our measures ineffective.

Starting from autocomplete@1.10.0, you now have the ability to manually set a static value for the enterKeyHint property on autocomplete(), which should fix this issue.

For usage, you can check the API reference, and this resource will help you determine which value to use according to your needs.

[cristianbarb]

Hi @dhayab , thank you for your help. Unfortunately, it does not seem to work. The issue is still reproducible on the mentioned Samsung devices even after setting a value for the enterKeyHint (tried 'search' and 'enter', and neither worked).

The code that initializes autocomplete is below:

autocomplete({ container: '#autocomplete', placeholder: 'Search for a brand, product, sku,...', enterKeyHint: 'enter', openOnFocus: true, initialState: { query: new URL(window.location).searchParams.get('query') ? decodeURIComponent(new URL(window.location).searchParams.get('query')) : "", }, onSubmit({ state }) { self.searchTypedTerm(state.query); }, plugins: [recentSearchesPlugin, querySuggestionsPlugin], });

Any other thoughts? Thank you!

[dhayab]

We might need more info to determine why this is not working for your case. Could you:

• go to https://dr292d.csb.app/ with your device
• tap on the Autocomplete input to open the detached panel and the virtual keyboard
• close the detached panel
• take a screenshot and attach it to a reply here

It should look like this:

Here is the source of this sandbox, for more details: https://codesandbox.io/s/dr292d?file=/app.tsx.

[cristianbarb]

@dhayab , below is the screenshot:

And a video how the issue is reproducible:

2023-07-14_14h09_58.mp4

[Haroenv]

Hey @cristianbarb sorry for the delay here, but is that screen recording from the codesandbox with a static enterKeyHint value? It seems different.

Have you tried setting enterKeyHint to '' as well as

let aaInput = undefined;
// ... 
  onStateChange() {
    if (!aaInput && document.querySelector(".aa-Input")) {
      aaInput = document.querySelector(".aa-Input").outerHTML;
      aaInput.enterKeyHint = '';
    }
  },

to force it to be unset?

We've tried reproducing this with real Samsung devices and with the fix in the sandbox could no longer reproduce it.

[cristianbarb]

Hi @Haroenv and @dhayab , sorry for the delay; we resolved the issue by upgrading to autocomplete@1.11.0 and setting the enterKeyHint to 'search'. Setting the enterKeyHint to ' ' and forcing it to be unset did not work for us.

Thank you for your help.

[harithaj-github]

Hi Team , we are using @algolia/autocomplete-js 1.15.0 facing same issue in Samsung chrome browser.
we have added setting enterKeyHint to 'search' dint work for us.

Can you please help us in fixing this.

Thank You in Advance!