[Due for payment 2026-06-18] [Due for payment 2026-06-17] iOS - Workspace is not tappable after selecting category and returning to workspace list

[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.2-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90537
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: iPhone 15 Pro Max / iOS 26.5
App Component: Workspace Settings

Action Performed:

1. Launch Expensify app.
2. Go to workspace settings > Categories.
3. Long tap on any category and tap Select.
4. Swipe back twice to return to workspace list.
5. Tap on any workspace.

Expected Result:

Workspace will be tappable after selecting category and returning to workspace list.

Actual Result:

Workspace is not tappable after selecting category and returning to workspace list.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7176412_1781054606390.ScreenRecording_06-10-2026_09-21-26_1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7176412

[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/42793b63094f44262d6844b0f3eb541653e6435dfd2f7562915b46c2c3972b42

[melvin-bot]

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

[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

Root Cause

PR #90537 made all tables share a single global "mobile selection mode" flag (the RAM_ONLY_MOBILE_SELECTION_MODE Onyx key), and the row‑press handler in the shared Table component keys off that global flag without checking whether this particular table even has selection enabled.

In TableRow.handleRowPress, a row tap is redirected to the checkbox handler whenever shouldUseNarrowLayout && isMobileSelectionEnabled is true:

if (shouldUseNarrowLayout && isMobileSelectionEnabled) {
    handleCheckboxPress(event);   // hijacks the tap, onPress never fires
    return;
}
onPress?.();

Note that the sibling handleRowLongPress at line 169 does correctly also check selectionEnabled — handleRowPress is missing that same guard.

The flow that triggers the bug:

1. On Categories, tapping Select calls turnOnMobileSelectionMode(), setting the global flag true (Table.tsx).
2. The flag is only turned off in the Categories page's onBackButtonPress handler. The iOS swipe‑back gesture bypasses that handler, so the flag stays true.
3. Back on the workspace list, WorkspaceListTable uses the same Table component but never opts into selection (selectionEnabled is false). Yet because the global flag is still true, every workspace row tap is rerouted to handleCheckboxPress → handleSingleRowSelection, which does nothing here (no onRowSelectionChange). The row's real onPress={item.action} (navigate to workspace) never runs.

This cleanly explains all the symptoms: iOS‑only (gated on shouldUseNarrowLayout), triggered by swipe‑back (bypasses the only flag‑reset path), and workspace rows appearing dead (taps redirected to a no‑op).

Recommended Fix

Add the missing selectionEnabled guard to handleRowPress so the redirect only applies to tables that actually opted into selection — consistent with handleRowLongPress:

// src/components/Table/TableRow.tsx:160
if (shouldUseNarrowLayout && isMobileSelectionEnabled && selectionEnabled) {
    handleCheckboxPress(event);
    return;
}

This scopes the press‑redirect to the table that owns the selection, so a stale global flag set by the Categories table can no longer disable taps on the workspace list.

Secondary issue worth addressing (defense in depth)

The global flag leaking across screens is the deeper problem. The Categories page only resets it via the header back button, but iOS swipe‑back, hardware back, and other nav paths skip it. Consider turning off mobile selection mode on screen blur/unmount of WorkspaceCategoriesPage (not just in onBackButtonPress) so the flag never persists into an unrelated screen. The one‑line selectionEnabled guard above fixes the reported regression; this addresses the class of bug.

Why "not reproducible in production"

The flag is RAM‑only and the new categories table shipped in this staging release (PR #90537, the suspected regression source), so production doesn't yet have the shared Table/global‑flag interaction.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/blob/a671aa4998030cd933b14917ba9faabc2f2f1306/src/components/Table/TableRow.tsx#L155-L166) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[JS00001]

pr open to fix