[$250] Receipt hover preview zoom opens on the wrong side of the thumbnail

[m-natarajan]

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.33-1
Reproducible in staging?: Y
Reproducible in production?: Y
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: @shawnborton
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Navigate to Spend > Expenses
2. Ensure the left sidebar is expanded
3. Hover over a receipt thumbnail of an expense
4. Observe the position of the zoom preview

Expected Result:

The receipt hover preview should open to the left of the receipt thumbnail when the sidebar is expanded.
The preview should only open to the right when:
The user is on the Home page, or
The left sidebar is collapsed.

Actual Result:

The receipt hover preview opens to the right of the receipt thumbnail even when the sidebar is expanded and the user is not on the Home page.

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

Recording.3189.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022076723313520196592
• Upwork Job ID: 2076723313520196592
• Last Price Increase: 2026-07-13

[MelvinBot]

⚠️ Something went wrong. This may be a transient issue — try again. If it persists, check status.anthropic.com.

Run details

[MelvinBot]

Proposal

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

The receipt hover preview always opens to the right of the thumbnail. It should open to the left when the left navigation sidebar is expanded (and not on Home), and only open right on Home or when the sidebar is collapsed.

What is the root cause of that problem?

The side is decided solely by a "does it overflow the right edge of the full window" check — there is no concept of the sidebar or the current page.

In getAnchoredPreviewPosition.ts:31-33, the preview defaults to the right of the thumbnail and only flips left if rightOfThumbnail + RECEIPT_PREVIEW_WIDTH + margin > windowWidth. Since windowWidth is the full viewport width (index.tsx:58) and the thumbnails live in the content pane, there is almost always room on the right — so it opens right in virtually every case, regardless of sidebar state.

Investigation details

• Side logic lives only at getAnchoredPreviewPosition.ts:31-33. Default = right; flip-left only on right-edge overflow. No sidebar / Home branch exists.
• windowWidth comes from useWindowDimensions() (index.tsx:58) and is the whole browser width — not adjusted for the sidebar. The anchor is measured with measureInWindow (absolute window coords) at ReceiptCell.tsx:59, so the overflow math never accounts for the space the expanded sidebar occupies on the left.
• shouldUseNarrowLayout is available in the component (index.tsx:56) but only gates whether the preview renders — it is not forwarded to the positioning function.
• Note: src/components/ReceiptHoverZoom/ is a different feature (an in-place CSS magnifier in the RHP receipt view) and has no side logic — it is not the cause here.

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

Pass a "prefer left" signal into the positioning function and default to the left side when the sidebar is expanded and we're not on Home:

1. In ReceiptPreview/index.tsx, compute shouldOpenLeft = <sidebar expanded> && <not on Home> and pass it to getAnchoredPreviewPosition. The layout signal is already available (!shouldUseNarrowLayout / isLargeScreenWidth); Home detection needs a navigation route check (e.g. against SCREENS.HOME).
2. In getAnchoredPreviewPosition.ts:31-33, add a preferLeft param: when true, default to the left placement (anchorPosition.left - RECEIPT_PREVIEW_WIDTH - RECEIPT_PREVIEW_GAP, clamped to the edge margin) and only fall back to the right if the left placement would go off-screen (mirror the current overflow logic for the left edge). When false, keep today's right-default behavior.

The exact selectors for "sidebar expanded" and "on Home" should be confirmed against product intent before implementing.

Confidence: High for the root cause (code path fully traced); Medium on the precise selectors for "sidebar expanded"/"Home" since those depend on product intent.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95975) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

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

On web, hovering a receipt thumbnail in Spend > Expenses opens the zoomed receipt preview to the right of the thumbnail, covering the row's merchant/amount columns, even when the expanded left sidebar leaves plenty of dead space to the left. Per design, the preview should open to the left of the thumbnail whenever the sidebar is expanded, and only open to the right on the Home page or when the sidebar is collapsed.

What is the root cause of that problem?

The preview is a document.body portal whose position is computed purely from the hovered cell's window coordinates. On mouse-enter, ReceiptCell.handleMouseEnter measures the cell with measureInWindow and passes the result as anchorPosition to ReceiptPreview, which feeds it to getAnchoredPreviewPosition in src/components/TransactionItemRow/ReceiptPreview/getAnchoredPreviewPosition.ts:

App/src/components/TransactionItemRow/DataCells/ReceiptCell.tsx

