[Due for payment 2026-09-18] Concierge prompt box - Suggestion list remains opened when dragging a file to Home

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.76-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #99912
Email or phone of affected tester (no customers): jsdoijnodsdisojo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Other

Action Performed:

1. Go to staging.new.expensify.com
2. Go to Home.
3. Type :sm on Concierge prompt box.
4. Drag a file to Home while suggestion list is opened.

Expected Result:

Suggestion list will close when dragging a file to Home.

Actual Result:

Suggestion list remains opened when dragging a file to Home.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7256535_1789081648447.4.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Vincenzo Godoy
Bug ID: 7256535

Issue Owner

Current Issue Owner: @ZhenjaHorbach

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/14090318b635787c11ae565e60aea82e82a435b9a16406c8392892836a7ec2d6

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #99912

[melvin-bot]

@puneetlath @ZhenjaHorbach you have been assigned to this deploy blocker because you reviewed the offending PR: #99912

[melvin-bot]

@GCyganek you have been assigned to this deploy blocker because you authored the offending PR: #99912

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #99912 - "Add mentions and emojis suggestions to Home prompt box; fix RHP suggestions" by @GCyganek (High confidence)
Related Issues: #99550 (the feature request this PR implemented), #100893 (StagingDeployCash)

Recommendation: ROLL FORWARD

The drag-dismiss behaviour already exists inside Suggestions but is driven by DragAndDropStateContext, and HomePage never renders a DragAndDropProvider — so the context falls back to its isDraggingOver: false default and the dismiss effect can never fire. That's a ~10 line wiring fix, whereas reverting #99912 would also roll back the shared useComposerSuggestions extraction that ComposerWithSuggestions and ReportActionItemMessageEdit now depend on (21 files, −264 lines from those two callers) plus the RHP z-index fix.

Assigned: @GCyganek (PR author), @puneetlath and @ZhenjaHorbach (approving reviewers) — already assigned by melvin-bot, attribution verified below.
Labels: No changes. DeployBlockerCash stays (App-side fix required). DeployBlocker was never applied, so nothing to remove.

📋 Detailed Analysis

Evidence

melvin-bot's guess was correct, and here is the verification rather than the heuristic:

1. The feature only exists because of Add mentions and emojis suggestions to Home prompt box; fix RHP suggestions #99912. Before that PR the Home Concierge prompt box rendered no suggestion list at all — the PR adds <Suggestions> and useComposerSuggestions to ConciergePromptBox. Typing :sm on Home produced nothing on the base commit (dc10c9e), so this cannot reproduce on production. That matches the report ("N/A - new feature, doesn't exist in prod").
2. Timeline fits. Add mentions and emojis suggestions to Home prompt box; fix RHP suggestions #99912 merged 2026-09-10T19:39Z; the blocker was filed 2026-09-11T01:38Z against 9.4.76-0, and Add mentions and emojis suggestions to Home prompt box; fix RHP suggestions #99912 is item 57 on the deploy checklist.
3. Add mentions and emojis suggestions to Home prompt box; fix RHP suggestions #99912 did not break the drag handling — it reused a component whose drag handling depends on a provider that Home doesn't have. The PR's diff touches no drag-and-drop logic (only an unrelated style passthrough in TransparentOverlay). The isDraggingOver effect in Suggestions.tsx is byte-identical at the PR's base commit, so it is pre-existing and untouched.

Reproduces on staging web only. It is inherently web-only: useDragAndDrop has a native stub returning {isDraggingOver: false}, and there is no file-drag gesture on native.

Verification

Affected files (all at dba098e):

• src/pages/home/ForYouSection/ConciergePromptBox.tsx#L374-L383 — <Suggestions> added by Add mentions and emojis suggestions to Home prompt box; fix RHP suggestions #99912.
• src/pages/home/HomePage.tsx#L49-L128 — the whole Home tree. No DragAndDropProvider anywhere in it.
• src/pages/inbox/report/ReportActionCompose/Suggestions.tsx#L67-L68 and #L140-L145 — the existing drag-dismiss mechanism.
• src/components/DragAndDrop/Provider/default.ts#L3-L6 — the silent default that Home gets instead.

