[$250] BNP-On entering number&decimal point, first digit moves inwards slightly

[IuliiaHerets]

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: V9.0.68-0 Reproducible in staging?: Y Reproducible in production?: Y Issue reported by: Applause Internal Team

Action Performed:

1. Launch app
2. Tap fab -- create expense
3. Enter 3. In keypad

Expected Result:

On entering 3 and decimal point, the digit 3 must not move.

Actual Result:

On entering 3 and decimal point, the digit 3 moves inwards slightly in android but not in mweb.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

https://github.com/user-attachments/assets/3d889baf-8828-480a-a266-8ccde1076f6c

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021863570868574579192
• Upwork Job ID: 1863570868574579192
• Last Price Increase: 2024-12-02
• Automatic offers:
• brunovjk | Reviewer | 105212229
• QichenZhu | Contributor | 105212231

Issue Owner

Current Issue Owner: @brunovjk

[melvin-bot[bot]]

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

[melvin-bot[bot]]

@isabelastisser Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~021863570868574579192

[melvin-bot[bot]]

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

[QichenZhu]

Proposal

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

The first digit briefly flickers when entering a money request amount.

What is the root cause of that problem?

The width of the amount input is designed to autogrow. Since React Native text input lacks the autogrow feature, we implement it using an underlying text view and synchronize the width of the input container and the underlying text.

https://github.com/Expensify/App/blob/5bb0e9ba3fb33a0ff0912b505740ca3cf4e384a6/src/components/TextInput/BaseTextInput/index.native.tsx#L261

https://github.com/Expensify/App/blob/5bb0e9ba3fb33a0ff0912b505740ca3cf4e384a6/src/components/TextInput/BaseTextInput/index.native.tsx#L450-L456

The width of the text input is set to fit its container.

https://github.com/Expensify/App/blob/5bb0e9ba3fb33a0ff0912b505740ca3cf4e384a6/src/components/TextInput/BaseTextInput/index.native.tsx#L352-L353

When typing in the input, the content updates immediately, but the width takes time to grow because the process is asynchronous and requires communication between JS and native sides.

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

Now that we've limited the container width, there's no need to strictly limit the width of the text input itself.

Inspired by the approach on web platforms below, we could also add extra width on native platforms.

https://github.com/Expensify/App/blob/5bb0e9ba3fb33a0ff0912b505740ca3cf4e384a6/src/components/TextInput/BaseTextInput/index.tsx#L517-L519

1. Replace the two lines with the next line.

https://github.com/Expensify/App/blob/5bb0e9ba3fb33a0ff0912b505740ca3cf4e384a6/src/components/TextInput/BaseTextInput/index.native.tsx#L352-L353

autoGrow ? {width: textInputWidth + 100} : [styles.flex1, style.w100],

2. Insert a line under the code below. https://github.com/Expensify/App/blob/5bb0e9ba3fb33a0ff0912b505740ca3cf4e384a6/src/components/TextInput/BaseTextInput/index.native.tsx#L258-L259

autoGrow ? styles.overflowVisible : styles.overflowHidden,

Before	After

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

This only involves stylesheet changes, so tests aren't necessary.

What alternative solutions did you explore? (Optional)

[brunovjk]

I think the RCA correctly identifies that the asynchronous width adjustment and lack of proper overflow control are the main causes of the flickering issue. I tested the proposal, and it works as expected, fixing the issue. @neil-marcellini what do you think about their solution? While we may need to confirm some details, the general idea seems sound. With that, I think we can go with @QichenZhu's proposal. I'll test further in the PR to avoid regressions.

🎀👀🎀 C+ reviewed

[melvin-bot[bot]]

Triggered auto assignment to @neil-marcellini, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[neil-marcellini]

I think the RCA correctly identifies that the asynchronous width adjustment and lack of proper overflow control are the main causes of the flickering issue. I tested the proposal, and it works as expected, fixing the issue. @neil-marcellini what do you think about their solution? While we may need to confirm some details, the general idea seems sound. With that, I think we can go with @QichenZhu's proposal. I'll test further in the PR to avoid regressions.

🎀👀🎀 C+ reviewed

I agree, it looks like a good solution.

[melvin-bot[bot]]

📣 @brunovjk 🎉 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

[melvin-bot[bot]]

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

Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻 Keep in mind: Code of Conduct | Contributing 📖

[QichenZhu]

