[$500] [MacOS Chrome / iOS Chrome] Chrome Browser Has Mistaken Form Fields For Inputs in Expensify Chat

[yuwenmemon]

Version Number: 9.0.23-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: Caught during CVP Testing
Email or phone of affected tester (no customers): [email protected]
Logs: N/A
Expensify/Expensify Issue URL: N/A
Issue reported by: @yuwenmemon
Slack conversation: https://expensify.slack.com/archives/C036QM0SLJK/p1724431920271019

Issue

1. On the same account, go to the chat with Concierge on mobile web
2. Click on the text input, your phone keyboard should pop up

Expected Result:

• The keyboard should show on mobile chrome without any form input helpers (i.e. the key, creditcard, and location options above the keyboard)

Actual Result:

• Chrome thinks the input is a form field and thus presents some form field shortcuts above the keyboard:

Workaround:

N/A

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021846212488219658542
• Upwork Job ID: 1846212488219658542
• Last Price Increase: 2024-11-19
• Automatic offers:
• allgandalf | Reviewer | 104995463

Issue Owner

Current Issue Owner: @yuwenmemon

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @allgandalf (External)

[melvin-bot]

Triggered auto assignment to @anmurali (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.

[Nodebrute]

Proposal

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

Chrome Browser Has Mistaken Form Fields For Inputs in Expensify Chat

What is the root cause of that problem?

This issue is not confined to the Onboarding form fields; it also affects other fields, such as the name field in the profile. We should not rely solely on labels for Google to accurately predict the purpose of each field.

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

We have an autocomplete attribute that we should use for all TextInput components where we are encountering this problem. We can also set autocomplete to off in the fields where we don't want google to autocomplete.

More Info here.

What alternative solutions did you explore? (Optional)

[klajdipaja]

Proposal

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

Chrome browser on mobile tries to autocomplete some input fields like the name in the signup process or in the profile, the merchant when adding expenses etc and in doing so it shows options like Credit Card autofill.
NOTE. I was unable to reproduce this in the Chat with concierge.

What is the root cause of that problem?

Autocomplete is not disabled in components/TextInput even though we are treating it as disabled by not propagating the property in the components/Form/InputWrapper component. Since it's not disabled Chrome uses the label to try and understand how to do that autofill.

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

Before passing the props by the wrapper component in:

App/src/components/TextInput/index.tsx

Lines 58 to 59 in 0c84552

	// eslint-disable-next-line react/jsx-props-no-spreading
	{...props}

We should disable it explicitly by adding:

            autoComplete="off"
            // eslint-disable-next-line react/jsx-props-no-spreading 
            {...props}

That would still allow for the props to add an autocomplete option in the wrapper component for special use-cases of the input field.

What alternative solutions did you explore? (Optional)

[melvin-bot]

@yuwenmemon, @anmurali, @allgandalf Whoops! This issue is 2 days overdue. Let's get this updated quick!

[anmurali]

Cannot reproduce the first issue

I can reproduce the second

[trjExpensify]

@allgandalf what do you think of the proposals?

[allgandalf]

There is something wrong with my k2, not able to see recent issues, (Maybe the token has expires 💢 , I will review the Proposals after this deploy blocker today @trjExpensify

[trjExpensify]

Thanks!

[allgandalf]

Reviewing Proposals now ♻️

[allgandalf]

@Nodebrute @klajdipaja are you able to reproduce the 1st issue? can you share a recording of it?

For the second issue:

I am able to reproduce the second issue, but none of the proposals above have the RCA or the solution for the issue, so i suggest both to please update your proposals, this issue is also open for proposals from other contributors 🙏

[allgandalf]

@Nodebrute @klajdipaja will you guys be able to update your proposals ?

[klajdipaja]

@allgandalf I was unable to reproduce the first issue, only the second one.
As for my proposal you are right I tried again and it did not provide the expected fix and with all my research all I could find is that this is a default behavior of Chromium browsers.
The root cause to me seems to be a "bug" or maybe default behavior in Chrome that for every input no matter if you have requested autocompletion or not, the autocompletion bar with the three icons show up. When autocomplete is specified to some type than in addition to these three default icons you could also see a list of suggestions.

There's a long list of hacks on this gist https://gist.github.com/niksumeiko/360164708c3b326bd1c8 that some of the users report as useful but non actually work to remove the whole autofill bar and to be honest I don't think we should aim to go in that direction.
I see three options here:

1. Set autocomplete values appropriately when possible so that the autofill bar becomes meaningful for most inputs. At the moment we are not doing this for 90% of inputs, even email fields do not have the autocomplete set to email which would help users fill the data.
2. Ignore this issue as a chrome behaviour and avoid building workarounds that might become unnecessary in a feature chrome update.
3. Workaround 1. Use RNMarkdownTextInput instead of RNTextInput. You can test it by replacing setting isMarkdownEnabled = true
4. Workaround 2 . Make the input a text-area which is why in some fields like the chat we do not get the autofill bar. That could be done by adding

    maxLength={25}
    multiline={true}
    numberOfLines={1}
```.
I can prepare a proposal for this if you think that would be the direction you want to go. 

[melvin-bot]

@yuwenmemon @anmurali @allgandalf this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[yuwenmemon]

It seems like we're not able to reproduce the first issue across the board, so I'm fine with us tackling just the second issue in proposals.

[allgandalf]

Waiting for proposals, @yuwenmemon @RachCHopkins can you ask CS or SWM to take a look here?

[allgandalf]

bump @yuwenmemon on the ^

[yuwenmemon]

Asking in Slack: https://expensify.slack.com/archives/C04878MDF34/p1731966318908489

To reduce confusion I'm removing the first issue from the OP since no one is able to reproduce anymore. But for posterity it was the following:

There are two issues that are similar.

First Issue

Action Performed:

1. Create an account on NewDot
2. Choose Get paid back from my employer from the intent selector
3. On the form to enter one's first and last name, focus the first input

Expected Result:

• Chrome autofill should suggest your name, without implying that it's a credit card form

Actual Result:

• Chrome autofill shows your name in the context of a Credit Card input form.
  

[RachCHopkins]

Thanks for that @yuwenmemon, I just spent far too long trying to work out what issue 2 was when I could only see 1!

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[yuwenmemon]

@SzymczakJ Expressed interest in picking this one up!

[allgandalf]

lesss go 💪 , @SzymczakJ let me know if i can be of any help here initially

[SzymczakJ]

Hey! I’m Jakub Szymczak from Software Mansion, an expert agency, and I’d like to work on this issue!

[SzymczakJ]

When I tested this issue on a real device(as I thought it would give me more insight) I noticed it's not reproducible on the real device.
So here comes my question: should we be fixing a bug that only occurs on mWeb iOS simulator? This might be even caused by some solely simulator internals bug. WDYT @yuwenmemon @allgandalf?

[yuwenmemon]

Interesting. I first saw the issue on a real iOS device.

I'm unsure the environment where others were able to reproduce but looking at the screenshots it's both on Safari and Chrome?

should we be fixing a bug that only occurs on mWeb iOS simulator?

I would say it depends on what we need to do to fix it. I always thought it was some weird component/html thing getting misinterpreted by the browser.

[melvin-bot]

📣 @allgandalf 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[allgandalf]

I'm unsure the environment where others were able to reproduce but looking at the screenshots it's both on Safari and Chrome?

I was able to reproduce on real device on Safari

[SzymczakJ]

I can only reproduce it on simulator, but I'm going to use this to investigate.

[SzymczakJ]

For investigation purposes: What's the iOS version and Safari version on which you managed to reproduce it? I was trying to reproduce on like 5 different iPhones and didn't manage to do it.
Also do you have some specifc setup, like username saved in apple keychain, or some other iPhone/account config?

[SzymczakJ]

Here's the investigation outcome:
tl:dr This is a Safari bug, which I managed to reproduce only on simulator. I've filed in a bug report to Safari and because it is internal safari problem, which we cannot really fix, then we should put it on hold and wait for Safari's response.

To make things clear here's the bug that I'm talking about(after writing to 'login username text input' the password autofill suggestion is also appearing in all other text inputs):

bug.repro.Expensify.mov

I'm 95% sure this is a Safari/simulator bug, because of the following reasons:

1. I created minimal reproduction app(https://github.com/SzymczakJ/text-input-type-repro) in which I can reproduce the bug behaviour. So this bug is not connected to Expensify directly and is not caused by some internal Expensify config.
2. It's not a bug that can be solved by setting proper props to TextInput, I've tried setting/resseting all of them.
3. I managed to reproduce the same behaviour on Apple website 😃, so I guess this is just how safari works, with mobile keyboards:

apple-reproduction.mov

I've reported a bug on Safari bug report Website, let's see if they respond. If you want me to investigate further, then please provide me more information about the iOS and Safari versions on which this bug is repoducible on real devices, because I'm running out of ideas and for me this bug only happens for simulators(I've tested 5 different iPhones).
This bug will only happen in case when user logs into app and then uses the app right away. Cases like going back to app, when already logged in, or resetting the safari fix the bug, so the buggy behaviour will happen in minority of cases. Because of that I'm in favour of putting this on hold and wait for Safari response to the problem as we don't have any way of changing Safari internal behaviour. WDYT @allgandalf @yuwenmemon

[melvin-bot]

@yuwenmemon, @RachCHopkins, @SzymczakJ, @allgandalf Eep! 4 days overdue now. Issues have feelings too...

[RachCHopkins]

@allgandalf @yuwenmemon, what do you think of that plan? Makes sense to me.

[allgandalf]

Agree, lets put this to monthly though, @yuwenmemon what do you think ?

[yuwenmemon]

I was able to reproduce on real device on Safari

@allgandalfare you able to share the device details you were able to reproduce this on?

In any case, if this seems like a simulator issue only and we've had trouble reproducing then maybe we can just close this out TBH.

[allgandalf]

In any case, if this seems like a simulator issue only and we've had trouble reproducing then maybe we can just close this out TBH.

Works for me!, we can always get back to this if this affects wider audience

[allgandalf]

@RachCHopkins lets close this

[allgandalf]

Let's close this @RachCHopkins