[Due for payment 2026-06-17] Web - Spend - CMD+B is no longer responsive after pressing it once on Spend > Reports

[applause-bot]

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.4.0-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: #92064
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Search

Action Performed:

1. Go to staging.new.expensify.com
2. Create a new account.
3. Create a workspace.
4. Go to workspace chat.
5. Create a new report.
6. Go to Spend > Reports.
7. Open the report.
8. Press CMD+B.
9. Go to Spend > Reports.
10. Open the report.
11. Press CMD+B.

Expected Result:

Workspace settings will open.

Actual Result:

CMD+B is no longer responsive after pressing it once on Spend > Reports.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7172908_1780684902068.16.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7172908

[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/1fee01038a8689079756a61ed801cb3d0221d4a2e1ea199d2ecc6a35c83e868c

[melvin-bot]

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

[melvin-bot]

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

[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.

[MelvinBot]

Proposal

What is the root cause of that problem?

The CMD+B handler (GoToWorkspaceHandler.tsx:23, added in this PR) resolves the current report with Navigation.getTopmostReportId(). If no report is found, it returns early and does nothing.

getTopmostReportId() only inspects the chat report stack — getTopmostReportParams.ts:22-39 searches exclusively for REPORTS_SPLIT_NAVIGATOR → SCREENS.REPORT.

But a report opened from Spend > Reports is not a SCREENS.REPORT in that navigator — it opens as SEARCH_REPORT / SEARCH_MONEY_REQUEST_REPORT (see SearchStaticList.tsx:164 and Search/index.tsx:1296). So for a Search-opened report, getTopmostReportId() returns undefined and CMD+B is a no-op.

Why it "works once" then stops: the repro steps first create a workspace chat report (steps 4-5), which leaves a REPORTS_SPLIT_NAVIGATOR lingering in the nav state. The first CMD+B finds that report and navigates to the workspace (coincidentally the same workspace). That navigation to the full-screen workspace route clears the chat navigator from the state. On the second attempt, only the Search report remains — getTopmostReportId() finds nothing, and nothing happens. The shortcut isn't "frozen"; it simply can't resolve a report opened from Search.

Why it's not a keyboard-subscription / stack issue

• The handler subscribes once at mount with [] deps and stays subscribed for the app lifetime; no competing handler subscribes to key B (only this handler does).
• Shortcut events don't bubble by default and only the top-of-stack handler fires, but there is no second B subscriber, so the event is delivered — the callback just returns early because reportID is undefined.

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

In GoToWorkspaceHandler, fall back to the Search report navigators when getTopmostReportId() is empty. Helpers already exist for this:

• getTopmostSuperWideRHPReportID() — resolves SEARCH_MONEY_REQUEST_REPORT / EXPENSE_REPORT reports.
• getTopmostSearchReportRouteParams() — resolves SEARCH_REPORT (RHP).

Resolve reportID from the chat report first, then fall back to these Search helpers, before looking up the report's policyID. The cleanest option is a single helper that returns the topmost report ID regardless of which navigator it lives in, used by this handler.

What alternative solutions did you explore? (Optional)

If a quick deploy-blocker mitigation is preferred over the broader fix, scope the change to only resolve the Search-opened report when a chat report isn't present.

---

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

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[godzillaxbox19982014-lgtm]

Proposal

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

Web - Spend - CMD+B is no longer responsive after pressing it once on Spend > Reports

What is the root cause of that problem?

I traced this to the path that handles workspace name, CMD:

• src/pages/workspace/reports/WorkspaceReportsPage.tsx:65 (useResponsiveLayout): const {shouldUseNarrowLayout} = useResponsiveLayout();
• src/pages/workspace/reports/WorkspaceReportsPage.tsx:325 (navigate): onPress={() => Navigation.navigate(ROUTES.WORKSPACE_CREATE_REPORT_FIELD.getRoute(policyID))}
• src/pages/workspace/reports/ReportFieldsListValuesPage.tsx:75 (useResponsiveLayout): const {isSmallScreenWidth} = useResponsiveLayout();
• The local evidence matches this recurring failure shape: shared workspace list builds options without the same eligibility filter as another workspace surface. Here, src/pages/workspace/reports/WorkspaceReportsPage.tsx:65 and src/pages/workspace/reports/WorkspaceReportsPage.tsx:325 do not agree on the same workspace name, CMD value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/workspace/reports/WorkspaceReportsPage.tsx:65 to derive workspace name, CMD from the workspace setup and policy state that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/workspace/reports/WorkspaceReportsPage.tsx:325; that follows the safer family move to move the rule into the shared selector/helper, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Workspace, Policy, Categories, Tags, Rules surface and avoid changing account/admin permission surfaces, policy owner/current-user exceptions.

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

1. Add or update a regression in tests/unit/Policy*.ts for the exact issue flow: Web - Spend - CMD+B is no longer responsive after pressing it once on Spend > Reports.
2. Cover the counter-case near src/pages/workspace/reports/WorkspaceReportsPage.tsx:65 so valid existing workspace name, CMD behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep workspace name, CMD consistent at the first read/write boundary shown above.