[HOLD for payment 2025-01-07] [HOLD for payment 2024-12-20] [$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 contributors@expensify.com 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:

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

Screenshots/Videos

Bug6679447_1732823534311.az_recorder_20241129_011626.mp4

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: @isabelastisser

[melvin-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]

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

[melvin-bot]

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

[melvin-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.

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

Line 261 in 5bb0e9b

(autoGrow || !!contentWidth) && StyleUtils.getWidthStyle(textInputWidth),

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

Lines 450 to 456 in 5bb0e9b

	{/*
	Text input component doesn't support auto grow by default.
	We're using a hidden text input to achieve that.
	This text view is used to calculate width or height of the input value given textStyle in this component.
	This Text component is intentionally positioned out of the screen.
	*/}
	{(!!autoGrow || autoGrowHeight) && !isAutoGrowHeightMarkdown && (

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

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

Lines 352 to 353 in 5bb0e9b

	styles.flex1,
	styles.w100,

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.

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

Lines 517 to 519 in 5bb0e9b

	if (Browser.isMobileSafari() || Browser.isSafari() || Browser.isMobileChrome()) {
	additionalWidth = 2;
	}

1. Replace the two lines with the next line.

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

Lines 352 to 353 in 5bb0e9b

	styles.flex1,
	styles.w100,

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

2. Insert a line under the code below.
   

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

   Lines 258 to 259 in 5bb0e9b

   	const newTextInputContainerStyles: StyleProp<ViewStyle> = StyleSheet.flatten([
   	styles.textInputContainer,

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]

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]

📣 @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]

📣 @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.

[melvin-bot]

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

• Fix IOU amount input flicking #53740

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

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]

@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, #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.

[melvin-bot]

@neil-marcellini, @isabelastisser, @QichenZhu, @brunovjk Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

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

[melvin-bot]

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

• Fix IOU amount input flicking on native platforms #54189

If no regressions arise, payment will be issued on 2025-01-07. 🎊

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]

@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]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment: N/A (No specific offending PR identified.

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion:

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Regression Test Proposal

Test:

1. Launch the app.
2. Tap the floating action button (FAB) to create a new expense.
3. Enter the number '3' in the amount field.
4. Enter a decimal point; verify that the digit '3' remains fully visible during the process.
5. Delete the number and input a large number (at least 8 digits).
6. Tap 'Next' and select a recipient.
7. On the confirmation page, verify that the amount is displayed correctly without any flickering or misalignment.

Do we agree 👍 or 👎

[brunovjk]

Summary: We reverted the initial PR for this issue because it caused a regression/blocker. Subsequently, we raised a new PR, which I did not find to cause any regressions.

[isabelastisser]

The payments are processed in Upwork. All set!