[HOLD for payment 2024-06-11] [LOW] [Splits] [$500] IOU - App returns to participant selection page when hitting Save with Tab on Description page

[m-natarajan]

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: 1.4.45-0
Reproducible in staging?: y
Reproducible in production?: n
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause internal team
Slack conversation:

Action Performed:

1. Go to staging.new.expensify.com
2. Go to FAB > Request money > Manual.
3. Enter amount and select participant.
4. On confirmation page, press Tab.
5. Navigate to Description and hit Enter.
6. Enter description and save it with Tab and Enter key.

Expected Result:

The description will be saved and app will land on confirmation page.

Actual Result:

The description is saved and app returns to participant selection page.

Workaround:

unknown

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

Screenshots/Videos

Add any screenshot/video evidence

Bug6396444_1709169446044.bandicam_2024-02-29_08-22-30-102.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~010769f678e16c288e
• Upwork Job ID: 1767859361668382720
• Last Price Increase: 2024-03-27
• Automatic offers:
• akinwale | Reviewer | 0

Issue Owner

Current Issue Owner: @MitchExpensify

[melvin-bot]

Triggered auto assignment to @MitchExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

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

[melvin-bot]

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

[m-natarajan]

@techievivek FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors.

[bernhardoj]

This has the same root cause as #33502 (comment)

[techievivek]

Not a blocker for sure. Also, not sure if we really want to fix this. Or as per this comment #33502 (comment) we can solve all this together.

[techievivek]

@MitchExpensify Do you have any thoughts about above ^?

[dragnoir]

Proposal

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

Save button clicked by keyboard go back twice

What is the root cause of that problem?

When I tested, I found that there's no issue with react navigation or react native web. The issue is within our button component.

A simple check anyone can do, replace the button with the one from react-native, no issue :)

The issue is whith all the button components on the app. Every action via keyboard enter key will trigger double the action.

App/src/components/Button/index.tsx

Lines 281 to 284 in 0cc5817

	if (event?.type === 'click') {
	const currentTarget = event?.currentTarget as HTMLElement;
	currentTarget?.blur();
	}

The condition above doesn't check if there's a keyboard enter key event.

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

The best way to handle here:

               onPress={(event) => {
                    if (event?.type === 'click') {
                        const currentTarget = event?.currentTarget as HTMLElement;
                        currentTarget?.blur();
                    }

+                  if (event?.type === 'keyup') {
+                        return;
+                   }

                    if (shouldEnableHapticFeedback) {
                        HapticFeedback.press();
                    }
                    return onPress(event);
                }}

This will prevent the double actions on the Button component and will solve the related bugs.

What alternative solutions did you explore? (Optional)

[MitchExpensify]

Not worth fixing at this time

[dragnoir]

@MitchExpensify the issue is within all buttons on the app and there's an easy fix here

[MitchExpensify]

If there is a general solution its worth considering reopening, @techievivek does the solution linked above look like it will fix all cases of this?

[dragnoir]

@techievivek can you please check my proposal? Thank you

[techievivek]

Adding a C+ so they can help review the proposal.

[melvin-bot]

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

📣 @dragnoir You have been assigned to this job!
Please apply to the Upwork job and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Once you apply to this job, your Upwork ID will be stored and you will be automatically hired for future jobs!
Keep in mind: Code of Conduct | Contributing 📖

[MitchExpensify]

What's our ETA on the PR @dragnoir ?

[dragnoir]

PR ready #39924

[techievivek]

Hmm, not sure why automation didn't work here. @MitchExpensify Can we look into the payments here? Thanks.

[mallenexpensify]

Still hasn't hit production, so payment isn't due for at least a week.

[MitchExpensify]

Still holding on PR to hit production to start the 7 day countdown to payment

[bernhardoj]

Since we are not fixing this globally, can I request to reopen #33502, please? I already have an accepted proposal there but gets closed. The upstream PR is already merged, so the plan is to:

1. Update rn-web to 0.19.11
2. Remove the workaround

The fix will fix this GH, #40602, #33502, and other unrecorded keyboard enter issues.

@techievivek @akinwale

cc: @roryabraham as the assigned engineer for the tab accessibility issue

[roryabraham]

@bernhardoj why don't you post your proposal on #40602 ?

[bernhardoj]

@roryabraham I'm hoping to get the bounty from that issue 😄. I really don't like how it's handled in that issue. The first discussion decided to fix the issue, I got assigned, then the 2nd discussion decided to close the issue 😞.

[roryabraham]

@bernhardoj I reopened #33502 - let's proceed with the RNW upgrade

[dragnoir]

@MitchExpensify can you pls check payment here?

[MitchExpensify]

Payment summary:

C $500 @dragnoir
C+ $500 @akinwale

Both paid via Upwork, contracts ended also

[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 1.4.78-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Update rn-web to 0.19.12 #40960

If no regressions arise, payment will be issued on 2024-06-11. 🎊

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

• @akinwale requires payment automatic offer (Reviewer)
• @dragnoir requires payment (Needs manual offer from BZ)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@akinwale] The PR that introduced the bug has been identified. Link to the PR:
• [@akinwale] 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:
• [@akinwale] A discussion in #expensify-bugs 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:
• [@akinwale] Determine if we should create a regression test for this bug.
• [@akinwale] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@MitchExpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: