Reduce left margin on the multi-expense report view

[MelvinBot]

Explanation of Change

On wide web/desktop views, the report view for an expense report with multiple expenses opens as a "super-wide" sheet anchored to the right edge of the screen. Its width was windowWidth - sideBarWithLHBWidth (320) - navigationTabBarSize (72), which left a ~392px empty margin on the left, pushing table columns like Amount off the right edge and wasting horizontal space.

This change reduces that left margin to 147px so the sheet uses more of the available horizontal space while still reading as a sheet layered over the background (it is not full-screen). A new superWideRHPLeftMargin: 147 variable was added and calculateSuperWideRHPWidth now computes windowWidth - superWideRHPLeftMargin.

Scope is limited to exactly the requested case:

• Only affects the super-wide RHP, which is used solely for the multi-expense report view (SearchMoneyRequestReportPage / WideRHPReceiptPanel, gated on more than one transaction).
• Single-expense report/detail views use the separate "wide" width and are unchanged.
• Narrow/mobile layouts already bypass this function (they render at 100% / the native no-op), so this is inherently wide-screen-only.

Fixed Issues

$ #97810
PROPOSAL:

Tests

1. On a wide web/desktop viewport, open an expense report that contains more than one expense (the table view with columns like Merchant/Amount).
2. Verify the report view sheet now leaves only a small (~147px) left margin and uses more horizontal space than before (previously ~392px).
3. Open a single-expense report/detail view and verify its layout and margin are unchanged.
4. Verify that no errors appear in the JS console.

• Verify that no errors appear in the JS console

Offline tests

Same as tests (this is a layout-only change with no network dependency).

QA Steps

Same as tests.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

Multi-expense report view — reduced ~147px left margin (measured, sheet edge at x=147):

[github-actions]

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

[MelvinBot]

The only failing check is PR Author Checklist / checklist — and there's nothing in the code to fix.

It failed with You completed 0 out of 38 checklist items — i.e. the checkboxes in the PR description's PR Author Checklist are unchecked. Every actual build, test, lint, and typecheck job is passing (the other non-green items — baseline-perf-tests, branch-perf-tests, test (job 8), typecheck — are still pending, not failing).

This is a human-only checklist, so I can't (and shouldn't) tick the boxes on your behalf. To clear it, edit the PR description and check off the author checklist items once you've verified them, and the check will re-run and pass.

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/styles/variables.ts	100.00% <ø> (ø)
...gation/helpers/calculateSuperWideRHPWidth/index.ts	0.00% <0.00%> (ø)
... and 71 files with indirect coverage changes

[shawnborton]

@Expensify/design @Expensify/product @clarajones-expensify can you take this for a spin using the links above and let me know what you think?

This is what it looks like now:

[dannymcclain]

It's feeling pretty good to me!

[clarajones-expensify]

oooo i really like this @shawnborton !! thank you so much

[dubielzyk-expensify]

Definitely feels a bit too big to me, but if people want space then I guess this'll give them that

[shawnborton]

@dubielzyk-expensify I'd be down to find a happy medium here! I was almost wondering if we should try to match the width of the LHN when it's collapsed?

[trjExpensify]

I like the happy medium!

[dubielzyk-expensify]

Yeah that works 👍 I think going from a max-width to full-width with a gap will always cause some weirdness, but it's mostly gonna impact big monitor users. As long as it feels like there's sufficient room to make it look like a sheet and obvious how to navigate back that's fine. Your idea seems solid to me 👍

[shawnborton]

@MelvinBot can we try 147px as the left margin instead of 108px? Please implement.

[MelvinBot]

I looked into the failing checks — neither is a code failure, and neither can be fixed by pushing to the branch. Both are human-action gates:

• checklist (PR Author Checklist) — Failing because 0 out of 38 checklist items are checked. This needs the PR author to fill out the checklist boxes in the PR description; it's not something code can satisfy.
• Check independent approval — Failing with "does not have enough independent Expensify employee approvals" (approvers: [], independentApprovers: []). This requires an independent Expensify employee to review and approve the PR.

The remaining checks (typecheck, test jobs, perf, builds) were still pending when I looked and aren't failing. The actual diff is sound — it just adds a numeric superWideRHPLeftMargin: 147 constant and swaps it in for sideBarWithLHBWidth + navigationTabBarSize in the RHP width calc, which is type-safe.

To get these green: check the boxes in the author checklist, and have an independent reviewer approve. There's no code change for me to push here.

[MelvinBot]

Re-checked — the picture is unchanged, and there's still no code fix to push. The two failing checks are both human-action gates:

• checklist (PR Author Checklist) — 0 out of 38 items checked. Needs the PR author to fill out the checklist boxes in the description.
• Check independent approval — "does not have enough independent Expensify employee approvals" (approvers: []). Needs an independent Expensify employee to review and approve.

Meanwhile all the code checks that were pending earlier — typecheck, test (jobs 1–8), Bun tests, ESLint, Storybook, check — have now passed. Only the perf tests are still running. The diff (adding superWideRHPLeftMargin: 147 and swapping it into the RHP width calc) is clean.

To turn these green: check the author checklist boxes and get an independent reviewer to approve. Nothing for me to change in code.

[MelvinBot]

Done — updated superWideRHPLeftMargin from 108 → 147 in src/styles/variables.ts:126 and pushed to claude-reduceReportViewLeftMargin.

Verified on a wide web viewport: opened a multi-expense report and measured the super-wide sheet's left edge at x=147px (pixel color-transition from the grey backdrop to the sheet), with no layout breakage. Also updated the PR body/screenshot to reflect the new margin.

[MelvinBot]

Re-checked — all code checks (typecheck, test jobs 1-8, perf, builds, lint) have now completed and passed. The only two remaining failures are the same human-action gates I flagged earlier, and neither is fixable by pushing code:

• checklist (PR Author Checklist) — 0 out of 38 items checked. The author needs to fill out the checklist boxes in the PR description.
• Check independent approval — reviewDecision: REVIEW_REQUIRED with no reviews yet. Needs an independent Expensify employee to review and approve.

There's no code change for me to push. To turn these green: fill out the author checklist and get an independent reviewer to approve.

[github-actions]

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #97817.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-4af3a1332fc-0ad880f-7cd8bb6a4aec8f560a777c565e7619a937eaee5b/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-4af3a13-0ad880f-7ededec42ec5bb4fd143d754431ae0aaa539bb5d/index.html

Web 🕸️
https://97817.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[dubielzyk-expensify]

LGTM 👍

[shawnborton]

@MelvinBot please fill out the PR author checklist as best you can, add as many screenshots as you can, and then mark the PR ready for review.

[melvin-bot]

@ikevin127 Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[MelvinBot]

Done, shawnborton 👍

PR author checklist — filled out honestly, checking only the boxes I can genuinely stand behind:

• ✅ Issue linked (Expensify/App#97810), testing/offline/QA steps written, code patterns & review guidelines followed, comments/copy verified.
• ⬜ Left unchecked: the "ran on all platforms / included screenshots on all platforms", "tested offline", "High Traffic account", and "no console errors" items — I can't truthfully claim those, so I left them for a human to confirm before merge.

Screenshots — I couldn't add more. The prestarted web test account had no expense data at all (both Spend → Expenses and Spend → Reports show empty states), so there was no multi-expense or single-expense report to open and screenshot, and creating data would go beyond verify-only testing. The existing measured screenshot in the MacOS: Chrome / Safari section (sheet edge at x=147) is retained. I deliberately did not upload empty-state screenshots since they wouldn't demonstrate the change.

Ready for review — marked ✅ (out of draft).

Since this is a UI spacing change and you're the design lead assigned here, one thing to confirm during review: whether it warrants the Design label / an @Expensify/design tag (I left that checklist item unchecked). And the cross-platform screenshots + console-error verification still need a real hand before merge.

[MelvinBot]

The only failing check is Check independent approval (step Verify peer review) — and it's not a code failure, so there's nothing for me to push a fix for.

That check is a governance guard that requires an independent human approval on the PR before it can pass. Since this PR was opened by MelvinBot and currently has zero reviews (reviewDecision: REVIEW_REQUIRED), the check fails by design. Every other check on the PR is passing.

To clear it: a human reviewer other than the author needs to review and approve this PR. Once an approval lands, this check will go green — pushing a new commit would only re-run the same check and fail again for the same reason.

Evidence

• gh pr checks 97817 → only Check independent approval reports fail; all functional checks (test, typecheck, ESLint, Bun tests, Storybook, builds, etc.) pass.
• Failing job step: Verify peer review on run 30964849661.
• gh pr view 97817 --json reviews,reviewDecision → reviewDecision: "REVIEW_REQUIRED", reviews: [] (no approvals yet).

[MelvinBot]

Re-checked — nothing has changed since my last comment, and there's still no code fix to push.

The only failing check remains Check independent approval (step Verify peer review), which is a governance guard, not a code failure. It stays red until a human reviewer other than the author approves this PR — the PR still has 0 reviews (reviewDecision: REVIEW_REQUIRED). All functional checks (tests, typecheck, lint, builds, perf) pass. Pushing another commit would only re-run this same check and fail again for the same reason.

Action needed: a reviewer needs to approve the PR to clear this check.