IOS - Contact list becomes empty after activating voice typing and deactivating it

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.75-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause - Internal Team
Component Left Hand Navigation (LHN)

Action Performed:

1. Open IOS hybrid app
2. Tap on FAB > Start chat
3. While the input field is in focus tap on voice typing
4. Tap on it again to deactivate voice typing

Expected Result:

The contact list shows recent and all contacts

Actual Result:

The contact list becomes empty

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6692356_1734017997908.ScreenRecording_12-12-2024_18-31-45_1.mov

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @joekaufmanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[truph01]

Proposal

Please re-state the problem that we are trying to solve in this issue.

• The contact list becomes empty

What is the root cause of that problem?

• The bug has been reported here.

• When we deactivate voice typing, an additional U+FFFC is added to the end of input's value. It leads to the contact list becomes empty.

What changes do you think we should make in order to solve the problem?

• We can update:

    const setValue = (newValue: string) => {
        let formattedValue = isMultiline ? newValue : newValue.replace(/\n/g, ' ');
        formattedValue = formattedValue.replace(/\uFFFC/g, '');

• It will remove the U+FFFC from the input value. We can consider only applying that removal if the platform is IOS.
  

  App/src/components/TextInput/BaseTextInput/index.native.tsx

  Lines 220 to 221 in 10bfe9a

  	const setValue = (newValue: string) => {
  	const formattedValue = isMultiline ? newValue : newValue.replace(/\n/g, ' ');

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

• We can create the util function to get the formattedValue such as:

    const getFormattedText = (newValue)=>{
        let formattedValue = isMultiline ? newValue : newValue.replace(/\n/g, ' ');
        formattedValue = formattedValue.replace(/\uFFFC/g, '');
        return formattedValue
    }

and check if the input contains \uFFFC, it should be removed from output.

What alternative solutions did you explore? (Optional)

[joekaufmanexpensify]

Ehhh, I am not convinced this is really worth doing anything about now. I can reproduce this, but if you type something in the search box, anything at all, the contacts appear again. It seems like the voice to text result is treated as a search result even when it's empty, so you just need to add something to bring about a different result.

I'm not super convinced this will really come up frequently, if at all. As it is fairly intuitive that you just type in the box to see other results.

I'm going to close this for now and we can revisit if actual customers report confusion about this. LMK if anyone disagrees with that!

[truph01]

@joekaufmanexpensify I understand the low priority for now, but this issue could impact user experience significantly. When the contact list appears empty after voice typing, it’s not intuitive for users to know they just need to type something to restore it. This could lead to confusion or frustration, especially for first-time users or those relying on voice input. Fixing it now, with minimal effort, can prevent potential complaints later and ensure a smoother experience.

[joekaufmanexpensify]

Hm, I am not sure I agree on the intuitiveness. I personally expect if someone sees empty search results, they're likely to either type something else, or navigate out and back into the page. Both of which resolve this. Further, I would be surprised if many/any customers intentionally experience this. In fact, the only real case I see for this is someone using voice to type by mistake because if there's any input there will be search results. In which case I'd expect them to type right after because they probably meant to be searching something with the keyboard.

I still think we should wait and see if this impacts any customers and then fix it then, if so.

[truph01]

Thanks for sharing your opinion @joekaufmanexpensify