[HOLD for payment 2023-11-21] [$500] Wrong position of payment method dropdown menu

[m-natarajan]

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: Dev only
Reproducible in staging?: DEV
Reproducible in production?: DEV
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: @situchan
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1699446024052489

Action Performed:

1. Open a report as account A
2. Send a Request money to Account B
3. Open the IOU detail

Expected Result:

Pay with expensify button appears within the card

Actual Result:

Pay with expensify button appears in the wrong position

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

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c488f2cde0f92e3d
• Upwork Job ID: 1722899907570507776
• Last Price Increase: 2023-11-10
• Automatic offers:
• getusha | Reviewer | 27606931
• s-alves10 | Contributor | 27606933
• situchan | Reporter | 27606934

Issue Owner

Current Issue Owner: @conorpendergrast

[melvin-bot]

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

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[ishpaul777]

Proposal

Problem

Wrong position of payment method dropdown menu

Root Cause

The issue occurs because .measureInWindow method used here is giving incorrect pos. values after the RNW upgrade, i believe the bug is upstream and not related to our codebase

Changes Suggested

we should follow the same pattern for setting position like we are using in BaseKYCWall i.e. using getClickedTargetLocation like below:

const getAnchorPosition = (domRect) => {
        if (props.anchorAlignment.vertical === CONST.MODAL.ANCHOR_ORIGIN_VERTICAL.TOP) {
            return {
                horizontal: domRect.left + domRect.width,
                vertical: domRect.top + domRect.height + CONST.MODAL.POPOVER_MENU_PADDING,
            };
        }

        return {
            horizontal: domRect.left + domRect.width,
            vertical: domRect.top - CONST.MODAL.POPOVER_MENU_PADDING,
        };
    }

    const setMenuPosition = () => {
        if (!caretButton.current) {
            return;
        }
        const buttonPosition = getClickedTargetLocation(caretButton.current);
        const position = getAnchorPosition(buttonPosition);
        setPopoverAnchorPosition(position);
    }

    useEffect(() => {
        if (!isMenuVisible) {
            return;
        }
        setMenuPosition();
    }, [windowWidth, windowHeight, isMenuVisible, setMenuPosition]);

[dummy-1111]

Proposal

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

Popover menu of payment method dropdown button is shown at the wrong position

What is the root cause of that problem?

We measure the anchor position of the popover menu below

App/src/components/ButtonWithDropdownMenu.js

Lines 91 to 99 in 3f2de5c

	caretButton.current.measureInWindow((x, y, w, h) => {
	setPopoverAnchorPosition({
	horizontal: x + w,
	vertical:
	props.anchorAlignment.vertical === CONST.MODAL.ANCHOR_ORIGIN_VERTICAL.TOP
	? y + h + CONST.MODAL.POPOVER_MENU_PADDING // if vertical anchorAlignment is TOP, menu will open below the button and we need to add the height of button and padding
	: y - CONST.MODAL.POPOVER_MENU_PADDING, // if it is BOTTOM, menu will open above the button so NO need to add height but DO subtract padding
	});
	});