Thanks for the offer. I'll open a PR on Monday.

[muttmuure]

Not a quality bug

[melvin-bot[bot]]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[luacmartins]

FYI I reverted the PR associated with this issue because it caused this blocker https://github.com/Expensify/App/issues/53992. Please work on a new solution taking that into account.

[brunovjk]

@QichenZhu Any idea what might have caused the issue? Thanks

[luacmartins]

I think the input was just growing to fill up space and pushing the whole component over

[QichenZhu]

I think the input was just growing to fill up space and pushing the whole component over

Yeah, my PR aimed to increase the input width without affecting the layout, but it fails in Chrome.

Any idea what might have caused the issue? Thanks

When focusing the input, Chrome scrolls its container horizontally. This doesn’t seem to happen in Safari or native apps. I’ve tested some possible solutions:

1. Setting the container overflow-x: clip doesn’t work.
2. Setting the input position: absolute doesn’t work.
3. Adding {preventScroll: true} when calling focus() works partially. But it doesn’t prevent scrolling on keyboard focus.

https://github.com/Expensify/App/blob/0a2ef8edc2d3244af2767518542286f3b6bd8637/src/pages/iou/request/step/IOURequestStepAmount.tsx#L88

focusTimeoutRef.current = setTimeout(() => textInput.current?.focus({preventScroll: true}), CONST.ANIMATED_TRANSITION);

https://github.com/Expensify/App/blob/0958370c7b7fb56809b30757055442d05944632c/src/pages/iou/MoneyRequestAmountForm.tsx#L136

textInput.current.focus({preventScroll: true});

I'm still looking for a better solution, ideally fixing it inside the input component without changing its usage.

@brunovjk cc: @luacmartins

[brunovjk]

Thank you for the investigation @QichenZhu. I will also test this approach on my end. It will require even more careful testing this time, so I don’t think I’ll finish today, but I’ll let you know if I find anything. Please feel free to reach out if you need any assistance. Thanks!

[QichenZhu]

@brunovjk Thanks for your time. The approach mentioned earlier has the drawback that it cannot prevent scrolling on keyboard focus. Here are another two possible solutions:

1. Add {overflowX: 'clip', overflowY: 'visible'} styles to the parent view of MoneyRequestAmountInput. This isn’t ideal since the regression comes from BaseTextInput but is fixed outside of it.

https://github.com/Expensify/App/blob/0958370c7b7fb56809b30757055442d05944632c/src/pages/iou/MoneyRequestAmountForm.tsx#L259

2. Skip fixing the original issue on web. The QA team mentioned it doesn’t happen on web. In my testing, it does happen on a slow simulator, but it's almost negligible on my physical devices.

I’m open to any suggestions. Thanks for your help!

[melvin-bot[bot]]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot[bot]]

The solution for this issue has been :rocket: deployed to production :rocket: in version 9.0.75-6 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

• https://github.com/Expensify/App/pull/53740

If no regressions arise, payment will be issued on 2024-12-20. :confetti_ball:

For reference, here are some details about the assignees on this issue:

• @QichenZhu requires payment automatic offer (Contributor)
• @brunovjk requires payment automatic offer (Reviewer)

[melvin-bot[bot]]

@brunovjk @isabelastisser @brunovjk The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[brunovjk]

Thanks for the effort @QichenZhu, I'll do some tests today and get back to you ASAP.

[brunovjk]

After testing, skipping the fix for web and applying it only on native platforms resolves the issue effectively. So far, everything works as expected in my tests. Thanks again for the great work @QichenZhu! How have your tests been going? Let's test this very carefully before calling in the interns.

[QichenZhu]

Thank you so much @brunovjk! I tested the steps in this issue, https://github.com/Expensify/App/issues/53992, and this comment. Looks good so far.

[brunovjk]

Great @QichenZhu! Could you update the Test Steps in your draft PR to include these cases? Can you think of any other cases where our changes might have affected? After that, I think we can release the PR to the design team for review. What do you think? Thanks.

[brunovjk]

Update: Please ignore the payment warnings. The PR has been reverted and we are already working on the solution here.

[isabelastisser]

Thanks for the heads up, @brunovjk!

[isabelastisser]

FYI, I will be OOO from Dec 23 to Jan 6, so please reassign the issue to another team member for urgency, IF needed.

[brunovjk]

Update: PR still under review.