Lines 55 to 59 in af11be2

	const handleMouseEnter = () => {
	if (!shouldMountPreview) {
	setShouldMountPreview(true);
	}
	cellRef.current?.measureInWindow((left, top, width, height) => setPreviewAnchor({left, top, width, height}));

That function hard-codes a right-first placement policy. It anchors the preview at anchorPosition.left + anchorPosition.width + RECEIPT_PREVIEW_GAP and only flips to the left side when the preview would overflow the right viewport edge:

App/src/components/TransactionItemRow/ReceiptPreview/getAnchoredPreviewPosition.ts

Lines 31 to 33 in af11be2

	const rightOfThumbnail = anchorPosition.left + anchorPosition.width + RECEIPT_PREVIEW_GAP;
	const overflowsRight = windowWidth > 0 && rightOfThumbnail + RECEIPT_PREVIEW_WIDTH + RECEIPT_PREVIEW_EDGE_MARGIN > windowWidth;
	const left = overflowsRight ? Math.max(RECEIPT_PREVIEW_EDGE_MARGIN, anchorPosition.left - RECEIPT_PREVIEW_WIDTH - RECEIPT_PREVIEW_GAP) : rightOfThumbnail;

const overflowsRight = windowWidth > 0 && rightOfThumbnail + RECEIPT_PREVIEW_WIDTH + RECEIPT_PREVIEW_EDGE_MARGIN > windowWidth;
const left = overflowsRight ? Math.max(RECEIPT_PREVIEW_EDGE_MARGIN, anchorPosition.left - RECEIPT_PREVIEW_WIDTH - RECEIPT_PREVIEW_GAP) : rightOfThumbnail;

In the Spend > Expenses table the receipt is the leftmost data column, so at any normal window width there are hundreds of pixels of table to its right, overflowsRight is always false, and the preview always opens to the right on top of the row's data. Nothing in the function or its callers reflects the sidebar state — the design rule "left when the sidebar is expanded, right on Home or when collapsed" has no representation in the code. The key observation is that the left-side room the design refers to is exactly the room the sidebar creates: with the sidebar expanded, the thumbnail sits roughly navigationTabBarSize (72) + searchSidebarExpandedWidth (320) + the list's mh5 margin plus the checkbox column, about 450px from the viewport edge, which is enough for the 380px preview (variables.receiptPreviewWidth) plus the 16px gap and 24px edge margin (420px total). With the sidebar collapsed (searchSidebarCollapsedWidth = 76) the thumbnail sits around 200px, and on the Home page the Recently added card starts at ~92px (72px tab bar + homePageContentContainer's 20px padding, left column pinned left even on wide monitors), so in both of those cases the preview cannot fit on the left and the right side is the correct placement.

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

Make getAnchoredPreviewPosition prefer the left side whenever the preview fully fits between the viewport's left margin and the thumbnail, keeping the existing right-overflow flip as the fallback:

const leftOfThumbnail = anchorPosition.left - RECEIPT_PREVIEW_WIDTH - RECEIPT_PREVIEW_GAP;
const fitsLeft = leftOfThumbnail >= RECEIPT_PREVIEW_EDGE_MARGIN;
const rightOfThumbnail = anchorPosition.left + anchorPosition.width + RECEIPT_PREVIEW_GAP;
const overflowsRight = windowWidth > 0 && rightOfThumbnail + RECEIPT_PREVIEW_WIDTH + RECEIPT_PREVIEW_EDGE_MARGIN > windowWidth;
const left = fitsLeft || overflowsRight ? Math.max(RECEIPT_PREVIEW_EDGE_MARGIN, leftOfThumbnail) : rightOfThumbnail;

This reproduces the design spec in every named scenario because the geometry encodes the sidebar state: expanded sidebar (~450px anchor) fits left so the preview opens over the sidebar with the same 16px gap it currently keeps on the right; collapsed sidebar (~200px) and Home (~105px) don't fit, so those keep opening right. Because ReceiptCell re-measures the anchor on every mouse-enter, the decision automatically tracks sidebar collapse/expand toggles, peeking, and window resizes with no extra state. Other callers are unaffected or already behave this way: the RHP flows that render TransactionItemRow (merge, duplicates, unreported expenses) anchor near the right viewport edge, where overflowsRight already flips them left and the new branch yields the identical Math.max coordinates, and the report-table rows in Reports sit right of the same expanded sidebar, so opening left there is consistent with the design rationale of not covering row data. The vertical clamping logic and native platforms (index.native.tsx returns null) are untouched. The existing unit suite tests/unit/components/ReceiptPreviewPositionTest.ts covers this function, so we update the right-placement expectations to use anchors without left room and add cases asserting the left-preferred placement when the anchor is at least RECEIPT_PREVIEW_WIDTH + RECEIPT_PREVIEW_GAP + RECEIPT_PREVIEW_EDGE_MARGIN from the edge.

What alternative solutions did you explore? (Optional)

We considered plumbing the real sidebar state (useSearchSidebarCollapse, backed by NVP_SEARCH_SIDEBAR) down through TransactionItemRow → ReceiptCell → ReceiptPreview as an explicit side preference, but rejected it: the NVP is global while the search sidebar only exists on Search fullscreen screens, so Home and RHP contexts would wrongly prefer left whenever the NVP reads "expanded", and it would touch a long prop chain across many call sites, whereas the measured anchor already encodes exactly the room the sidebar creates.

[aswin-s]

Proposal

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

On web (Windows/macOS Chrome & Safari), when hovering a receipt thumbnail in Spend > Expenses with the left sidebar expanded, the zoom preview opens to the right of the thumbnail. Expected: the preview should open to the left whenever the user is not on the Home page and the sidebar is expanded, and only open to the right on the Home page or when the sidebar is collapsed.

What is the root cause of that problem?

getAnchoredPreviewPosition (src/components/TransactionItemRow/ReceiptPreview/getAnchoredPreviewPosition.ts:31-33) decides side purely from geometric overflow of the right viewport edge: it defaults to rightOfThumbnail and only flips to the left when rightOfThumbnail + RECEIPT_PREVIEW_WIDTH + RECEIPT_PREVIEW_EDGE_MARGIN > windowWidth. It never consults the Search sidebar state (useSearchSidebarCollapse / NVP_SEARCH_SIDEBAR from src/components/Navigation/SearchSidebarCollapseStore.ts) or the current route. ReceiptCell.tsx:107-114 (the consumer that renders ReceiptPreview) also never passes any sidebar/route hint. So on wide viewports on the Expenses page, even with the sidebar expanded, there is still room to the right and the preview stays on the right — the wrong side per the spec.

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

1. In src/components/TransactionItemRow/ReceiptPreview/index.tsx, read the sidebar-collapsed flag via useSearchSidebarCollapse() and derive isOnHome from the current route (e.g. via useNavigationState / Navigation.getActiveRoute() matched against the Home screen constant). Pass a preferLeft = !isOnHome && !isCollapsed down to getAnchoredPreviewPosition.
2. In src/components/TransactionItemRow/ReceiptPreview/getAnchoredPreviewPosition.ts:26-33, accept the new preferLeft argument. When preferLeft is true, compute leftOfThumbnail = anchorPosition.left - RECEIPT_PREVIEW_WIDTH - RECEIPT_PREVIEW_GAP first and use it if leftOfThumbnail >= RECEIPT_PREVIEW_EDGE_MARGIN; otherwise fall back to the current right-side placement. Keep the existing right-overflow flip as the fallback path so behavior on Home / collapsed-sidebar is unchanged.
3. Keep the min-visible-height and bottom-clamp logic (getAnchoredPreviewPosition.ts:36-45) untouched — this change is horizontal-only.
4. No native change required: ReceiptPreview/index.native.tsx is a no-op stub for this preview (hover doesn't apply), so leave it as-is.
5. Add a unit test alongside getAnchoredPreviewPosition.ts covering: (a) preferLeft=true with room on the left → left; (b) preferLeft=true with no room on the left → right; (c) preferLeft=false → current behavior preserved.

What alternative solutions did you explore? (Optional)

[ahmdshrif]

Proposal

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

On wide-screen web, the receipt hover preview always opens to the right of the thumbnail. Per design it should open to the left when the left sidebar is expanded (over the sidebar instead of covering the row's data), and open right only on the Home page or when the sidebar is collapsed.

What is the root cause of that problem?

The side of the preview is decided by a single function, and the only input it considers is right-viewport overflow. Neither the sidebar's expansion state nor the current page ever enters the computation.

1. On mouse-enter, ReceiptCell measures the hovered cell's window position and passes it as anchorPosition to the portal-rendered preview:

   App/src/components/TransactionItemRow/DataCells/ReceiptCell.tsx

   Lines 55 to 61 in af11be2

   	const handleMouseEnter = () => {
   	if (!shouldMountPreview) {
   	setShouldMountPreview(true);
   	}
   	cellRef.current?.measureInWindow((left, top, width, height) => setPreviewAnchor({left, top, width, height}));
   	bind.onMouseEnter();
   	};

2. ReceiptPreview converts that anchor to a position via getAnchoredPreviewPosition:

   App/src/components/TransactionItemRow/ReceiptPreview/index.tsx

   Line 127 in af11be2

   const anchoredPositionStyle = getAnchoredPreviewPosition(anchorPosition, windowWidth, windowHeight, previewHeight);

3. That function hard-codes "right of the thumbnail, unless the preview would overflow the right viewport edge":

   App/src/components/TransactionItemRow/ReceiptPreview/getAnchoredPreviewPosition.ts

   Lines 31 to 33 in af11be2

   	const rightOfThumbnail = anchorPosition.left + anchorPosition.width + RECEIPT_PREVIEW_GAP;
   	const overflowsRight = windowWidth > 0 && rightOfThumbnail + RECEIPT_PREVIEW_WIDTH + RECEIPT_PREVIEW_EDGE_MARGIN > windowWidth;
   	const left = overflowsRight ? Math.max(RECEIPT_PREVIEW_EDGE_MARGIN, anchorPosition.left - RECEIPT_PREVIEW_WIDTH - RECEIPT_PREVIEW_GAP) : rightOfThumbnail;

4. Substituting the repro into that gate: Spend > Expenses on a ~1600px window, sidebar expanded (320px, variables.searchSidebarExpandedWidth), thumbnail cell at left ≈ 340: overflowsRight = 340 + 28 + 16 + 380 + 24 = 788 > 1600 is false, so the preview opens right every time — exactly the reported behavior.
5. Structural cause: PR [Home Page] Design Followup for Recently Added Slot #95056`` introduced row-anchored previews with a viewport-overflow-only heuristic; the design rule "prefer the space over the expanded sidebar" was never encoded, even though the expansion state already exists in NVP_SEARCH_SIDEBAR, read by `useSearchSidebarCollapse`:

   App/src/components/Navigation/SearchSidebarCollapseStore.ts

   Lines 72 to 87 in af11be2

   	function useSearchSidebarCollapse() {
   	const [searchSidebarNVP] = useOnyx(ONYXKEYS.NVP_SEARCH_SIDEBAR);
   	const collapsed = searchSidebarNVP?.isCollapsed ?? false;
   	const peeking = useSyncExternalStore(subscribe, getPeekSnapshot, getPeekSnapshot);
   	const toggleSidebar = useCallback(() => setSearchSidebarCollapsed(!collapsed), [collapsed]);
   	const startSidebarPeek = useCallback(() => startPeek(collapsed), [collapsed]);
   	return {
   	isCollapsed: collapsed,
   	isPeeking: peeking,
   	isVisuallyCollapsed: collapsed && !peeking,
   	toggleSidebar,
   	startPeek: startSidebarPeek,
   	endPeek,
   	};
   	}

Every surface funnels through this one function, so the affected paths are:

• Search table rows (Spend > Expenses):

  App/src/components/TransactionItemRow/TransactionItemRowWide.tsx

  Line 171 in af11be2

  <ReceiptCell

  — should flip left when the sidebar is expanded.
• The single-report transaction table under Reports lives in the same SEARCH_FULLSCREEN_NAVIGATOR, whose sidebar is mounted as ExtraContent:

  App/src/libs/Navigation/AppNavigator/createSearchFullscreenNavigator/index.tsx

  Line 28 in af11be2

  ExtraContent: SearchSidebar,

  — should also flip left.
• Home page recently-added rows use the same cell:

  App/src/pages/home/RecentlyAddedSection/RecentlyAddedRow.tsx

  Line 65 in af11be2

  <ReceiptCell

  — must stay right (Home is registered in TabNavigator, not the search navigator).
• Narrow layout is unaffected (preview returns null:

  App/src/components/TransactionItemRow/ReceiptPreview/index.tsx

  Line 119 in af11be2

  if (shouldUseNarrowLayout || !debounceShouldShow || !shouldShow || (!source && !isEReceipt && !isDistanceEReceipt && !isPerDiemEReceipt)) {

  ), and native is a null stub (ReceiptPreview/index.native.tsx).

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

Decide the side at the single convergence point, using "an expanded search sidebar is actually on screen" — i.e. the topmost fullscreen route is the search navigator AND the sidebar NVP is not collapsed. In ReceiptPreview/index.tsx (the web-only file, so no native impact):

const {isCollapsed} = useSearchSidebarCollapse();
const isOnSearchRoute = useRootNavigationState(() => isSearchTopmostFullScreenRoute());
const shouldOpenLeft = !!isOnSearchRoute && !isCollapsed;

using

App/src/libs/Navigation/helpers/isSearchTopmostFullScreenRoute.ts

Lines 5 to 11 in af11be2

	const isSearchTopmostFullScreenRoute = (): boolean => {
	const topmostFullScreenRoute = getTopmostFullScreenRoute();
	if (!topmostFullScreenRoute) {
	return false;
	}
	return topmostFullScreenRoute.name === NAVIGATORS.SEARCH_FULLSCREEN_NAVIGATOR;
	};

, then pass it as a new optional last parameter to getAnchoredPreviewPosition and extend the side choice, reusing the left-side clamp that already exists for the overflow flip:

const left = shouldOpenLeft || overflowsRight
    ? Math.max(RECEIPT_PREVIEW_EDGE_MARGIN, anchorPosition.left - RECEIPT_PREVIEW_WIDTH - RECEIPT_PREVIEW_GAP)
    : rightOfThumbnail;

Since the preview (380px, variables.receiptPreviewWidth) is wider than the expanded sidebar (320px), the existing Math.max clamp keeps it at the 24px edge margin over the sidebar — the same geometry the right-edge flip uses today; no new positioning code. Extend tests/unit/components/ReceiptPreviewPositionTest.ts with cases for the new parameter. Regression safety: the parameter defaults to false, so Home, collapsed-sidebar, RHP, and the existing right-edge-overflow flip keep identical output, and top/bottom clamping is untouched.

Why the obvious spot fix does not work: the tempting geometric one-liner — "open left when the preview fits to the left of the anchor" — fails in the exact repro, because the preview needs 396px (380 + 16 gap) but the expanded sidebar only pushes the anchor ~340px from the edge, so "fits left" stays false and the preview still opens right; and on Home, wide monitors give the centered layout enough left gutter to flip it left there, violating the "right on Home" requirement. Gating on useSearchSidebarCollapse().isCollapsed alone also breaks Home, since that persisted NVP still reads isCollapsed: false while you are on Home. The route check is what separates the cases, because the sidebar is only mounted as the search navigator's ExtraContent.

What alternative solutions did you explore? (Optional)

1. Thread a shouldOpenPreviewOnLeft prop from each page down through TransactionItemRowWide/Narrow → ReceiptCell → ReceiptPreview: works, but touches every row consumer for no gain over the centralized check.
2. Pure geometry ("open left whenever there is room on the left"): fails both ways — it misses the Home-stays-right requirement, and in the actual repro it never fires (see above).
3. Compare anchorPosition.left >= searchSidebarExpandedWidth: false-positives on Home/wide screens; the route + NVP state is unambiguous.

[melvin-bot]

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

[wildan-m]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-13 17:53:49 UTC.

Proposal

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

On Spend > Expenses, hovering a receipt thumbnail always opens the zoom preview to the right of the thumbnail, even when the left sidebar is expanded. The preview should open to the left of the thumbnail when the sidebar is expanded, and only open to the right when the user is on the Home page or the sidebar is collapsed.

What is the root cause of that problem?

The side the preview opens on is decided in one place, getAnchoredPreviewPosition, and it is decided purely from viewport overflow — it has no knowledge of the sidebar, the layout, or which page the row is on:

App/src/components/TransactionItemRow/ReceiptPreview/getAnchoredPreviewPosition.ts

Lines 26 to 33 in eebed90

	function getAnchoredPreviewPosition(anchorPosition: AnchorPosition | undefined, windowWidth: number, windowHeight: number, previewHeight = 0) {
	if (!anchorPosition) {
	return undefined;
	}
	const rightOfThumbnail = anchorPosition.left + anchorPosition.width + RECEIPT_PREVIEW_GAP;
	const overflowsRight = windowWidth > 0 && rightOfThumbnail + RECEIPT_PREVIEW_WIDTH + RECEIPT_PREVIEW_EDGE_MARGIN > windowWidth;
	const left = overflowsRight ? Math.max(RECEIPT_PREVIEW_EDGE_MARGIN, anchorPosition.left - RECEIPT_PREVIEW_WIDTH - RECEIPT_PREVIEW_GAP) : rightOfThumbnail;

It computes rightOfThumbnail (the thumbnail's right edge plus a gap) and places the preview there. It only flips to the left when the 380px-wide preview plus the 24px edge margin would not fit inside windowWidth to the right of the thumbnail. In other words: right is the default and left is only ever an overflow fallback.

On the Expenses table the receipt column is near the left of the content area, so there is always plenty of room on the right. overflowsRight is therefore false and the preview is always placed to the right — regardless of whether the sidebar is expanded — which is exactly the reported behavior. It then covers the expense row's own data, which is the content the user is looking at.

The caller passes only geometry, so no sidebar/page signal ever reaches the positioning helper:

App/src/components/TransactionItemRow/ReceiptPreview/index.tsx

Line 127 in eebed90

const anchoredPositionStyle = getAnchoredPreviewPosition(anchorPosition, windowWidth, windowHeight, previewHeight);

Meanwhile the app already knows whether the Search sidebar is expanded — that state lives in useSearchSidebarCollapse, backed by the nvp_searchSidebar Onyx value — but neither ReceiptCell nor ReceiptPreview nor getAnchoredPreviewPosition consumes it:

App/src/components/Navigation/SearchSidebarCollapseStore.ts

Lines 72 to 87 in eebed90

	function useSearchSidebarCollapse() {
	const [searchSidebarNVP] = useOnyx(ONYXKEYS.NVP_SEARCH_SIDEBAR);
	const collapsed = searchSidebarNVP?.isCollapsed ?? false;
	const peeking = useSyncExternalStore(subscribe, getPeekSnapshot, getPeekSnapshot);
	const toggleSidebar = useCallback(() => setSearchSidebarCollapsed(!collapsed), [collapsed]);
	const startSidebarPeek = useCallback(() => startPeek(collapsed), [collapsed]);
	return {
	isCollapsed: collapsed,
	isPeeking: peeking,
	isVisuallyCollapsed: collapsed && !peeking,
	toggleSidebar,
	startPeek: startSidebarPeek,
	endPeek,
	};
	}

So the missing piece is not the geometry maths — the vertical clamping and the overflow fallback are both fine — it is that the horizontal side is never allowed to be a preference, only an overflow escape hatch.

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

Make the preferred side an input to the positioning helper, and derive that preference from the sidebar state on the Expenses table only.

1. Give getAnchoredPreviewPosition a "prefer the left side" input. Add a boolean parameter alongside the existing anchor/window/height arguments. When it is true, first compute the left-hand placement (the thumbnail's left edge minus the preview width minus the gap) and use it only if that position still clears the viewport edge margin — i.e. only if the preview genuinely fits on the left without being clamped on top of the thumbnail. If it does not fit, fall back to the current behavior unchanged (right of the thumbnail, flipping left on overflow). Keep all the vertical logic exactly as it is. This keeps the helper safe by construction: preferring the left can never produce a preview that overlaps the row or runs off the screen — in the worst case it degrades to today's placement.

2. Derive the preference from the expanded sidebar and thread it down. Read the existing sidebar state from useSearchSidebarCollapse in the Expenses table row and pass "sidebar is expanded" (its isVisuallyCollapsed value, inverted — so a sidebar that is only temporarily peeking is still treated as collapsed) through TransactionItemRow → ReceiptCell → ReceiptPreview → getAnchoredPreviewPosition. ReceiptCell already accepts optional presentation props such as shouldShowPreview, so this is one more optional prop in the same style, defaulting to false. Both Expenses rows opt in — the flat table row and the expanded-group row — so grouping the table doesn't change which side the preview opens on.

App/src/components/TransactionItemRow/DataCells/ReceiptCell.tsx

Lines 107 to 114 in eebed90

	{shouldMountPreview && (
	<ReceiptPreview
	source={previewSource}
	hovered={hovered && shouldShowPreview}
	isEReceipt={!!isEReceipt}
	transactionItem={transactionItem}
	anchorPosition={previewAnchor}
	/>

3. Leave the Home page on the default. The Home page renders the same cell through RecentlyAddedRow, which simply does not pass the new prop — so it keeps false and keeps opening to the right, as expected:

App/src/pages/home/RecentlyAddedSection/RecentlyAddedRow.tsx

Lines 64 to 71 in eebed90

	const thumbnail = (
	<ReceiptCell
	transactionItem={expense.transaction}
	isSelected={false}
	shouldUseNarrowLayout={shouldUseNarrowLayout}
	shouldShowPreview={shouldShowReceiptPreview}
	/>
	);

This yields exactly the three behaviors described in the issue: sidebar expanded on Expenses → preview opens left, over the sidebar, leaving the expense row readable; sidebar collapsed → the left placement no longer clears the edge margin, so it falls back to the right; Home page → unchanged, opens right.

The existing unit tests in tests/unit/components/ReceiptPreviewPositionTest.ts continue to pass unchanged (they exercise the default, non-preferring path), and the new preference is covered by added cases: left when the sidebar is expanded and there is room, the fallback to the right when there is not, and the vertical placement staying untouched.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/95975-receipt-preview-prefers-left-when-sidebar-expanded?expand=1

What alternative solutions did you explore? (Optional)

Decide the side purely from geometry — always prefer the left whenever the thumbnail sits far enough from the viewport's left edge for the preview to fit. This needs no new prop and no sidebar state, but it is fragile: whether it picks the correct side depends on incidental table/row padding adding up to more than the 380px preview plus its gap and margin, and it would also silently change the Home page (whose rows can sit far enough from the left edge to satisfy the same condition), which the issue explicitly says must keep opening to the right. Tying the decision to the sidebar state that actually creates the free space is both more explicit and more stable.

Read the sidebar state directly inside ReceiptPreview rather than passing it in. Fewer wiring changes, but ReceiptPreview is shared by the Home page, the report transactions list, duplicate/merge screens and the unreported-expense list, none of which sit next to the Search sidebar — reading a global sidebar value there would flip the side for all of them, which is out of scope for this bug. Keeping the decision at the row level means each surface opts in explicitly.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-13 22:47:43 UTC.

Proposal

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

On a wide screen, hovering a receipt thumbnail in Spend > Expenses opens the zoom preview to the right of the thumbnail, on top of the row's own data, even when the expanded left sidebar leaves plenty of room. It should open to the left while the sidebar is expanded, and keep opening right on Home or when the sidebar is collapsed.

What is the root cause of that problem?

getAnchoredPreviewPosition.ts:31-33 treats the right side as the default and the left as an overflow escape hatch:

const overflowsRight = windowWidth > 0 && rightOfThumbnail + RECEIPT_PREVIEW_WIDTH + RECEIPT_PREVIEW_EDGE_MARGIN > windowWidth;
const left = overflowsRight ? Math.max(RECEIPT_PREVIEW_EDGE_MARGIN, anchorPosition.left - RECEIPT_PREVIEW_WIDTH - RECEIPT_PREVIEW_GAP) : rightOfThumbnail;

The receipt is the leftmost data column, so there is always room to the right, overflowsRight is never true, and the preview always lands on the row. Original flaw from #95056 (96b1b878ec6), not a regression.

The decision reduces to one number, so I computed it for every surface. The preview opens left when it fits there, i.e. when anchor.left >= 420 (380 receiptPreviewWidth + 16 gap + 24 edge margin). anchor.left comes from cellRef.measureInWindow (ReceiptCell.tsx:59) — absolute window coordinates.

Surface	anchor.left	Today	≥ 420?
Search table, sidebar expanded	456	right (bug)	yes → left
Search table, sidebar collapsed	212	right	no → right ✓
Home "Recently added"	136	right	no → right ✓
Reports tab, single-report table	456	right (same bug)	yes → left
Super-wide RHP (SEARCH_MONEY_REQUEST_REPORT / EXPENSE_REPORT)	456	right (same bug)	yes → left
RHP merge / duplicate / unreported	—	no preview at all	n/a

Search, expanded: 72 nav rail (variables.ts:126) + 320 searchSidebarExpandedWidth (:124) + 20 row mh5 + 12 row p3 + 20 checkbox (SelectionButton.tsx:120) + 12 gap3 = 456. Collapsed swaps 320 → 76 = 212. Home is 72 + 20 homePageContentContainer padding + 32 mh8 + 12 ph3 = 136, and it does not move on a wide monitor — homePageMainLayout is width: '100%' with the left column pinned, not centred (styles/index.ts:6972-6979).

These are not just derived — I measured them. Booted the app on a real browser at 1600×982, signed in, and read getBoundingClientRect() off the live DOM:

NavigationTabBar    left=0    width=72     <- nav rail
Search (content)    left=392               <- 72 + 320 expanded sidebar
transaction-item-row left=412  1168x52     <- + 20 (mh5)
receipt thumbnail   left=456  top=183  28x32   <- + 12 (p3) + 20 (checkbox) + 12 (gap3)

anchor.left = 456, and 28x32 is exactly variables.w28/h32. So 456 >= 420 and the left placement fires. Any figure below ~412 for the expanded case can be ruled out directly: the row's own outer edge is already there before a single pixel of in-row padding is counted.

Two things fall out of this that I think matter more than the reported bug:

1. Two more surfaces have the identical bug, unreported. The Reports-tab single-report transaction table renders the same ReceiptCell at the same 456 — but via ReportsSplitNavigator's 320px LHN (sideBarWithLHBWidth, variables.ts:123), not the Search sidebar. And the super-wide RHP (SearchMoneyRequestReportPage, any report with >1 transaction, useRHPWidth('super-wide') at :184) has its left edge pinned at windowWidth − 320 − 72 = 392 for any window ≥ 1232, so anchor.left is a constant 456 at 1440/1600/2560. Today it opens right at x=500, squarely on that row's own date/merchant/amount columns. Same bug, different screen.

2. Gating on the Search route does not fix them. A isSearchTopmostFullScreenRoute() && !isCollapsed guard is false in the Reports tab and false inside a right-modal, so both surfaces keep the bug. The room to the left is not created only by the Search sidebar — the Reports LHN and the super-wide RHP's pinned left edge create exactly the same 456px, coincidentally, for different structural reasons. Geometry catches all three; a route whitelist catches one.

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

Decide the side from the measured anchor in getAnchoredPreviewPosition.ts, keeping the existing overflow flip as the fallback:

const leftOfThumbnail = anchorPosition.left - RECEIPT_PREVIEW_WIDTH - RECEIPT_PREVIEW_GAP;
const fitsLeft = leftOfThumbnail >= RECEIPT_PREVIEW_EDGE_MARGIN;
const left = fitsLeft || overflowsRight ? Math.max(RECEIPT_PREVIEW_EDGE_MARGIN, leftOfThumbnail) : rightOfThumbnail;

One file, no prop threading, no new state. ReceiptCell re-measures on every mouse-enter, so collapsing/expanding the sidebar and resizing are tracked for free. Home and the collapsed sidebar keep opening right because they genuinely do not fit (136 and 212), not because we told them not to. The merge/duplicate/unreported RHPs cannot regress at all: they sit under RIGHT_MODAL_NAVIGATOR, never call useRHPWidth, so shouldUseNarrowLayout is true and ReceiptPreview returns null at index.tsx:119 before the positioning code runs. Vertical clamping and index.native.tsx are untouched.

Two caveats I would rather state than have found in review:

• On the super-wide RHP the preview lands at x 60–440. That is 87% dead space over the dimmed overlay, but the last ~48px overlaps the RHP's own checkbox column (which starts at 424). It never reaches the thumbnail or any data column — the preview's right edge is anchor.left − 16 = 440 < 456 by construction — so this is a clear improvement on covering the whole row, but it is not literally zero overlap.
• MoneyRequestReportTransactionList.tsx:433 compares minTableWidth against windowWidth, not the RHP width. If that ever puts the rows in a horizontal ScrollView, scrolling the table right would drag anchor.left below 420 and the preview would fall back to opening right. Whether minTableWidth can exceed the window with the default column set is column/label dependent and I could not settle it from code alone — worth a look in a running build.

For tests, tests/unit/components/ReceiptPreviewPositionTest.ts already covers this pure function. I would add the four anchors above as cases (456 → left, 212 → right, 136 → right, near-right-edge → still flips left).

What alternative solutions did you explore? (Optional)

Reading useSearchSidebarCollapse() and gating on isSearchTopmostFullScreenRoute(). It fixes the reported screen and leaves the Reports-tab table and the super-wide RHP broken, for the reason above. It also puts an Onyx + external-store subscription inside ReceiptPreview, which 87baf59e6aa ("pass layout props to ReceiptCell instead of per-row context subscriptions") deliberately moved out of this component.

Threading a preferLeft prop from each page down through TransactionItemRow → ReceiptCell → ReceiptPreview works but touches every consumer, and a partial update (fix the search row, forget one of the other three surfaces) silently leaves the bug in place — which is exactly the failure mode here.