[$250] Web - Scan - Unable drop image file to upload receipt zone in the first time create scan expense

[jponikarchuk]

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: v9.3.2-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-2966/folder/13177085/41237993/1125947174
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Win 11/Chrome
App Component: Money Requests

Action Performed:

1. Open https://staging.new.expensify.com login with new account
2. Create a workspace
3. Navigate to workspace chat and click Create expense
4. Try to drag an image file from your local machine and drop it to upload receipt zone
5. Close RHP and click on Create expense
6. Drag an image file and drop it to upload receipt zone

Expected Result:

At step 4, user can drop image file to the upload receipt zone

Actual Result:

At step 4, red circle with a cross appearing, user can't drop image file to upload receipt zone. Close RHP and create expense again, user can drop it to upload receipt zone.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022011846415443579458
• Upwork Job ID: 2011846415443579458
• Last Price Increase: 2026-01-15

Issue Owner

Current Issue Owner: @brunovjk

[melvin-bot]

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

[daledah]

Proposal

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

When a user with a new account creates their first expense and tries to drag and drop an image file to the upload receipt zone, a red circle with a cross appears indicating the drop is not allowed. However, if they close the RHP and try again, drag and drop works correctly.

What is the root cause of that problem?

The root cause is in IOURequestStartPage.tsx. The DragAndDropProvider is disabled based on the selectedTab state:

App/src/pages/iou/request/IOURequestStartPage.tsx

Line 274 in 0bf4e1b

<DragAndDropProvider isDisabled={selectedTab !== CONST.TAB_REQUEST.SCAN}>

The issue is:

1. selectedTab is initialized from lastSelectedTab which comes from Onyx
2. For a new account, lastSelectedTab doesn't exist in Onyx yet, so it's undefined
3. The condition isDisabled={selectedTab !== CONST.TAB_REQUEST.SCAN} evaluates to true when selectedTab is undefined
4. So the DragAndDropProvider is disabled on first render
5. The tab navigator still displays the Scan tab (via defaultSelectedTab), but the provider doesn't know about this

App/src/pages/iou/request/IOURequestStartPage.tsx

Line 79 in 0bf4e1b

const [selectedTab, setSelectedTab] = useState(lastSelectedTab);

The second time it works because after the first visit, the selected tab is saved to Onyx, so lastSelectedTab is no longer undefined.

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

Use defaultSelectedTab as a fallback when selectedTab is undefined:

// src/pages/iou/request/IOURequestStartPage.tsx

- <DragAndDropProvider isDisabled={selectedTab !== CONST.TAB_REQUEST.SCAN}>
+ <DragAndDropProvider isDisabled={(selectedTab ?? defaultSelectedTab) !== CONST.TAB_REQUEST.SCAN}>

This ensures the drag and drop provider is enabled when the Scan tab is the default selected tab, even before the selectedTab state is initialized from Onyx.

note: we can do the same with other places that have the same problem

What alternative solutions did you explore? (Optional)

[yatin-italy]

Proposal

Restate the problem this issue is trying to solve.

• For new users, the first drop does not work.
• The UI shows the Scan tab.
• The provider thinks Scan is inactive.
• The first drag and drop is blocked.

What is the root cause of that problem?

• selectedTab is undefined on first render.
• Onyx has not loaded lastSelectedTab yet.
• isDisabled reads selectedTab directly.
• This marks Scan as inactive by mistake.

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

• Use the effective tab with fallbacks.
• Do not rely on selectedTab alone.
• Keep the change local to the provider.
• Do not add new state or persistence.

// Fallback keeps drag/drop enabled on Scan for first-time users before lastSelectedTab hydrates
<DragAndDropProvider
    isDisabled={(selectedTab ?? defaultSelectedTab ?? CONST.TAB_REQUEST.SCAN) !== CONST.TAB_REQUEST.SCAN}
>
    {/* existing children */}
</DragAndDropProvider>

[joekaufmanexpensify]