gh pr view 99912 --json files confirms the PR modifies ConciergePromptBox.tsx and HomePage.tsx, and confirms it does not modify Suggestions.tsx or anything under src/components/DragAndDrop/. ConciergePromptBox is the only <Suggestions> consumer outside src/pages/inbox/report/ — the other two (ComposerWithSuggestions via ReportFooter, and ReportActionItemMessageEdit) both mount under ReportScreen.

Root Cause

Suggestions dismisses itself on drag by watching context, not DOM events:

// Suggestions.tsx:67
const {isDraggingOver} = useDragAndDropState();
const prevIsDraggingOver = usePrevious(isDraggingOver);
...
// Suggestions.tsx:140
useEffect(() => {
    if (!(!prevIsDraggingOver && isDraggingOver)) {
        return;
    }
    updateShouldShowSuggestionMenuToFalse();
}, [isDraggingOver, prevIsDraggingOver, updateShouldShowSuggestionMenuToFalse]);

useDragAndDropState() is useContext(DragAndDropStateContext), and that context was created with a non-throwing default of {isDraggingOver: false, dropZoneID: ''}. So outside a DragAndDropProvider the hook silently returns a constant false, prevIsDraggingOver === isDraggingOver === false forever, and the effect body never runs. No error, no warning — the behaviour just disappears.

Why it works in a report: ReportScreen wraps its subtree in ReportDragAndDropProvider → DragAndDropProvider, which runs useDragAndDrop on its own wrapper View and publishes real isDraggingOver into the context. The composer's suggestion list is inside that provider, so dragging a file over a chat dismisses it.

