[Due for payment 2026-04-23] [$250] DEV: Composer create popover menu is stuck

[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:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @bernhardoj
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Go to a workspace chat
2. Click the composer create button (+) > Create expense

Expected Result:

The popover menu is closed

Actual Result:

The popover menu is closed briefly and then shown again

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

web.2.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022042967539038532566
• Upwork Job ID: 2042967539038532566
• Last Price Increase: 2026-04-11

Issue Owner

Current Issue Owner: @adhorodyski

[MelvinBot]

Proposal

What is the root cause of that problem?

On web wide layout, the "Create expense" menu item sets shouldCallAfterModalHide: shouldUseNarrowLayout (AttachmentPickerWithMenuItems.tsx:235), which evaluates to false on web. This causes PopoverMenu.selectItem to take the synchronous else branch (PopoverMenu.tsx:347-350) — calling onItemSelected (which sets setMenuVisibility(false)) and onSelected (navigation) without going through Modal.close().

During the popover's close animation, the modal overlay is removed from the DOM, exposing the + button underneath. A residual pointer/click event from the original "Create expense" click propagates through to the now-exposed + button, triggering its onPress handler (AttachmentPickerWithMenuItems.tsx:454-463) which calls setMenuVisibility(!isMenuVisible) — reopening the popover.

On mobile (shouldUseNarrowLayout=true), the code routes through Modal.close() which properly sequences the callback after the modal fully hides, preventing the race condition. Additionally, the web version of useSingleExecution (index.ts:10-20) is a no-op, providing no double-click protection.

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

Change shouldCallAfterModalHide to true for the expense-related menu items on all platforms (not just narrow layout), so that PopoverMenu.selectItem always routes through Modal.close() for proper sequencing. This ensures the popover fully closes before the navigation callback fires, preventing the click event from reaching the + button.

In AttachmentPickerWithMenuItems.tsx, change the shouldCallAfterModalHide value from shouldUseNarrowLayout to true for the relevant menu items (create expense, split expense, track distance, etc.). The Safari file picker exception is already handled separately in onItemSelected, so this change should be safe.

What alternative solutions did you explore? (Optional)

1. Add double-click protection to the + button on web — This would mask the symptom rather than fix the root cause (improper sequencing of modal close and navigation).
2. Stop event propagation in selectItem — Would require changes to the shared PopoverMenu component and might break other menu behaviors.
3. Add a debounce/timeout to setMenuVisibility — Fragile timing-based fix that could break under different animation durations.

The proposed fix (always using shouldCallAfterModalHide: true) is the cleanest because it aligns the web behavior with the already-working mobile behavior.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[yuvrajangadsingh]

Proposal

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

In a workspace chat on web wide layout, clicking the composer create button (+) then selecting "Create expense" causes the popover menu to close briefly and immediately reopen.

What is the root cause of that problem?

I agree with MelvinBot's analysis of the mechanism but not the proposed fix.

On web wide layout, shouldCallAfterModalHide is shouldUseNarrowLayout which evaluates to false. This makes PopoverMenu.selectItem take the synchronous else branch (PopoverMenu.tsx:338-341), calling both onItemSelected (which calls setMenuVisibility(false) at AttachmentPickerWithMenuItems.tsx:527) and onSelected (navigation) without routing through Modal.close().

During the popover's close transition, the modal container gets pointer-events: none applied (BaseModal.tsx, when isVisible becomes false). This lets pointer events pass through to the + button underneath. The + button handler at AttachmentPickerWithMenuItems.tsx:448 calls setMenuVisibility(!isMenuVisible). Since isMenuVisible is now false, this flips it back to true, reopening the popover.

On narrow layout this doesn't happen because shouldCallAfterModalHide: true routes through Modal.close(), which sequences the callback after the modal fully hides.

MelvinBot's proposed fix won't work. Setting shouldCallAfterModalHide: true for all platforms was already tried in commit b82ea55cd1b by FitseTLT and explicitly reverted in commit 232dd965e17. The revert changed every item in AttachmentPickerWithMenuItems back from true to shouldUseNarrowLayout. It was reverted because forcing Modal.close() sequencing on web delays navigation until after the close animation finishes, which caused visual issues in the carousel/highlight flow (fix/83760-carousel-highlight-fab branch).

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

In AttachmentPickerWithMenuItems.tsx, add a ref-based guard that prevents the + button from toggling the menu when it was just closed by a menu item selection:

1. Add a ref: const closedBySelectionRef = useRef(false);

2. In the onItemSelected callback (line 526), set the ref before closing:

onItemSelected={(item, index) => {
    closedBySelectionRef.current = true;
    setMenuVisibility(false);
    onItemSelected();
    // ... rest unchanged
}}

3. In the + button's onPress handler (line 439), check the ref and bail out if the menu was just closed by selection:

onPress={(e) => {
    e?.preventDefault();
    if (!isFocused) {
        return;
    }
    if (closedBySelectionRef.current) {
        closedBySelectionRef.current = false;
        return;
    }
    onAddActionPressed();
    actionButtonRef.current?.blur();
    setMenuVisibility(!isMenuVisible);
}}

4. Pass onModalHide to the PopoverMenu (line 520) to clear the ref after the close animation completes, covering the case where no stray event arrives:

<PopoverMenu
    ...
    onModalHide={() => { closedBySelectionRef.current = false; }}
    ...
/>

This is deterministic (no timeouts or debounce), scoped to one file, and doesn't affect the shared PopoverMenu or Modal components.

Affected surfaces: src/pages/inbox/report/ReportActionCompose/AttachmentPickerWithMenuItems.tsx. The FAB (src/pages/inbox/sidebar/FloatingActionButtonAndPopover.tsx) uses the same shouldCallAfterModalHide: shouldUseNarrowLayout pattern but is less likely to manifest since the FAB button position doesn't overlap with its menu items.

What alternative solutions did you explore? (Optional)

1. shouldCallAfterModalHide: true (MelvinBot's suggestion) -- already tried in b82ea55cd1b and reverted in 232dd965e17. Delays navigation on web, caused visual regressions.
2. event.stopPropagation() in selectItem -- doesn't help because the + button is a sibling in the React tree, not a parent. stopPropagation only prevents upward bubbling.
3. Timing-based debounce on setMenuVisibility -- fragile, dependent on animation duration, could break under different conditions.

[TaduJR]

Regression from #87394 (comment)

Issue #87097

[melvin-bot]

📣 @ghmaimon! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[github-actions]

⚠️ @ghmaimon Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[ghmaimon]

Contributor details
Your Expensify account email: mimoun.ghordou@fladeed.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01d1b46ab621e8a597