[Due for payment 2025-09-17] [$250] Dropping receipts in scan area also opens attachment view

[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: 9.2.0-0
Reproducible in staging?: Y
Reproducible in production?: Y
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: @Krishna2323
Slack conversation (hyperlinked to channel name): #Opensource

Action Performed:

1. Create a new workspace
2. Open FAB > Start chat > Select #Room tab
3. Enter name and create
4. Drop an attachment in the report
5. Tap Header > Members > Invite >Select a user and invite
6. Drop a receipt in Scan drop zone

Expected Result:

Attachment preview modal is opened along with the create IOU RHP

Actual Result:

Only start IOU RHP should open

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
• MacOS: Desktop

Platforms Tested:

On which of our officially supported platforms was this issue tested:

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

Screenshots/Videos

Add any screenshot/video evidence

Monosnap.screencast.2025-08-25.11-56-45.mp4

Recording.1577.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021961297292501239827
• Upwork Job ID: 1961297292501239827
• Last Price Increase: 2025-08-29

Issue Owner

Current Issue Owner: @jliexpensify

[melvin-bot]

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

[m-natarajan]

Proposal by @Krishna2323

Proposal

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

Rooms - Dropping receipts in scan area also opens attachment view

What is the root cause of that problem?

• Global handler persists in Provider
  • The DragAndDropProvider stores a global onDrop in a ref and passes it into the hook. Since it's a ref, updating it doesn't trigger a re-render, and there's no built-in cleanup/unregister behavior, so the last set handler can persist across UI switches.
    

    App/src/components/DragAndDrop/Provider/index.tsx

    Lines 23 to 33 in 93f456d

    	const onDropHandler = useRef<SetOnDropHandlerCallback>(() => {});
    	const setOnDropHandler = useCallback((callback: SetOnDropHandlerCallback) => {
    	onDropHandler.current = callback;
    	}, []);
    	const {isDraggingOver} = useDragAndDrop({
    	dropZone: htmlDivElementRef(dropZone),
    	onDrop: onDropHandler.current,
    	shouldAcceptDrop,
    	isDisabled,
    	});

• Single dropzone registers a handler; dual dropzone does not clear it
  • In single-dropzone mode, ReportActionCompose renders a DragAndDropConsumer with onDrop={handleAttachmentDrop}, which registers the Provider's handler.
    

    App/src/pages/home/report/ReportActionCompose/ReportActionCompose.tsx

    Lines 664 to 682 in 93f456d

    	{shouldDisplayDualDropZone && (
    	<DualDropZone
    	isEditing={shouldAddOrReplaceReceipt && hasReceipt}
    	onAttachmentDrop={handleAttachmentDrop}
    	onReceiptDrop={handleAddingReceipt}
    	shouldAcceptSingleReceipt={shouldAddOrReplaceReceipt}
    	/>
    	)}
    	{!shouldDisplayDualDropZone && (
    	<DragAndDropConsumer onDrop={handleAttachmentDrop}>
    	<DropZoneUI
    	icon={Expensicons.MessageInABottle}
    	dropTitle={translate('dropzone.addAttachments')}
    	dropStyles={styles.attachmentDropOverlay(true)}
    	dropTextStyles={styles.attachmentDropText}
    	dashedBorderStyles={styles.activeDropzoneDashedBorder(theme.attachmentDropBorderColorActive, true)}
    	/>
    	</DragAndDropConsumer>
    	)}

• When switching to dual-dropzone mode, ReportActionCompose removes that DragAndDropConsumer and renders
  • DualDropZone, which includes a DragAndDropConsumer without onDrop, so the Provider keeps the old handleAttachmentDrop.
    

    App/src/pages/home/report/ReportActionCompose/ReportActionCompose.tsx

    Lines 664 to 671 in 93f456d

    	{shouldDisplayDualDropZone && (
    	<DualDropZone
    	isEditing={shouldAddOrReplaceReceipt && hasReceipt}
    	onAttachmentDrop={handleAttachmentDrop}
    	onReceiptDrop={handleAddingReceipt}
    	shouldAcceptSingleReceipt={shouldAddOrReplaceReceipt}
    	/>
    	)}

    
    

    App/src/components/DropZone/DualDropZone.tsx

    Lines 26 to 36 in 93f456d

    	function DualDropZone({isEditing, onAttachmentDrop, onReceiptDrop, shouldAcceptSingleReceipt}: DropZoneProps) {
    	const styles = useThemeStyles();
    	const {translate} = useLocalize();
    	const {shouldUseNarrowLayout, isMediumScreenWidth} = useResponsiveLayout();
    	const theme = useTheme();
    	const shouldStackVertically = shouldUseNarrowLayout || isMediumScreenWidth;
    	const scanReceiptsText = shouldAcceptSingleReceipt ? 'dropzone.addReceipt' : 'dropzone.scanReceipts';
    	return (
    	<DragAndDropConsumer>

• Event bubbling triggers both the stale Provider handler and the zone handler
  • Each DropZoneWrapper from ( dual-dropzone mode) explicitly allows the native drop event to bubble by setting shouldStopPropagation: false. This means a drop in the receipt zone will also reach the Provider's handler.
    

    App/src/components/DropZone/DropZoneWrapper.tsx

    Lines 18 to 28 in 93f456d

    	function DropZoneWrapper({onDrop, children}: DropZoneWrapperProps) {
    	const styles = useThemeStyles();
    	const dropZone = useRef<HTMLDivElement | View>(null);
    	const {isDraggingOver} = useDragAndDrop({
    	shouldAcceptDrop: (event) => !!event.dataTransfer?.types.some((type) => type === 'Files'),
    	onDrop,
    	shouldStopPropagation: false,
    	shouldHandleDragEvent: false,
    	dropZone: htmlDivElementRef(dropZone),
    	});

• Consumer sets the Provider handler only when onDrop is provided
  • The Consumer registers the Provider's handler when onDrop exists, so the Provider could keep the old handler when switching views.
    

    App/src/components/DragAndDrop/Consumer/index.tsx

    Lines 9 to 14 in 93f456d

    	useEffect(() => {
    	if (!onDrop) {
    	return;
    	}
    	setOnDropHandler?.(onDrop);
    	}, [onDrop, setOnDropHandler]);

• The Provider is globally active for the screen
  • The report screen is wrapped with the DragAndDropProvider, so the bubbling drop event always has a global target.
    

    App/src/pages/home/ReportScreen.tsx

    Lines 831 to 835 in 93f456d

    	<DragAndDropProvider isDisabled={isEditingDisabled}>
    	<View
    	style={[styles.flex1, styles.justifyContentEnd, styles.overflowHidden]}
    	testID="report-actions-view-wrapper"
    	>

Impact

• After switching from single to dual dropzone, dropping a file on the receipt "replace" zone calls both: The DropZoneWrapper's onReceiptDrop handler,
• The stale Provider-level handler previously set by the single-dropzone Consumer (handleAttachmentDrop).
• This happens because the global onDrop remains set in the Provider and the drop event bubbles up from DropZoneWrapper to the Provider.

Why it's subtle

• The Provider's onDrop comes from a ref; changing it doesn't cause a re-render, and there was no cleanup when the Consumer unmounted or omitted onDrop. Combined with shouldStopPropagation: false in DropZoneWrapper, it leads to the Provider firing stale logic even when UI switches to DualDropZone.

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

1. The easiest solution is to pass a no-op onDrop to DragAndDropConsumer in DualDropZone.
   

   App/src/components/DropZone/DualDropZone.tsx

   Lines 26 to 36 in 93f456d

   	function DualDropZone({isEditing, onAttachmentDrop, onReceiptDrop, shouldAcceptSingleReceipt}: DropZoneProps) {
   	const styles = useThemeStyles();
   	const {translate} = useLocalize();
   	const {shouldUseNarrowLayout, isMediumScreenWidth} = useResponsiveLayout();
   	const theme = useTheme();
   	const shouldStackVertically = shouldUseNarrowLayout || isMediumScreenWidth;
   	const scanReceiptsText = shouldAcceptSingleReceipt ? 'dropzone.addReceipt' : 'dropzone.scanReceipts';
   	return (
   	<DragAndDropConsumer>

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

What alternative solutions did you explore? (Optional)

1. In DragAndDropConsumer, always set (or clear) the handler, and clean up on unmount.

   useEffect(() => {
       // If onDrop is missing, explicitly clear to a no-op
       setOnDropHandler?.(onDrop ?? (() => {}));
       // On unmount, also clear
       return () => setOnDropHandler?.(() => {});
   }, [onDrop, setOnDropHandler]);
2. In `DragAndDropProvider`, pass a wrapper that reads the latest ref at event time

 const {isDraggingOver} = useDragAndDrop({
     dropZone: htmlDivElementRef(dropZone),
     // Always call the latest handler stored in the ref
     onDrop: (event) => onDropHandler.current?.(event),
     shouldAcceptDrop,
     isDisabled,
 });

3. Update shouldStopPropagation: false to shouldStopPropagation: true:
   

   App/src/components/DropZone/DropZoneWrapper.tsx

   Line 25 in 93f456d

   shouldStopPropagation: false,

4. Update ReportActionCompose to use single DragAndDropConsumer and remove DragAndDropConsumer from the DualDropZone.
   

   App/src/pages/home/report/ReportActionCompose/ReportActionCompose.tsx

   Lines 664 to 683 in 6cbd35e

   	{shouldDisplayDualDropZone && (
   	<DualDropZone
   	isEditing={shouldAddOrReplaceReceipt && hasReceipt}
   	onAttachmentDrop={handleAttachmentDrop}
   	onReceiptDrop={handleAddingReceipt}
   	shouldAcceptSingleReceipt={shouldAddOrReplaceReceipt}
   	/>
   	)}
   	{!shouldDisplayDualDropZone && (
   	<DragAndDropConsumer onDrop={handleAttachmentDrop}>
   	<DropZoneUI
   	icon={Expensicons.MessageInABottle}
   	dropTitle={translate('dropzone.addAttachments')}
   	dropStyles={styles.attachmentDropOverlay(true)}
   	dropTextStyles={styles.attachmentDropText}
   	dashedBorderStyles={styles.activeDropzoneDashedBorder(theme.attachmentDropBorderColorActive, true)}
   	/>
   	</DragAndDropConsumer>
   	)}
   	</>

   <DragAndDropConsumer onDrop={shouldDisplayDualDropZone ? undefined : handleAttachmentDrop}>
      {shouldDisplayDualDropZone ? <DualDropZone ... /> : <DropZoneUI ... />}
    </DragAndDropConsumer>

5. Scope DualDropZone with its own Provider. Wrap DualDropZone in an inner DragAndDropProvider so its drops are handled in that scope and don't reach the outer provider. More complex, but isolates behavior cleanly.

Result

[melvin-bot]

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

[melvin-bot]

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

[jliexpensify]

cc @jasperhuangg in case you want to be assigned as the Engineer?

[cosmicvulpes]

Proposal

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

When a user drops a receipt onto the Scan Receipts drop-zone in a room chat, the app shows two UI elements:

1. The expected Start IOU – Scan Receipt right-hand panel (RHP) and
2. An unintended Send Attachment preview modal.
   Only the IOU RHP should appear.

What is the root cause of that problem?

DragAndDropConsumer registers the drop handler for the active composer via React context, but it never clears that handler when the component unmounts.
The bug appears right after the composer switches from a single drop-zone (only “Add attachments”) to the dual drop-zone (adds “Scan receipts” after another member joins the room).
The single-dropzone consumer registers an attachment onDrop handler; when the UI re-renders with the dual drop-zone that consumer unmounts—or re-mounts without an onDrop—but its previous handler remains in the Provider ref. Dropping a receipt now triggers two handlers: the intended scan-receipt handler and the stale attachment handler, producing the extra modal.

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

Clear stale drop handlers – Update DragAndDropConsumer so it unregisters its onDrop callback on unmount. This guarantees that once a screen is dismissed, its handler cannot accidentally fire in any subsequent screen.

Setting it as no-op is sufficient, minimal and clean solution.

// src/components/DragAndDrop/Consumer/index.tsx
useEffect(() => {
...
    setOnDropHandler?.(onDrop); //<-- registers handler for this consumer
    return () => {
        // Reset to a no-op so no stale handler can fire after navigation
        setOnDropHandler?.(() => {});
    };
...

Note for reviewers: The already-proposed approach focuses on suppressing the drop event locally.
This proposal removes the underlying stale handler, preventing the issue across all screens while keeping current drag-and-drop behaviour unchanged.

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

None

What alternative solutions did you explore? (Optional)

None