This works fine but it gives a wrong position inside the inverted flat list. In inverted FlatList, -1 of scale is applied and measureInWindow gives the scaled result(Refer https://reactnative.dev/docs/flatlist#inverted). This looks like come from the recent change of react-native-web in this PR

Scaled measurement returns: This is the root cause

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

We can simply make a upstream patch
Add the following patch to the current patch

diff --git a/node_modules/react-native-web/dist/exports/UIManager/index.js b/node_modules/react-native-web/dist/exports/UIManager/index.js
index 15b71d5..46b9e01 100644
--- a/node_modules/react-native-web/dist/exports/UIManager/index.js
+++ b/node_modules/react-native-web/dist/exports/UIManager/index.js
@@ -77,7 +77,7 @@ var UIManager = {
   measureInWindow(node, callback) {
     if (node) {
       setTimeout(() => {
-        var _getRect2 = getRect(node),
+        var _getRect2 = node.getBoundingClientRect(),
           height = _getRect2.height,
           left = _getRect2.left,
           top = _getRect2.top,

This works as expected

Result

What alternative solutions did you explore? (Optional)

We need to take this scaled result into consideration

1. Add the props named shouldInvertMeasurement with default value false to the ButtonWithDropdownMenu and SettlementButton components
2. Update the above code to

caretButton.current.measureInWindow((x, y, w, h) => {
            const horizontal = x + w;
            const vertical = props.shouldInvertMeasurement ? windowHeight - y + 18 : y; // weird offset in inverted mode
            setPopoverAnchorPosition({
                horizontal,
                vertical: props.anchorAlignment.vertical === CONST.MODAL.ANCHOR_ORIGIN_VERTICAL.TOP
                    ? vertical + h + CONST.MODAL.POPOVER_MENU_PADDING // if vertical anchorAlignment is TOP, menu will open below the button and we need to add the height of button and padding
                    : vertical - CONST.MODAL.POPOVER_MENU_PADDING, // if it is BOTTOM, menu will open above the button so NO need to add height but DO subtract padding
            });
        });

3. Add shouldInvertMeasurement props with value true here in ReportPreview component

[dummy-1111]

This is reproducible in staging, and not in production. Can be a deploy blocker

cc @m-natarajan @conorpendergrast

[situchan]

@s-alves10 Scanning code in RNW upgrade, I don't see any change in UIManager.

[situchan]

This works fine but it gives a wrong position inside the inverted flat list. In inverted FlatList, -1 of scale is applied and measureInWindow gives the scaled result

Why used to work before RNW upgrade?

[situchan]

I am fine applying patch for now to fix deploy blocker but we should fix the real root cause for sure.
@getusha do you think this solution makes sense?

-        var _getRect2 = getRect(node),
+        var _getRect2 = node.getBoundingClientRect(),

[dummy-1111]

I debugged the RNW and getRect function in UIManager returns the wrong result for inverted FlatList. In the previous version, it works fine

[dummy-1111]

The getBoundingClientRect method returns the size of an element and its position relative to the viewport.

[getusha]

@s-alves10 @situchan probably adding shouldUseTargetLocation prop to PopoverWithMeasuredContent will solve this issue because we added that for this kind of issue. i am not sure if it will be accurate might need a slight touch.

[ishpaul777]

@situchan wdyt of changes I suggested in my proposal ?

[situchan]

@s-alves10 I see that shouldUseTargetLocation is added in emoji picker. Can you verify your patch will fix both issues without shouldUseTargetLocation?

[dummy-1111]

Sure

[dummy-1111]

@situchan

I've verified that both emoji picker and dropdown button work fine with the proposed patch

[situchan]

@s-alves10's proposal (main solution) looks good to me.
🎀 👀 🎀 C+ reviewed

[melvin-bot]

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

[getusha]

@situchan I think we should also create upstream PR, but i feel like it might not be accepted.

[situchan]

@situchan I think we should also create upstream PR, but i feel like it might not be accepted.

But at least we can let author know.

[getusha]

@situchan there is already an issue for that necolas/react-native-web#2589
i think using the fix in the App is a good idea instead of a patch.

[situchan]

@arosiclair will decide whether to

• apply patch
• or use existing solution applied during RNW upgrade to fix emoji picker position

[getusha]

@s-alves10 can you share how the popover will look like after applying the patch.

[dummy-1111]

@getusha

Here are the screenshots

cc @situchan

[arosiclair]

Okay I've verified that this is reproducible on staging v1.3.97-3 and not on prod v1.3.95-9:

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

• [CP Staging] Fix/issue 31069 #31184

If no regressions arise, payment will be issued on 2023-11-21. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

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

• @getusha requires payment offer (Reviewer)
• @s-alves10 requires payment offer (Contributor)
• @situchan requires payment offer (Reporter)

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

• [@getusha] The PR that introduced the bug has been identified. Link to the PR:
• [@getusha] 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:
• [@getusha] 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:
• [@getusha] Determine if we should create a regression test for this bug.
• [@getusha] 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.
• [@conorpendergrast] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[conorpendergrast]

Looks like this didn't get switched to Daily, and it's due payment!

[conorpendergrast]

Payouts due:

• Issue Reporter AND PR reviewer: $50 + $500 = $550 @situchan requires payment offer

• Contributor+: N/A @getusha - regression

• Contributor: $500 @s-alves10 requires payment offer

Upwork job is here.

[situchan]

I also reviewed PR

[conorpendergrast]

@situchan thanks, I had missed that. Noting for my future self: I see you listed as a reviewer for the PR that caused this regression but that's from comments made two days ago, so are not relevant to this issue and don't change payment

[conorpendergrast]

@s-alves10 please accept the offer!

[conorpendergrast]

@getusha Can you do the C+ checklist too, please? Thank you!

[dummy-1111]

@conorpendergrast

Offer accepted, thanks

[getusha]

@s-alves10 any updates on the upstream PR & issue? i am sure we shouldn't be ignoring that.

[dummy-1111]

https://expensify.slack.com/archives/C01GTK53T8Q/p1700803705123509?thread_ts=1699611327.310029&cid=C01GTK53T8Q

[conorpendergrast]

Paid! Just the C+ checklist now

[getusha]

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:

• [@getusha] The PR that introduced the bug has been identified. Link to the PR: N/A this is a bug from react-native-web introduced after upgrading to latest release.
• [@getusha] 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
• [@getusha] 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: N/A
• [@getusha] Determine if we should create a regression test for this bug. No this a minor bug and react-native-web issue.
• [@getusha] If we decide to create a [regression test] (https://github.com/Expensify/App/blob/main/contributingGuides/REGRESSION_TEST_BEST_PRACTICES.md) for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

[conorpendergrast]

Nice! All done, thank you everyone