[HOLD for payment 2025-01-07] [$250] Android - Expense - Submit button jumps when proceeding to confirmation page

[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: 9.0.67-1
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team

Action Performed:

1. Launch the app.
2. Go to FAB > Create expense > Manual.
3. Enter amount > Next.
4. With the keyboard up, select any user at the top.

Expected Result:

Submit button will not jump when proceeding to confirmation page.

Actual Result:

Submit button jumps when proceeding to confirmation page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6677445_1732656649279.Screen_Recording_20241127_052722.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021861729998144839111
• Upwork Job ID: 1861729998144839111
• Last Price Increase: 2024-11-27
• Automatic offers:
• suneox | Reviewer | 105169308
• huult | Contributor | 105169309

Issue Owner

Current Issue Owner: @sonialiap / @MitchExpensify

[melvin-bot]

Triggered auto assignment to @techievivek (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

Triggered auto assignment to @sonialiap (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]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[techievivek]

Not a blocker, demoting it and sending to to external

[melvin-bot]

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

[melvin-bot]

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

[mountiny]

cc @kirillzyusko @c3024 This is something to look into/ follow up on later

[huult]

Edited by proposal-police: This proposal was edited at 2024-11-27 15:03:55 UTC.

Proposal

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

Submit button jumps when proceeding to confirmation page

What is the root cause of that problem?

We use KeyboardAvoidingView in the ScreenWrapper to adjust its height, position, or bottom padding based on the keyboard height, ensuring it remains visible while the virtual keyboard is displayed.

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Line 604 in e44e493

<ScreenWrapper

App/src/components/ScreenWrapper.tsx

Line 278 in aa31378

<KeyboardAvoidingView

When we navigate to IOURequestStepConfirmation, KeyboardAvoidingView still detects the keyboard as open and adjusts the bottom padding, causing the submit button to jump up when the keyboard is visible and then jump down after it hides

That's why we don't encounter this issue when the keyboard is not open.

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

To resolve this issue, dismissing the keyboard before navigation ensures that KeyboardAvoidingView works correctly

// src/pages/iou/request/step/IOURequestStepParticipants.tsx#L110
    const goToNextStep = useCallback(() => {
+        Keyboard.dismiss();
        ...
    }

Or

// src/pages/iou/request/step/IOURequestStepParticipants.tsx#L110
    const goToNextStep = useCallback(() => {
        ...
        if (isCategorizing) {
            Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_CATEGORY.getRoute(action, iouType, transactionID, selectedReportID.current || reportID, iouConfirmationPageRoute));
        } else {
+            KeyboardUtils.dismiss().then(() => {
                Navigation.navigate(iouConfirmationPageRoute);
+            });
    }

Or

        if (isCategorizing) {
+            KeyboardUtils.dismiss().then(() => {
                Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_CATEGORY.getRoute(action, iouType, transactionID, selectedReportID.current || reportID, iouConfirmationPageRoute));
+            });
        } else {
+            KeyboardUtils.dismiss().then(() => {
                Navigation.navigate(iouConfirmationPageRoute);
+            });
        }

POC

Screen.Recording.2024-11-27.at.21.51.38.mov

What alternative solutions did you explore? (Optional)

We use shouldEnableKeyboardAvoidingView props of ScreenWrapper to disable KeyboardAvoidingView

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Line 604 in e44e493

<ScreenWrapper

//src/pages/iou/request/step/IOURequestStepConfirmation.tsx#L604
        <ScreenWrapper
            includeSafeAreaPaddingBottom={false}
            shouldEnableMaxHeight={DeviceCapabilities.canUseTouchScreen()}
            testID={IOURequestStepConfirmation.displayName}
+            shouldEnableKeyboardAvoidingView={false}
        >

[huult]

Proposal updated

• Updated new RCA
• Add alternative solutions

[suneox]

Proposal updated

• Updated new RCA
• Add alternative solutions

@huult Your main solution doesn’t seem to work consistently

Screen.Recording.2024-12-01.at.00.16.47.mp4

Could you please provide more details about the RCA for your alternative solution?

[ikevin127]

Edited by proposal-police: This proposal was edited at 2024-12-02 13:19:46 UTC.

Proposal

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

Submit button jumps when proceeding to confirmation page.

What is the root cause of that problem?

The issue seems to be caused by the recent implementation of android specific KeyboardAvoidingView component:

App/src/components/KeyboardAvoidingView/index.android.tsx

Line 61 in 3cc88f5

const KeyboardAvoidingView = forwardRef<View, React.PropsWithChildren<KeyboardAvoidingViewProps>>(

from this PR:

• feat: edge-to-edge mode on Android #52392

which make it such that ScreenWrapper props like shouldDismissKeyboardBeforeClose (true by default) and keyboardAvoidingViewBehavior to have custom implementation and not work as expected anymore.

The same PR brought about changes related to how the keyboard / layout interactions behave and are being handled / animated / transitioned on Android: Native, which I think is also related to causing our glitch / delay when transitioning from one page to another where the keyboard is not needed and we have a button which is supposed to be fixed at the bottom.

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

Note

I also tried to play around with props like shouldEnableKeyboardAvoidingView and use Keyboard.dismiss() but none of those seem to fix the issue given the new android specific KeyboardAvoidingView implementation detailed above.

TLDR: Prevent displaying the Submit {amount} button until Keyboard.isVisible becomes false.

To do this we need to apply some changes to the FixedFooter component. We can do this in at least two different ways:

1. Add a new prop like onlyShowWhenKeyboardIsHidden and in BaseSelectionList where FixedFooter is used -> pass onlyShowWhenKeyboardIsHidden={Platform.OS === CONST.PLATFORM.ANDROID}.
2. Split the FixedFooter component into index.tsx which will remain unchanged and index.android.tsx where we will add specific logic to prevent displaying the children until Keyboard.isVisible becomes false (I know this is the recommended way).

For this proposal's sake I'm going with the first option (if selected we can further discuss the best way):

1. Modify FixedFooter as below, making sure to import Keyboard from react-native and the new prop type (boolean):

function FixedFooter({style, children, onlyShowWhenKeyboardIsHidden = false}: FixedFooterProps) {
    const styles = useThemeStyles();
    const isKeyboardVisible = Keyboard.isVisible();
    const shouldHide = onlyShowWhenKeyboardIsHidden ? isKeyboardVisible : false;

    if (!children || shouldHide) {
        return null;
    }

    return <View style={[styles.ph5, styles.pb5, styles.flexShrink0, style]}>{children}</View>;
}

2. In BaseSelectionList on this line, pass onlyShowWhenKeyboardIsHidden={Platform.OS === CONST.PLATFORM.ANDROID}.

Alternative solution

We should use await KeyboardUtils.dismiss() before calling the navigation to the confirmation screen.

A similar fix was already implemented in our FormProvider component.

Result video (before / after)

Android: Native (OnePlus 7T - Android 14 - Real device)

Before	After
before.mp4	after.mp4

[sonialiap]

I'm OOO Dec 16-20, adding a leave buddy

next steps:

• waiting for PR to be finished

[melvin-bot]

@suneox, @sonialiap, @huult, @techievivek, @MitchExpensify Eep! 4 days overdue now. Issues have feelings too...

[MitchExpensify]

@huult what is the latest on the PR?

[suneox]

@huult what is the latest on the PR?

I'm still reviewing the PR and will finish testing it today.

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

[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:

• 53182 submit button jump confirmation page #53529

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

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

• @suneox requires payment automatic offer (Reviewer)
• @huult requires payment automatic offer (Contributor)

[melvin-bot]

@suneox @sonialiap / @MitchExpensify @suneox 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]

[MitchExpensify]

Payment summary:

• $250 $125 @suneox requires payment automatic offer (Reviewer)
• $250 $125 @huult requires payment automatic offer (Contributor) - paid ✔️ - requesting refund for the overpayment

[MitchExpensify]

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:

• [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 Template

• [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

  Link to issue:

Regression Test Proposal

Precondition:

Test:

Do we agree 👍 or 👎

[sonialiap]

@suneox please complete the checklist. Once done we'll issue the payment :)

[suneox]

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: feat: edge-to-edge mode on Android #52392 (comment)

• [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: N/A

• [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.
  N/A: It isn't an impactful bug

[suneox]

@suneox please complete the checklist. Once done we'll issue the payment :)

I’ve completed the checklist, and the PR for this issue has introduced this regression

[parasharrajat]

@MitchExpensify Looks like there was a regression from this PR so that summary is wrong #53182 (comment)

cc: @sonialiap

[melvin-bot]

@suneox, @sonialiap, @huult, @techievivek, @MitchExpensify Huh... This is 4 days overdue. Who can take care of this?

[sonialiap]

Payment summary updated here to reflect the regression price decrease to 125

@suneox payment made ✔
@huult partial refund requested ✔

[huult]

@sonialiap I’ve quickly created a pull request to fix the regression test without needing to pick or rent out anything else. Could you please consider issuing a refund? Thank you.