[$250] Web - Workspace - Workspace More menu opens on the left

[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.1.13-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Mac 15.3 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Account has at least one workspace.

1. Go to staging.new.expensify.com
2. Go to Settings > Workspaces.
3. Click on any workspace.
4. Go to Reports.
5. Go back to Settings.
6. Click app back button.
7. Click 3-dot menu on the workspace row.

Expected Result:

More menu will open at where the 3-dot menu is.

Actual Result:

More menu opens on the left.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6770613_1741956703547.20250314_204729.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021902099872891314657
• Upwork Job ID: 1902099872891314657
• Last Price Increase: 2025-03-25

Issue Owner

Current Issue Owner: @rushatgabhane

[melvin-bot]

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

[FitseTLT]

🚨 Edited by proposal-police: This proposal was edited at 2025-03-14 15:25:28 UTC.

Proposal

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

Web - Workspace - Workspace More menu opens on the left

What is the root cause of that problem?

In #56594 we changed the menu anchor position to be calculated onLayout instead of onPress

App/src/pages/workspace/WorkspacesListRow.tsx

Lines 171 to 182 in b09e2d1

	onLayout={(e: LayoutChangeEvent) => {
	if (shouldUseNarrowLayout) {
	return;
	}
	const target = e.target || (e as LayoutChangeEventWithTarget).nativeEvent.target;
	target?.measureInWindow((x, y, width) => {
	setThreeDotsMenuPosition({
	horizontal: x + width,
	vertical: y,
	});
	});
	}}

onLayout is being called too early in this case and the anchor position will be miscalculated

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

We used this approach to solve a bug related with search menu item so we can revert it for this cases and others that cause a problem and set the anchor position onPress

                       <ThreeDotsMenu
                            onIconPress={() => {
                                if (shouldUseNarrowLayout) {
                                    return;
                                }
                                threeDotsMenuContainerRef.current?.measureInWindow((x, y, width, height) => {
                                    setThreeDotsMenuPosition({
                                        horizontal: x + width,
                                        vertical: y + height,
                                    });
                                });
                            }}

Or optionally we can give the calculation any kind of delay and it will fix the problem, for instance, setTimeout like:

 if (shouldUseNarrowLayout) {
                                return;
                            }
                            setTimeout(() => {
                                const target = e.target || (e as LayoutChangeEventWithTarget).nativeEvent.target;
                                target?.measureInWindow((x, y, width) => {
                                    setThreeDotsMenuPosition({
                                        horizontal: x + width,
                                        vertical: y,
                                    });
                                });
                            });

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N / A - UI bug

What alternative solutions did you explore? (Optional)

Alternatively we can reimplement the solution in #56594. We can revert it to change it back to calculating the anchor position on press but to solve the original issue we will make onIconPress to return a promise that will resolve inside measureInWindow after the anchor position is set then inside ThreeDotsMenu we will call showPoppover after the promise in onIconPress resolves so that it will show the popover after the anchor position is calculated and set to the correct position.

App/src/components/ThreeDotsMenu/index.tsx

Lines 71 to 74 in b09e2d1

	showPopoverMenu();
	if (onIconPress) {
	onIconPress();
	}

[Themoonalsofall]

Proposal

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

Web - Workspace - Workspace More menu opens on the left

What is the root cause of that problem?

We are calculating three dots position in onLayout function

App/src/pages/workspace/WorkspacesListRow.tsx

Lines 169 to 183 in b09e2d1

	<View
	ref={threeDotsMenuContainerRef}
	onLayout={(e: LayoutChangeEvent) => {
	if (shouldUseNarrowLayout) {
	return;
	}
	const target = e.target || (e as LayoutChangeEventWithTarget).nativeEvent.target;
	target?.measureInWindow((x, y, width) => {
	setThreeDotsMenuPosition({
	horizontal: x + width,
	vertical: y,
	});
	});
	}}
	>

but there will be cases where onLayout is called too early, leading to incorrect calculations.

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

We can use InteractionManager.runAfterInteractions to ensure that measureInWindow runs only after all animations and layout calculations have finished.

onLayout={(e: LayoutChangeEvent) => { 
    if (shouldUseNarrowLayout) { 
        return; 
    } 

    InteractionManager.runAfterInteractions(() => {
        const target = e.target || (e as LayoutChangeEventWithTarget).nativeEvent.target; 
        target?.measureInWindow((x, y, width) => { 
            setThreeDotsMenuPosition({ 
                horizontal: x + width, 
                vertical: y, 
            }); 
        }); 
    });
}}

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None UI bug

What alternative solutions did you explore? (Optional)

Or we can use the useEffect with viewRef

const viewRef = useRef<View>(null);

useEffect(() => {
    if (!shouldUseNarrowLayout && viewRef.current) {
        viewRef.current.measureInWindow((x, y, width) => {
            setThreeDotsMenuPosition({ 
                horizontal: x + width, 
                vertical: y, 
            });
        });
    }
}, [shouldUseNarrowLayout, viewRef]);

<View ref={viewRef} onLayout={() => {}} />

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[FitseTLT]

Added alt section

[melvin-bot]

@CortneyOfstad Whoops! This issue is 2 days overdue. Let's get this updated quick!

[CortneyOfstad]

Getting eyes

[melvin-bot]

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

[melvin-bot]

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

[Themoonalsofall]

friendly bump @rushatgabhane

[melvin-bot]

@rushatgabhane Eep! 4 days overdue now. Issues have feelings too...

[rushatgabhane]

reviewing

[FitseTLT]

This is dupe @rushatgabhane

[rushatgabhane]

dupe of?

[FitseTLT]

cc @bernhardoj

[bernhardoj]

It will be fixed here #57920

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[melvin-bot]

@CortneyOfstad @rushatgabhane this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

@rushatgabhane Whoops! This issue is 2 days overdue. Let's get this updated quick!

[CortneyOfstad]

I'm also not able to recreate so going to close!

I am heading OoO this afternoon — March 28 to April 7. If this needs to be reopened to whatever reason, please reapply the label or reach out in Slack, otherwise I will review when I get back. Thanks!