Why Home is different: Home does handle file drags, but through a completely separate path — ReceiptScanDropZone calls useDragAndDrop directly and keeps isDraggingOver in local component state, publishing nothing to context. ReceiptScanDropZone is also a sibling of ScreenWrapper in HomePage, not an ancestor of the prompt box, so it could not provide the context even if it wanted to. Net result: the receipt "Scan receipts" drop overlay appears on drag, the + PopoverMenu does get closed (useDragAndDrop calls closePopover() on dragenter, index.ts#L61-L63), but the suggestion list — which is not a PopoverProvider popover, it is a ReactDOM.createPortal into document.body — is left visible. None of ConciergePromptBox's own dismiss paths fire either: dragging a file does not blur the composer (onBlur → hideSuggestionMenu), does not scroll the input, and does not unfocus the screen.

Suggested fix

Publish Home's existing page-level drag state into the context the suggestion list already listens to. Single file, src/pages/home/HomePage.tsx:

import {DragAndDropStateContext} from '@components/DragAndDrop/Provider/DragAndDropContext';
import useDragAndDrop from '@hooks/useDragAndDrop';
import htmlDivElementRef from '@src/types/utils/htmlDivElementRef';

function shouldAcceptDrop(event: DragEvent): boolean {
    return !!event.dataTransfer?.types.some((type) => type === 'Files');
}

function HomePage() {
    // ...
    // Observe-only: ReceiptScanDropZone owns the actual drop. This just exposes the page's drag state
    // through DragAndDropStateContext so the Concierge prompt suggestion list dismisses itself on drag,
    // the same way it does inside a report.
    const {isDraggingOver} = useDragAndDrop({
        dropZone: htmlDivElementRef(receiptDropTargetRef),
        shouldAcceptDrop,
        shouldHandleDragEvent: false,
    });

    return (
        <DragAndDropStateContext.Provider value={{isDraggingOver, dropZoneID: ''}}>
            {/* existing tree unchanged */}
        </DragAndDropStateContext.Provider>
    );
}

shouldHandleDragEvent: false keeps this listener from re-doing the dropEffect/closePopover work ReceiptScanDropZone already performs, and onDrop defaults to a no-op so the receipt-scan drop path is untouched. stopPropagation only stops ancestor bubbling, not other listeners on the same node, so both hooks still receive the events.

An equally valid alternative, matching the setIsDraggingOver prop DragAndDropProvider already exposes, is to add an onDraggingOverChange prop to ReceiptScanDropZone and lift the state into HomePage. It avoids the duplicate listener but reports state upward from an effect, which PERF-10 discourages — author's call.

Note for whoever fixes it: tests/unit/pages/HomePage.test.tsx:82 mocks out ReceiptScanDropZone, so a regression test for this needs the drag state to come from somewhere the mock does not remove.

What I could not verify

• I did not run the app. This analysis is from the code and the PR diffs; I did not reproduce the bug in a browser or confirm the proposed fix live.
• Whether the drag is only cosmetically broken. On web the suggestion list is portaled to document.body, i.e. outside receiptDropTargetRef. TransparentOverlay hides itself while dragging (isDraggingOver && styles.dNone), but the suggestion list View itself does not, so a file dropped directly on top of the list may land on a non-drop-zone element and make Chrome open/download the file instead of starting a receipt scan. That is a plausible reading of the code, not something I observed — worth checking during QA, because it would make this more than cosmetic. It is also a residual edge case for the suggested fix (a drag that first enters over the list would not reach receiptDropTargetRef).
• isDragDisabled: isAnonymousUser. ReceiptScanDropZone's hook is disabled for anonymous users, so the suggested fix would not dismiss for them. Anonymous users cannot use the prompt box anyway (interceptAnonymousUser), but I did not test that path.
• Whether the Concierge RHP composer (Help button) has the same missing-provider gap. It is out of scope for this report and I did not trace its provider tree.

---

💡 Suggested AI code review rule

This is the second-order kind of bug that a rule can catch mechanically: a component was reused in a new tree, and a context it silently defaults on turned one of its behaviours off with no error. Proposed for Expensify/App (.claude/skills/coding-standards):

• Rule: CLEAN-REACT-PATTERNS-10 — Mount a reused component under the providers its behaviour depends on
• Condition: Flag when a PR renders an existing component (or calls an existing hook) in a new screen/tree and that component consumes a context created with a non-throwing default of falsy flags, empty strings, or no-op functions, unless the new tree also renders the matching provider. Either render the provider or thread the state in via props — do not rely on the default.
• Why: A createContext default that is a valid-looking no-op makes a missing provider unobservable: no error, no warning, the feature just silently loses a behaviour. Here Suggestions dismisses itself on file-drag by reading DragAndDropStateContext; mounted on Home, where there is no DragAndDropProvider, it received the constant isDraggingOver: false default and the dismiss effect could never fire ([Due for payment 2026-09-18] Concierge prompt box - Suggestion list remains opened when dragging a file to Home #100915).
• Search pattern: for a newly cross-tree import, grep -rn "useContext(\|use[A-Z][A-Za-z]*State()" <reused component's directory>, then check each context's createContext<...>(<default>) — if the default is not undefined/throwing, confirm the new host renders the provider. Cross-tree reuse itself: grep -rn "from '@pages/inbox/report" src/pages --include=*.tsx | grep -v "^src/pages/inbox/".
• Offending code (❌): ConciergePromptBox.tsx#L374-L383 mounted under HomePage.tsx#L49-L128 (no provider), consuming Suggestions.tsx#L67-L68 against the silent default
• Correct shape (✅): ReportScreen.tsx#L132 wrapping the same component in ReportDragAndDropProvider

It is distinct from CLEAN-REACT-PATTERNS-3 (that one is about prop contracts leaking consumer assumptions, not about implicit provider dependencies). If it is worth adding, a maintainer can open it as a draft PR in Expensify/App with the ❌/✅ code inline.