Reproduced!

[melvin-bot]

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

[melvin-bot]

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

[Eskalifer1]

🚨 Edited by proposal-police: This proposal was edited at 2026-01-15 20:14:16 UTC.

Proposal

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

Web - Scan - Unable drop image file to upload receipt zone in the first time create scan expense

What is the root cause of that problem?

Previously, we didn't have a state like selectedTab, and we only worked with lastSelectedTab:

App/src/pages/iou/request/IOURequestStartPage.tsx

Lines 78 to 79 in a38325f

	const [lastSelectedTab, selectedTabResult] = useOnyx(`${ONYXKEYS.COLLECTION.SELECTED_TAB}${CONST.TAB.IOU_REQUEST_TYPE}`, {canBeMissing: true});
	const [selectedTab, setSelectedTab] = useState(lastSelectedTab);

But the problem is that now this useState is initialized with the value lastSelectedTab, and for new accounts or after clearing the cache, this value is undefined, and although the correct tab is displayed, because of this line:

App/src/pages/iou/request/IOURequestStartPage.tsx

Line 289 in a38325f

defaultSelectedTab={defaultSelectedTab}

But the component itself has a lot of logic tied to the selected tab, such as this Drag&Drop task or other examples where the tab type is checked:

App/src/pages/iou/request/IOURequestStartPage.tsx

Line 239 in a38325f

selectedTab === CONST.TAB_REQUEST.SCAN &&

App/src/pages/iou/request/IOURequestStartPage.tsx

Line 128 in a38325f

