[$250] Workspaces -Button Learn more not available for first time open "No workspace found" screen.

[mitarachim]

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.3.33-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/folder/13176682/test-cases/41236556
Email or phone of affected tester (no customers): rybkina+030726up@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 17 Pro /26.3
App Component: Other

Action Performed:

1. Signup with a new Gmail account as a user with no workspace
2. Tap on FAB > Start chat > Room
3. Tap on Learn more button on "No workspace found" screen

Expected Result:

Learn more button on "No workspace found" screen should be available.

Actual Result:

The "Learn details" button is located on the "Workspace not found" screen, hidden under the keyboard.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7096170_1772851489568.ScreenRecording_03-06-2026_20-38-33_1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @nkdengineer

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022030999897279138558
• Upwork Job ID: 2030999897279138558
• Last Price Increase: 2026-03-16

[melvin-bot]

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

[MelvinBot]

Proposal

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

When a new user with no workspace navigates to FAB > Start chat > Room, the "No workspace found" screen appears but the "Learn more" button is hidden behind the keyboard on iOS.

What is the root cause of that problem?

There are two compounding issues:

1. KeyboardAvoidingView is explicitly disabled for the empty workspace state. In src/pages/workspace/WorkspaceNewRoomPage.tsx:243, shouldEnableKeyboardAvoidingView is set to workspaceOptions.length !== 0, which evaluates to false when there are no workspaces. The parent NewChatSelectorPage.tsx:61 also has shouldEnableKeyboardAvoidingView={false}. So there is no keyboard avoidance at any level of the view hierarchy.

2. The EmptyWorkspaceView has no ScrollView. In src/pages/workspace/WorkspaceNewRoomPage.tsx:41-58, the EmptyWorkspaceView renders a bare Fragment containing a BlockingView (which uses flex:1, taking all available vertical space) and a Button ("Learn more") as a sibling below it. With no scroll container and no keyboard avoidance, the button gets pushed below the visible area when the keyboard is open.

The keyboard stays open because when the user switches from the "New Chat" tab (which has a text input) to the "Room" tab, the onTabSelectFocusHandler in NewChatSelectorPage.tsx:37-48 attempts to focus roomPageInputRef, but in the empty workspace state there is no input element so the focus call is a no-op — the keyboard from the previous tab remains visible on iOS.

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

Dismiss the keyboard when the EmptyWorkspaceView is shown, since there are no input fields in this state. Add a useEffect in the EmptyWorkspaceView component (src/pages/workspace/WorkspaceNewRoomPage.tsx) that calls Keyboard.dismiss() on mount. This ensures the keyboard is dismissed when a user with no workspaces lands on the Room tab, making the "Learn more" button visible.

What alternative solutions did you explore? (Optional)

1. Wrapping EmptyWorkspaceView in a ScrollView — this would allow scrolling to the button, but a scroll container isn't really appropriate for a static blocking view with a single button. It also doesn't solve the core problem of the keyboard being open when there's nothing to type into.

2. Enabling shouldEnableKeyboardAvoidingView for the empty state — this would adjust the layout, but since there are no inputs in the empty state, dismissing the keyboard is the more correct behavior.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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