[Payment due] [$250] Android-Chat-using header markdown, typing texts from the third line not fit on composer box

[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: v9.2.60-0
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/test-runs/TR-2012/folder/13176723/41237038/1022759611
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Device used: Samsung A25/Android 16
App Component: Chat Report View

Action Performed:

1. Open app
2. Navigate to any conversation
3. Type header markdown # and some texts for 4 lines
4. Send message
5. Hold the message for open menu and select Edit comment
6. Type some texts

Expected Result:

The typing texts should be fit on composer box

Actual Result:

From the third line, the lower part of typing texts are cut off. When edit message, user can't scroll down for see them fully

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7007647_1763490818468.Az_Recorder_20251119_005519_1_.mp4

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022013234891082341177
• Upwork Job ID: 2013234891082341177
• Last Price Increase: 2026-01-19

Issue Owner

Current Issue Owner: @garrettmknight

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021992933361632121544

[melvin-bot]

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

[annaweber830]

Proposal

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

When editing a message that contains header markdown (#), text from the third line onwards gets cut off in the composer box.

What is the root cause of that problem?

The root cause is insufficient bottom padding in the textInputCompose style definition in src/styles/index.ts. Currently, paddingBottom is set to 0, which provides no bottom padding for the composer text input.

App/src/styles/index.ts

Line 2056 in f542fba

paddingBottom: 0,

When markdown headers are rendered, they have:

1. Larger line heights
2. Additional margins
3. Larger font sizes

The combination of these factors means that when content with markdown headers exceeds the visible area of the text input, the lack of bottom padding causes the bottom portion of text (from the third line onwards) to be cut off. Without sufficient padding, the text input's scrollable area doesn't account for the extra space needed by markdown headers' larger line heights and margins, making the bottom text inaccessible through scrolling.

This is particularly problematic on Android, where the text input behavior with multiline content and height: 'auto' requires careful padding configuration to ensure proper scrolling and text visibility.

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

Change the paddingBottom value in the textInputCompose style from 0 to Platform.OS === 'android' ? variables.fontSizeNormal * 0.4 : 0 in src/styles/index.ts.

Specific changes:

App/src/styles/index.ts

Line 2056 in f542fba

paddingBottom: 0,

Changed code:

paddingBottom: Platform.OS === 'android' ? variables.fontSizeNormal * 0.4 : 0,

This change will add approximately 6-8px of bottom padding on Android devices (since variables.fontSizeNormal is 15-21px depending on device pixel ratio, and 0.4 * 15 = 6px, 0.4 * 21 = 8.4px), while keeping 0 padding on iOS and other platforms.

Why this fixes the issue:

1. Provides sufficient bottom space on Android: The additional 6-8px of bottom padding on Android ensures there's enough space to accommodate markdown headers with their larger line heights (28-32px) and margins (8px)
2. Enables proper scrolling: With adequate bottom padding, the text input's scrollable area will correctly account for all content, including markdown headers, allowing users to scroll to see all text
3. Platform-specific fix: Since the issue is most noticeable on Android (as mentioned in the issue description), applying padding only on Android is appropriate and won't affect iOS behavior
4. Follows existing pattern: The codebase already uses Platform.OS === 'android' checks for Android-specific styling (as seen in the comment above this style), so this approach is consistent with existing patterns
5. Minimal visual impact: The padding is calculated as a percentage of font size (0.4x), making it proportional and visually appropriate

Note: This change affects all uses of the textInputCompose style throughout the app, but since the composer is the primary use case and the padding is minimal, this should not cause visual regressions in other contexts.

What alternative solutions did you explore?

[eVoloshchak]

@annaweber830, thank you for the proposal!

I think this needs a more holistic approach, that would adapt to the composer's content (padding would be wrong if you use different font sizes in markdown and it would still be imperfect across all devices due to different DPI/font settings). Adding the padding does seems like a work around another underlying issue (potentially in react-native itself).

This is particularly problematic on Android, where the text input behavior with multiline content and height: 'auto' requires careful padding configuration to ensure proper scrolling and text visibility.

This is the most important part. Why does behavior differ between iOS and Android?