Android - Composer - "Write something" is stuck to the top of the composer

[lanitochka17]

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.41-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/TR-10912/folder/13176681/41236977/1264592242
Email or phone of affected tester (no customers): sdjsdjosijnsodiosd@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:

1. Launch Expensify app.
2. Open an empty chat.
3. Tap on the composer.
4. Tap device back button.
5. Open emoji picker.
6. Tap outside emoji picker.
7. Tap + button.
8. Dismiss the modal.
9. Repeat Step 3 to 8.

Expected Result:

"Write something" will not be stuck to the top of the composer.

Actual Result:

"Write something" is stuck to the top of the composer.
Tapping below "Write something" will not focus on the composer.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7107676_1773952220228.Screen_Recording_20260320_042554_Expensify.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @war-in

[melvin-bot]

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

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #85544 - "[NO QA] Composer Performance Improvements" by @JS00001 (High confidence)
Related Issues: None

Recommendation: REVERT

This PR modified the containsOnlyEmojis function to add an early return when the message is empty. This changes the behavior/timing of the textContainsOnlyEmojis calculation in the Composer, which affects the markdown styling passed to the underlying React Native Live Markdown component. This appears to cause a rendering issue on Android where the placeholder text gets stuck at the top of the composer.

Labels: Keeping DeployBlockerCash (frontend App PR caused the issue). No label changes needed.

Detailed Analysis

Evidence

• PR [NO QA] Composer Performance Improvements #85544 merged on March 17, 2026
• Issue Android - Composer - "Write something" is stuck to the top of the composer #85877 reported on March 19, 2026 for version 9.3.41-0
• Bug is reproducible on staging (which includes PR [NO QA] Composer Performance Improvements #85544) but NOT on production
• PR [NO QA] Composer Performance Improvements #85544 is listed in the StagingDeployCash checklist at position 51

Verification

PR #85544 modified two files:

1. src/components/Composer/implementation/index.tsx - Added early return in web implementation
2. src/libs/EmojiUtils.tsx - Added early return in containsOnlyEmojis function

The EmojiUtils.tsx change affects BOTH web and native platforms because both implementations call this function:

Native (index.native.tsx) - Line 40:

const textContainsOnlyEmojis = useMemo(() => containsOnlyEmojis(Parser.htmlToText(Parser.replace(value ?? ''))), [value]);

The Change:

function containsOnlyEmojis(message: string): boolean {
+    if (!message) {
+        return false;
+    }
    const trimmedMessage = Str.replaceAll(message.replaceAll(' ', ''), '\\n', '');
    const match = trimmedMessage.match(CONST.REGEX.ALL_EMOJIS);
    ...
}

Root Cause

The early return changes the timing/behavior when the composer value is empty or being cleared. The textContainsOnlyEmojis value is used to determine markdown styling that is passed to the RNMarkdownTextInput component. On Android, this appears to cause the underlying React Native Live Markdown component to not properly update its internal state related to placeholder rendering, causing the placeholder text to become stuck at the top of the composer.

The bug manifests after a specific sequence of actions (opening/closing emoji picker, modals, etc.) that involve focus/blur cycles combined with the changed empty-state behavior.

[MelvinBot]

Proposal

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

On Android (staging v9.3.41-0), the "Write something" placeholder text in the chat composer gets stuck at the top of the input after cycling through: tap composer → press back button → open emoji picker → close it → tap + button → dismiss → repeat. The placeholder remains pinned to the top and tapping below it doesn't focus the composer. This does not reproduce on production.

What is the root cause of that problem?

The root cause is the React Native 0.81 → 0.83 upgrade (PR #79962), which changes how the Android TextInput measures content during keyboard show/hide transitions.

Specifically, two patches applied on top of RN 0.83.1 alter Android TextInput behavior in ways that interact poorly with the composer's layout cycle during rapid focus/blur/keyboard transitions:

1. Patch 007 (TextInput.patch) removes the cachedAttributedStringId measurement fast-path from AndroidTextInputShadowNode.cpp. In RN 0.81, the TextInput could use a cached spannable for quick re-measurement. With this patch, every layout cycle forces a full text re-measurement from scratch. During rapid keyboard show/hide transitions (back button, emoji picker, action menu), the full re-measurement can produce inconsistent results because the AttributedString state may be stale when the measurement runs.

2. Patch 015 (android-keyboard-avoiding-view.patch) changes the height reported in keyboardDidHide events from mVisibleViewArea.height() to mLastHeight (or getMeasuredHeight()). If this height differs from what the layout engine expects, KeyboardAvoidingView calculates incorrect offsets, causing the composer container to settle at the wrong size.

The composer uses textAlignVertical="top" (set in ComposerWithSuggestions.tsx:970), and on Android the TextInput uses height: undefined with flexGrow: 1, flexShrink: 1 for sizing (src/styles/index.ts:2143-2156). When the measurement becomes inconsistent after keyboard cycling, the flex container grows larger than the single-line content height, and the placeholder text sits at the top of this oversized space — appearing "stuck" at the top.

This was already flagged during the RN 0.83 upgrade QA as Bug #6: "Write something placeholder jumps when opening emoji picker on Android" (see PR #79962 comments). It was marked as "reproducible on prod" at the time and deprioritized, but the current bug may be a worse manifestation (stuck vs. momentary jump).

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

Two approaches, in order of preference:

Option A (targeted fix): Investigate whether changing textAlignVertical from "top" back to "center" in ComposerWithSuggestions.tsx:970 resolves the visual symptom without breaking multiline text entry. If single-line placeholder looks correct with "center" and multiline text still works, this is the simplest fix.

Option B (measurement fix): If Option A doesn't work (e.g., multiline text alignment is wrong with "center"), the TextInput measurement patch (007) may need to be refined. The patch removes the cached measurement entirely — a more targeted fix could keep the cached path but invalidate it when focus/keyboard state changes, ensuring fresh measurements during transitions while still benefiting from the cache during stable states.

In either case, the android-keyboard-avoiding-view patch (015) height calculation should also be verified — check that the mLastHeight value matches the actual visible area height after keyboard dismissal on the affected device (Samsung Galaxy S25 FE / Android 16).

What alternative solutions did you explore? (Optional)

• EmojiPicker timing changes: The EmojiPicker native component replaced InteractionManager.runAfterInteractions() with direct requestAnimationFrame() calls, changing focus/blur timing. This could be a contributing factor but doesn't explain why the placeholder gets permanently stuck.
• FlashList 2.3.0 upgrade (PR Bump FlashList to v2.3.0 #85541): The inverted chat list upgrade could affect the composer's parent container layout, but FlashList doesn't directly control the TextInput measurement.
• composerHeightAfterClear mechanism: This state management in ComposerWithSuggestions could theoretically get stuck, but it's only triggered during message send, not during focus/blur cycling.
• emptyComposerHeightRef stale value: This ref is captured once from the first content size event. If measured during a keyboard transition, it could be incorrect, causing wrong heights when applied via resetHeight.

---

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.