[$250] IOS - Expense/IOU - Keyboard overlaps camera when replacing receipt

[lanitochka17]

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.50
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Action Performed:

1. Open the app and log in
2. Navigate to any chat
3. Tap + > Submit expense > Manual
4. Enter the amount, add the receipt on the confirmation step and submit IOU/expense
5. Navigate to the IOU/expense details
6. While the keyboard is up, scroll up and tap the receipt
7. Select 3 dots > Replace

Expected Result:

The keyboard is hidden

Actual Result:

The keyboard is still displayed and overlaps the camera

Workaround:

Unknown

Platforms:

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

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

Screenshots/Videos

Add any screenshot/video evidence

Bug6638131_1729195839730.IMG_0494.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021849498756209836053
• Upwork Job ID: 1849498756209836053
• Last Price Increase: 2024-10-24

Issue Owner

Current Issue Owner: @suneox

[melvin-bot]

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

[c3024]

Proposal

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

Keyboard overlaps with camera view when replacing receipt.

What is the root cause of that problem?

When we click on Replace in AttachmentModal, we execute closeModal first and then navigate to the receipt selection scan page.

App/src/components/AttachmentModal.tsx

Lines 419 to 428 in 8ca4576

	closeModal();
	Navigation.navigate(
	ROUTES.MONEY_REQUEST_STEP_SCAN.getRoute(
	CONST.IOU.ACTION.EDIT,
	iouType,
	transaction?.transactionID ?? '-1',
	report?.reportID ?? '-1',
	Navigation.getActiveRouteWithoutParams(),
	),
	);

This closeModal executes onModalClose if it is a function

App/src/components/AttachmentModal.tsx

Lines 381 to 386 in 8ca4576

	const closeModal = useCallback(() => {
	setIsModalOpen(false);
	if (typeof onModalClose === 'function') {
	onModalClose();
	}

We dismiss the attachment modal in TransactionReceiptPage here in onModalClose

App/src/pages/TransactionReceiptPage.tsx

Lines 53 to 58 in 8ca4576

	Navigation.dismissModal();
	} else {
	Navigation.dismissModal(
	ReportUtils.isOneTransactionThread(report?.reportID ?? '-1', report?.parentReportID ?? '-1', parentReportAction) ? report?.parentReportID : report?.reportID,
	);
	}

When we dispatch two such navigation actions (dismissModal and navigate to scan page) one after another immediately, we cannot be sure of the order in which they execute and the actions seem to be interfere with each other.

navigationRef.dispatch with StackActions.pop() used in dismissModal involves a little more complex process of action handling, so this issue is most evident when using dismissModal. A similar issue is seen here.

Using goBack instead of dismissModal reduces this largely but still there are chances of unexpected order.

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

We should wait for the navigation actions in onModalClose to complete before sending new navigation actions.
So, we can change this

App/src/components/AttachmentModal.tsx

Line 420 in 8ca4576

Navigation.navigate(

to

Navigation.setNavigationActionToMicrotaskQueue(() => Navigation.navigate(

so that the next navigation action is added to the micro task queue and gets executed only after the previous navigation action is complete.

What alternative solutions did you explore? (Optional)

[melvin-bot]

@JmillsExpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

@JmillsExpensify Huh... This is 4 days overdue. Who can take care of this?

[JmillsExpensify]

Opening up to the community.

[melvin-bot]

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

[melvin-bot]

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

[suneox]

@c3024 Thank you for your proposal. However, your RCA isn’t clear about which event or referenced code is triggering the input focus that opens the keyboard. Could you please provide more information on that point?

[c3024]

When we go to a report without any messages, composer autofocuses here

App/src/pages/home/report/ReportActionCompose/ComposerWithSuggestions/ComposerWithSuggestions.tsx

Line 306 in 66112d1

(shouldFocusInputOnScreenFocus || (isEmptyChat && !ReportActionsUtils.isTransactionThread(parentReportAction))) &&

So, when we close the attachment modal we return to the money request report and the money request view is not considered a message so the composer autofocuses and the keyboard shows up.

I think when the navigation actions are dispatched simultaneously and not successively, the focus seems to trigger later than the second navigation action (here opening the scan page) or the next navigation to scan page happens before the blurring of the composer and the keyboard remains visible.

[shahinyan11]

@suneox Hi there. I posted a proposal for this issue a week ago, but somehow it was posted under a different issue. I must have mixed up the issues and posted the solution in the wrong place. I don't know if you'll take this into account, but I'll add my suggestion here too. Thank you

[shahinyan11]

Proposal

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

IOS - Expense/IOU - Keyboard overlaps camera when replacing receipt

What is the root cause of that problem?

On pressing replace in the three-dot menu we call the closeModal function here before navigation. The closeModal in turn calls the onModalClose function from the component props and it calls Navigation.dismissModal inside ( See here ).
Above implementation leads to keyboard activation on report screen before navigation to new screen

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

1. Add optional shouldCallParentClose param for closeModal function and update function body to below

    const closeModal = useCallback(( shouldCallParentClose =  true) => {
        setIsModalOpen(false);

        if (typeof onModalClose === 'function' && shouldCallParentClose) {
            onModalClose();
        }

        // eslint-disable-next-line react-compiler/react-compiler, react-hooks/exhaustive-deps
    }, [onModalClose]);

2. Call the closeModal function with false parameter .

3. OPTIONAL: Move closeModal(false) under Navigation.navigate

onSelected: () => {
    Navigation.navigate(
        ROUTES.MONEY_REQUEST_STEP_SCAN.getRoute(
            CONST.IOU.ACTION.EDIT,
            iouType,
            transaction?.transactionID ?? '-1',
            report?.reportID ?? '-1',
            Navigation.getActiveRouteWithoutParams(),
        ),
    );
    closeModal(false);
},

What alternative solutions did you explore? (Optional)