[Deploy Blocker] Android - Chat - Emoji picker and + button are not responsive when composer is not focused

@GCyganek

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

Version Number: 9.5.13-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: https://test-management.browserstack.com/projects/2219752/test-runs/79083052/folder/13176681/41236985/1869288627?q=emoji&issue_type=jira&sort=-identifier
Email or phone of affected tester (no customers): jsoidjndoiniodnsjojd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Chat Report View

Action Performed:

Launch Expensify app.
Open any chat.
Close the keyboard if opened.
Tap emoji picker or + button.

Expected Result:

Emoji picker will open.

Actual Result:

Emoji picker is not responsive when composer is not focused.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7288108_1792154655321.Screen_Recording_20261016_204317_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7288108

Issue Owner

Current Issue Owner: @GCyganek

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/75b172138ffe42f8440c0498f9be0098573934639c8bb20e59ad50f8c37c3930

@neil-marcellini

Triggered auto assignment to @neil-marcellini (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

👋 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:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

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

Deploy Blocker Analysis

Likely cause: Add liquid glass bottom tab bar to iOS, Android and mWeb by sumo-slonik, merged 2026-10-15 in merge commit 3e8adfb5. Confidence is medium. I found it by ruling out every other PR in the checklist, but I did not reproduce it on an Android device.

Recommendation: Revert Add liquid glass bottom tab bar to iOS, Android and mWeb. The later staging PRs don't touch its files, so the revert should apply cleanly. It is also blamed for [Liquid Glass][Bug - QA Exploration] Android - Bottom tab bar label is too small when font size is minimum, which the revert would also fix.

Investigation details

Ruled out by elimination

Between production and staging, nothing changed in ReportActionCompose/, EmojiPickerButton, Pressable, Popover/PopoverMenu, Modal, KeyboardAvoidingView, or the keyboard utilities. package.json only bumps the version.
The only nearby change is CategoryShortcutButton.tsx. It changes how category labels are translated inside the open picker, so it can't stop the picker from opening. It also doesn't explain the + button.
The other staging PRs cover docs, workflows, IOU/policy logic, search, settings, and Share. None of them touches the chat composer or the Android navigation container.

Likely mechanism (inferred from code, not verified on a device)

On Android, the PR replaces the JS bottom-tab navigator with the native Material tab bar from react-native-screens, in TabNavigator.native.tsx:31. Every chat now renders inside that native tab container (L53-L64).
On chat screens the bar is hidden with display: 'none', in useNativeTabBarOptions/index.android.ts:43 and useNativeTabNavigator.ts:66.
The + button (AttachmentPickerWithMenuItems.tsx:465-475) and the emoji button (EmojiPickerButton.tsx:49-76) use different JS code paths, so a shared JS bug is unlikely.
What the two buttons share is position. With the keyboard closed, both sit in the bottom strip, where the native tab bar lives. With the keyboard open, they move up out of that strip and work. This suggests the hidden bar, its inset handling, or the new tab overlay layers swallow taps in that strip.

To confirm on a device

Turn on Android "Pointer location" or use Layout Inspector to see which view receives taps in the bottom strip.
Retest an adhoc build with the PR reverted.

If you prefer to roll forward: keep the JS tab bar on Android only and leave iOS on native tabs. That needs agreement from the PR author and reviewers.

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

view run

👀

Fix CP'd to Staging here : #104238

⚠️ 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.

⚠️ 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.

Fixed, Samsung Galaxy S25 FE / Android 16, 9.5.13-1

Screen_Recording_20261017_004459_Expensify.mp4