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