if (selectedTab === CONST.TAB_REQUEST.PER_DIEM && !shouldShowPerDiemOption) {

And potentially this bug could be anywhere.

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

Since the value can be either undefined because it is missing, or undefined because isLoadingSelectedTab has a value of true, you need to add a fix for both of these cases:

1. Add a fallback value here:
   

   App/src/pages/iou/request/IOURequestStartPage.tsx

   Line 79 in a38325f

   const [selectedTab, setSelectedTab] = useState(lastSelectedTab);

const [selectedTab, setSelectedTab] = useState(lastSelectedTab ?? defaultSelectedTab);

This will fix the error when there is no value in Onyx at all, but now we always have a value in selectedTab, which means that this useEffect will not perform its function, since there is a check for selectedTab here:

App/src/pages/iou/request/IOURequestStartPage.tsx

Lines 147 to 154 in a38325f

	useEffect(() => {
	if (isLoadingSelectedTab || selectedTab) {
	return;
	}
	setSelectedTab(lastSelectedTab);
	// We only want to set the selected tab when selectedTab is not set yet, don't want to run this effect again when lastSelectedTab changes
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [isLoadingSelectedTab, selectedTab]);

I think we can refactor the code (or just remove the check for || selectedTab), namely, leave this useEffect only for isLoadingSelectedTab. Here, we can also add a fallback to the default value:

    useEffect(() => {
        if (isLoadingSelectedTab) {
            return;
        }
        setSelectedTab(lastSelectedTab ?? defaultSelectedTab);
        // We only want to set the selected tab when selectedTab is not set yet, don't want to run this effect again when lastSelectedTab changes
        // eslint-disable-next-line react-hooks/exhaustive-deps
    }, [isLoadingSelectedTab]);

What alternative solutions did you explore? (Optional)

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.

[abbasifaizan70]

Proposal

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

When a user tries to drag and drop an image file to upload a receipt in the workspace chat after clicking "Create expense", the first attempt fails showing a red circle with a cross (indicating the drop is not allowed). However, if the user closes the RHP and clicks "Create expense" again, the drag and drop works successfully.

What is the root cause of that problem?

The root cause is in the useDragAndDrop hook which uses React Navigation's useIsFocused() hook to determine if drag and drop events should be accepted. When the RHP modal opens over the workspace chat, the underlying report screen loses navigation focus, causing isFocused to become false.

The problematic code:

App/src/hooks/useDragAndDrop/index.ts

Line 25 in 3852554

const isFocused = useIsFocused();

App/src/hooks/useDragAndDrop/index.ts

Lines 71 to 75 in 3852554

	const dropZoneDragHandler = useCallback(
	(event: DragEvent) => {
	if (!isFocused || isDisabled || !shouldAcceptDrop(event)) {
	return;
	}

In the dropZoneDragHandler function, when isFocused is false, the function returns early without processing the drag event. This causes the browser to use the default "not allowed" cursor (red circle with cross).

Where the drop effect is set:

App/src/hooks/useDragAndDrop/index.ts

Lines 44 to 66 in 3852554

	const handleDragEvent = useCallback(
	(event: DragEvent) => {
	if (!shouldHandleDragEvent) {
	return;
	}
	const shouldAcceptThisDrop = shouldAllowDrop && shouldAcceptDrop(event);
	if (shouldAcceptThisDrop && event.type === DRAG_ENTER_EVENT) {
	closePopover();
	}
	const effect = shouldAcceptThisDrop ? COPY_DROP_EFFECT : NONE_DROP_EFFECT;
	if (event.dataTransfer) {
	// eslint-disable-next-line no-param-reassign
	event.dataTransfer.dropEffect = effect;
	// eslint-disable-next-line no-param-reassign
	event.dataTransfer.effectAllowed = effect;
	}
	},
	[shouldHandleDragEvent, shouldAllowDrop, shouldAcceptDrop, closePopover],
	);

The handleDragEvent function sets the dropEffect to 'none' when the drop shouldn't be accepted (line 56), which displays the red circle with cross to the user.

Why it works on the second attempt:

After closing the RHP and clicking "Create expense" again, when the IOURequestStepScan page loads, it becomes the focused screen in React Navigation. Therefore isFocused becomes true and drag and drop events are properly handled.

The IOURequestStepScan component that uses drag and drop:

App/src/pages/iou/request/step/IOURequestStepScan/index.tsx

Lines 1123 to 1131 in 3852554

	<DragAndDropConsumer onDrop={handleDropReceipt}>
	<DropZoneUI
	icon={isReplacingReceipt ? lazyIcons.ReplaceReceipt : lazyIcons.SmartScan}
	dropStyles={styles.receiptDropOverlay(true)}
	dropTitle={isReplacingReceipt ? translate('dropzone.replaceReceipt') : translate(shouldAcceptMultipleFiles ? 'dropzone.scanReceipts' : 'quickAction.scanReceipt')}
	dropTextStyles={styles.receiptDropText}
	dashedBorderStyles={[styles.dropzoneArea, styles.easeInOpacityTransition, styles.activeDropzoneDashedBorder(theme.receiptDropBorderColorActive, true)]}
	/>
	</DragAndDropConsumer>

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

The issue occurs because the isFocused check is too strict for nested navigation scenarios where modals/RHP panels are opened. The drop zone in IOURequestStepScan should be able to accept drops even when it's rendered but the parent screen has lost navigation focus.

Solution: Add an override parameter to bypass isFocused check for nested screens

Modify the useDragAndDrop hook to accept an optional shouldIgnoreFocus parameter that allows certain components to accept drag and drop events regardless of the navigation focus state.

Implementation Steps:

1. Update the UseDragAndDrop type definition:

File: App/src/hooks/useDragAndDrop/types.ts

Add the new parameter to the type (around line 9):

type UseDragAndDropOptions = {
    dropZone: RefObject<HTMLDivElement | View>;
    onDrop?: (event: DragEvent) => void;
    shouldAllowDrop?: boolean;
    isDisabled?: boolean;
    shouldAcceptDrop?: (event: DragEvent) => boolean;
    shouldStopPropagation?: boolean;
    shouldHandleDragEvent?: boolean;
    shouldIgnoreFocus?: boolean; // Add this new parameter
};

2. Update the useDragAndDrop hook implementation:

File: App/src/hooks/useDragAndDrop/index.ts

Update the function signature and logic (line 16-24):

const useDragAndDrop: UseDragAndDrop = ({
    dropZone,
    onDrop = () => {},
    shouldAllowDrop = true,
    isDisabled = false,
    shouldAcceptDrop = () => true,
    shouldHandleDragEvent = true,
    shouldStopPropagation = true,
    shouldIgnoreFocus = false, // Add this with default false
}) => {

Update the focus check logic (line 32-42):

useEffect(() => {
    // If shouldIgnoreFocus is true, don't reset drag state based on focus
    if (shouldIgnoreFocus) {
        if (isDisabled) {
            setIsDraggingOver(false);
            dragCounter.current = 0;
            if (debounceTimeoutRef.current) {
                clearTimeout(debounceTimeoutRef.current);
                debounceTimeoutRef.current = null;
            }
        }
        return;
    }
    
    if (isFocused && !isDisabled) {
        return;
    }
    setIsDraggingOver(false);
    dragCounter.current = 0;
    if (debounceTimeoutRef.current) {
        clearTimeout(debounceTimeoutRef.current);
        debounceTimeoutRef.current = null;
    }
}, [isFocused, isDisabled, shouldIgnoreFocus]);

Update the dropZoneDragHandler callback (line 71-75):

const dropZoneDragHandler = useCallback(
    (event: DragEvent) => {
        // Allow processing if shouldIgnoreFocus is true
        if ((!shouldIgnoreFocus && !isFocused) || isDisabled || !shouldAcceptDrop(event)) {
            return;
        }
        // ... rest of the function

Also update the dependencies array (line 118):

[isFocused, isDisabled, shouldAcceptDrop, shouldStopPropagation, handleDragEvent, isDraggingOver, onDrop, shouldIgnoreFocus],

3. Update IOURequestStepScan to use the new parameter:

File: App/src/pages/iou/request/step/IOURequestStepScan/index.tsx

Find where DragAndDropConsumer is used with the drop handler (around line 1123) and update the component to pass shouldIgnoreFocus={true} if the DragAndDropConsumer accepts it, OR update ReceiptDropUI to pass this prop.

Actually, looking at the code structure, the DragAndDropConsumer uses context from DragAndDropProvider. We need to check if there's a better place to set this.

Alternative approach - Update DropZoneWrapper:

File: App/src/components/DropZone/DropZoneWrapper.tsx

Add shouldIgnoreFocus prop and pass it to useDragAndDrop:

type DropZoneWrapperProps = {
    onDrop: (event: DragEvent) => void;
    children: (props: {isDraggingOver: boolean}) => ReactNode;
    shouldIgnoreFocus?: boolean;
};

function DropZoneWrapper({onDrop, children, shouldIgnoreFocus = false}: 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),
        shouldIgnoreFocus, // Pass the prop here
    });
    // ... rest of the component
}

Then update StepScreenDragAndDropWrapper or the specific usage in IOURequestStepScan to pass shouldIgnoreFocus={true}.

What alternative solutions did you explore? (Optional)

Alternative 1: Remove the isFocused check entirely

We could remove the isFocused check from useDragAndDrop entirely. However, this might cause issues where drag and drop remains active on screens that are not visible or have been navigated away from, potentially causing unexpected behavior.

Alternative 2: Use modal visibility state instead of navigation focus

Instead of relying on React Navigation's useIsFocused(), we could check if the specific screen/component is actually visible on screen using a different mechanism. However, this would be more complex and harder to maintain.

Alternative 3: Keep drag state active for child screens in the navigation stack

We could modify the focus check to allow drag and drop when the screen is either focused OR when it's a parent screen of the currently focused screen (i.e., it's visible underneath a modal/RHP). This would require accessing the navigation state to determine the hierarchy.

Demo

Screen.Recording.2026-01-16.at.4.19.19.AM.mov