[$250] Chat - Composer field is cut off at the bottom when expanded

[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.3.84-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/folder/13176681/test-cases/41236978
Email or phone of affected tester (no customers): fischer9966+053122@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: MacOS 26.5 / Chrome, Safari, iPhone 17 Pro / 26.5, iPad 9th Gen / 26.5. Pixel 5 / Android 14
App Component: Chat Report View

Action Performed:

1. Open Expensify app or go to staging.new.expensify.com
2. Login with any account
3. Open any chat
4. Enter a any text that is over 3 lines to get Expand icon
5. Tap "expand" icon to expand composer field

Expected Result:

"Composer" field expands correctly. All elements are visible.

Actual Result:

Composer field is cut off at the bottom when expanded. Mobile apps - bottom part of the composer is hidden by the keyboard. Web - bottom line touches the bottom edge of the screen.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7164845_1779925498667.iOS-expanded-composer-cuts-off.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7164845

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022059890385898616348
• Upwork Job ID: 2059890385898616348
• Last Price Increase: 2026-06-11

[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/b88a99df65a1ff38c6352448a21982d8a12f45039135ad78cf074198d8ceb77a

https://platform.applause.com/services/links/v1/external/8086fa385186f8154f591acd6903e80c01f3249b53350280de8b7069db16bc64

[MelvinBot]

Proposal

What is the root cause of that problem?

When the composer is expanded to full size, chatFooterFullCompose sets height: '100%' on the footer. However, the footer's parent container in ReportScreen.tsx:146-147 is a flex column with overflow: 'hidden' that also contains the ReportActionsList as a sibling. When the footer requests 100% height, the ReportActionsList still occupies flex space above it — the two siblings compete for the same space. The footer gets pushed down and its bottom is clipped by overflow: 'hidden'.

Additionally, chatFooterFullCompose has paddingTop: 20 but no paddingBottom, so the bottom content touches the screen edge on web. On native, the keyboard further reduces available height but the 100% height doesn't account for it, causing the bottom to be hidden behind the keyboard.

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

When isComposerFullSize is true, the ReportActionsList sibling in ReportScreen.tsx:150 should be hidden (e.g., display: 'none' or flex: 0) so the expanded footer can actually occupy the full parent height without competing for space. Additionally, add paddingBottom to chatFooterFullCompose to prevent the content from touching the bottom edge.

What alternative solutions did you explore? (Optional)

• position: 'absolute' on the footer to overlay the actions list — rejected because it would break keyboard avoidance and safe area handling.
• Calculating exact pixel height instead of 100% — rejected as fragile and platform-dependent; hiding the sibling is the simpler, more robust fix.

Investigation details

Layout hierarchy when expanded:

1. Parent View (ReportScreen.tsx:146): flex:1, justifyContent:'flex-end', overflow:'hidden'
2. Child 1: ReportActionsList (takes flex space)
3. Child 2: ReportFooter with chatFooterFullCompose: height:'100%', paddingTop:20

The footer's height: '100%' in a flex context doesn't actually give it 100% of the parent — the flex algorithm distributes space among siblings first. The ReportActionsList consumes its share, leaving the footer with less than 100%, and its bottom overflows past the parent's bounds where overflow: 'hidden' clips it.

Inner components (ComposerInputArea.tsx:26) also set height: '100%' via chatItemFullComposeRow, cascading the sizing problem down to the text input itself.

---

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.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-28 07:05:25 UTC.

Proposal

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

When the user types more than three lines into the chat composer and taps the expand icon, the composer enters full-size mode but its content is clipped at the bottom — on web/desktop the composer's bottom border touches the very edge of the viewport (the typing indicator / character-limit row is invisible), and on iOS/Android the bottom of the input area sits beneath the on-screen keyboard. The bug reproduces on staging and production at 9.3.84-0 on every platform listed in the report.

What is the root cause of that problem?

This is a layout-overflow regression introduced by PR #90915 (refactor: Split ReportActionCompose into more compositional components, merged 2026-05-26, commit 6a3c80832c9). Pre-refactor, ReportActionCompose rendered a single ReportActionComposeInner whose JSX nested the chat-footer indicators (OfflineIndicator, AgentZeroAwareTypingIndicator, ComposerExceededLength) inside the same OfflineWithFeedback whose style carried chatItemFullComposeRow (height: '100%') and whose contentContainerStyle carried flex: 1. The input box (flex: 1 via chatItemFullComposeBox) and the indicator row (intrinsic ~27px via chatItemComposeSecondaryRow) were therefore siblings of one bounded flex-column parent, so the box grew and the row sat at the bottom — both inside the 100%-height region. The split moved those indicators into a new ComposerDefaultFooter component, and a follow-up cleanup (commit 0eafc2a3fbf, "refactor: remove redundant extra component") then deleted the ComposerLayout wrapper that used to enclose both children, hoisting chatItemFullComposeRow onto the outer View of ComposerInputArea itself.

After that change, ReportActionCompose renders the two pieces as direct siblings inside ComposerProvider, which produces no DOM/native wrapper of its own:

App/src/pages/inbox/report/ReportActionCompose/ReportActionCompose.tsx

Lines 27 to 31 in 377d37b

	return (
	<ComposerProvider reportID={reportID}>
	<ComposerInputArea />
	<ComposerDefaultFooter />
	</ComposerProvider>

The first sibling, ComposerInputArea, claims height: '100%' (which chatItemFullComposeRow resolves to via sizing.h100) of its parent — the chatFooterFullCompose View from ReportFooter, also height: '100%':

App/src/pages/inbox/report/ReportActionCompose/ComposerInputArea.tsx

Lines 24 to 27 in 377d37b

	<View
	testID={CONST.COMPOSER.TEST_ID.REPORT_ACTION_COMPOSE}
	style={[isComposerFullSize && styles.chatItemFullComposeRow]}
	>

The second sibling, ComposerDefaultFooter (the typing/offline/exceeded-length row), is laid out after that 100%-tall first child in the default flexDirection: 'column', so it sits past the bottom of the chat-footer container. The ReportScreen's outer flex column has overflow: 'hidden', so on web that overflowed row is clipped and the input box's own bottom border meets the screen edge with no breathing room; on iOS/Android the same overflow plus the missing intrinsic-height "bumper" means the bottom of the input region sits at (or below) the keyboard's top edge, since the only thing that previously kept the input clear of the keyboard was that indicator row taking its 27px share of the bounded region. The "bottom is hidden by keyboard" symptom on native and the "bottom line touches the screen edge" symptom on web are two views of the same regression: an out-of-bounds sibling and no participant in the height division anymore.

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

Restore the layout invariant the cleanup commit broke: both ComposerInputArea and ComposerDefaultFooter must share one bounded column whose height is chatItemFullComposeRow in expanded mode, with the input area taking flex: 1 and the footer keeping its intrinsic 27px. Concretely, re-introduce a tiny ComposerLayout (or equivalently a wrapper View directly in ReportActionCompose) that consumes isComposerFullSize from Onyx and renders <View style={[isComposerFullSize && styles.chatItemFullComposeRow]}>{children}</View>, and use it in ReportActionCompose to wrap <ComposerInputArea /><ComposerDefaultFooter />. Then change ComposerInputArea's own outer View style from chatItemFullComposeRow to styles.flex1 for the isComposerFullSize case — its inner column (<ComposerLocalTime /> + the existing flex: 1 View holding <ComposerContainer /> and <ComposerImportedState />) is already correct and doesn't need any other change.

After the fix, the inner column inside the new wrapper is: ComposerInputArea (flex: 1, grows to fill the remaining height) and ComposerDefaultFooter (intrinsic ~27px), exactly mirroring the pre-refactor OfflineWithFeedback-children layout that has shipped to production for years. The EditOnlyReportActionCompose code path is unaffected because it renders <ComposerInputArea /> directly inside a sibling <View style={[isComposerFullSize ? styles.chatFooterFullCompose : undefined, styles.mb2]}> in ReportFooter (line 163) — that wrapper is already an explicit height: '100%' flex-column container, so ComposerInputArea's new flex: 1 resolves correctly without the dropped ComposerDefaultFooter sibling. No prop or context contract changes are needed, and the non-expanded path is untouched because the new wrapper applies no style when isComposerFullSize is false.

What alternative solutions did you explore? (Optional)

We considered adding paddingBottom: insets.bottom + 20 to chatFooterFullCompose in ReportFooter, which would mask the web "bottom touches the edge" symptom by shrinking the chat-footer content box. We rejected it because the underlying overflow is unchanged — ComposerInputArea would still claim 100% of that (smaller) content box and ComposerDefaultFooter would still spill past the bottom, so the typing/exceeded-length indicators remain invisible and the mobile keyboard-clip case (which is a layout problem, not a padding one) is not addressed. We also considered moving ComposerDefaultFooter inside ComposerInputArea next to ComposerImportedState, but that re-couples the two components and breaks the explicit reason PR #90915 split them apart: letting EditOnlyReportActionCompose render the input area without the default footer.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-28 06:56:52 UTC.

Proposal

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

When the composer is expanded with the "expand" icon, the bottom of the composer is cut off: on web the last line sits flush against the bottom edge of the screen, and on mobile the bottom of the composer (and its footer row) is hidden behind the keyboard.

What is the root cause of that problem?

In full-size mode the footer row (offline indicator / typing indicator / character-limit warning) is rendered outside the height: '100%' region instead of sharing space with the composer box.

ComposerInputArea's outer wrapper applies styles.chatItemFullComposeRow ({height: '100%'}) when full-size, so it consumes the entire height of the full-size footer column (chatFooterFullCompose is also {height: '100%'}):

App/src/pages/inbox/report/ReportActionCompose/ComposerInputArea.tsx

Lines 23 to 43 in 377d37b

	return (
	<View
	testID={CONST.COMPOSER.TEST_ID.REPORT_ACTION_COMPOSE}
	style={[isComposerFullSize && styles.chatItemFullComposeRow]}
	>
	<ComposerLocalTime />
	<View style={isComposerFullSize ? styles.flex1 : {}}>
	<ComposerContainer>
	<ComposerDropZone>
	<ComposerBox>
	<ComposerActionButton />
	<ComposerInput />
	<ComposerEmojiPicker />
	<ComposerSendButton />
	</ComposerBox>
	</ComposerDropZone>
	</ComposerContainer>
	<ComposerImportedState />
	</View>
	</View>
	);

ReportActionCompose then renders ComposerInputArea and ComposerDefaultFooter as siblings, so the footer is laid out after a sibling that already takes 100% of the column height — leaving it zero vertical space and pushing it (and the bottom of the composer box) past the bottom edge:

App/src/pages/inbox/report/ReportActionCompose/ReportActionCompose.tsx

Lines 26 to 33 in 377d37b

	function ReportActionCompose({reportID}: ReportActionComposeProps) {
	return (
	<ComposerProvider reportID={reportID}>
	<ComposerInputArea />
	<ComposerDefaultFooter />
	</ComposerProvider>
	);
	}

This is a regression from PR #90915 ([NoQA] refactor: Split ReportActionCompose into more compositional components, merged 2026-05-26). Before that refactor the footer was rendered inside the OfflineWithFeedback container (now ComposerContainer), as a sibling of the composer box within the same flex: 1 content area — so the box flex-grew and the footer kept its natural height, both staying visible. The refactor moved the footer out to the top level, breaking that layout.

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

Render the footer back inside the full-size flex region (inside ComposerContainer), exactly where it lived before #90915. Pass it as children so EditOnlyReportActionCompose (which has no footer) is unaffected.

ReportActionCompose.tsx — move the footer inside ComposerInputArea:

 function ReportActionCompose({reportID}: ReportActionComposeProps) {
     return (
         <ComposerProvider reportID={reportID}>
-            <ComposerInputArea />
-            <ComposerDefaultFooter />
+            <ComposerInputArea>
+                <ComposerDefaultFooter />
+            </ComposerInputArea>
         </ComposerProvider>
     );
 }

ComposerInputArea.tsx — accept children and render them inside ComposerContainer, as a sibling of ComposerDropZone (the pre-#90915 position):

-function ComposerInputArea() {
+function ComposerInputArea({children}: PropsWithChildren) {
     ...
                 <ComposerContainer>
                     <ComposerDropZone>
                         <ComposerBox>
                             <ComposerActionButton />
                             <ComposerInput />
                             <ComposerEmojiPicker />
                             <ComposerSendButton />
                         </ComposerBox>
                     </ComposerDropZone>
+                    {children}
                 </ComposerContainer>
                 <ComposerImportedState />

(add import type {PropsWithChildren} from 'react';). With the footer back inside the flex: 1 content area, the composer box grows and the footer keeps its natural height, so the bottom of the composer and its footer stay visible — matching the non-expanded behavior on web, iOS and Android.

What alternative solutions did you explore? (Optional)

• Keep the footer as a sibling but change the wrapper from height: '100%' to flex: 1. Rejected: on native, SwipeableView wraps the composer in an unstyled View (no flex/height), so flex: 1 has no definite parent height to grow into and full-size would collapse. Restoring the footer inside the existing flex: 1 region reuses the layout that already worked on every platform.
• Add bottom padding/margin to the footer or cap the composer's max-height. Rejected: this treats the symptom (spacing) rather than the cause (the footer being outside the 100%-height region); the footer would still be squeezed out whenever the composer box fills the column.

[melvin-bot]

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

[melvin-bot]

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

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

The expanded composer styles set height: '100%' on three nested flex children of a flex parent — which React Native treats as the measured height of the parent, not the available height after siblings/keyboard are subtracted.

The parent container in ReportScreen.tsx#L142-L155 is flex: 1, justifyContent: 'flex-end', overflow: 'hidden', and it renders both ReportActionsList and ReportFooter as flex siblings:

<View style={[styles.flex1, styles.justifyContentEnd, styles.overflowHidden]}>
    <ReportActionsList />
    {shouldDeferNonEssentials ? <ReportActionComposePlaceholder /> : <ReportFooter />}
</View>

When the composer expands, three styles all kick in and ask for height: '100%':

• chatFooterFullCompose → { height: '100%', paddingTop: 20 } (no paddingBottom)
• chatItemFullComposeRow → { ...sizing.h100 }
• chatItemFullComposeBox → { ...flex.flex1, ...sizing.h100 }

100% resolves against the parent's intrinsic height (full report-actions-view-wrapper height), but flex still gives ReportActionsList its share of that same height first. So the footer is laid out at "100% of parent" below the actions list, and the bottom slice falls outside the parent — where overflow: 'hidden' clips it. On native, KeyboardAvoidingView (enabled in ReportScreen.tsx#L114) shrinks the screen by the keyboard height, but the explicit 100% doesn't shrink in response, so the keyboard further covers the bottom. On web, the absent paddingBottom puts the last composer row flush against the viewport edge.

This is fundamentally a misuse of height: '100%' on a flex child — it would be flex: 1 if the layout truly meant "take the remaining space."

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

Two parts. First, when the composer is full-size, stop rendering ReportActionsList so the footer can legitimately occupy all the flex space (this also avoids wasted re-renders of the message list under an opaque composer):

 <View style={[styles.flex1, styles.justifyContentEnd, styles.overflowHidden]}>
-    <ReportActionsList />
+    {!isComposerFullSize && <ReportActionsList />}
     {shouldDeferNonEssentials ? <ReportActionComposePlaceholder /> : <ReportFooter />}
 </View>

(isComposerFullSize is already available via useOnyx(\${ONYXKEYS.COLLECTION.REPORT_IS_COMPOSER_FULL_SIZE}${reportIDFromRoute}`) — same pattern used in [ReportFooter.tsx#L67`](https://github.com/Expensify/App/blob/main/src/pages/inbox/report/ReportFooter.tsx#L67).)

Second, replace height: '100%' with flex: 1 in the three full-size styles so the layout cooperates with KeyboardAvoidingView instead of fighting it, and add bottom breathing room:

 chatFooterFullCompose: {
-    height: '100%',
+    flex: 1,
     paddingTop: 20,
+    paddingBottom: 8,
 },

The same height: '100%' → flex: 1 swap applies to chatItemFullComposeRow and chatItemFullComposeBox (drop sizing.h100, keep flex.flex1). The {height: '100%', maxHeight: 'none'} inline style in Composer/implementation/index.tsx#L351 should also become {flex: 1, maxHeight: 'none'} so the <textarea> actually fills its flex parent without hard-coding a percentage.

Net effect: when expanded, the footer becomes the only flex child and naturally fills the parent; KAV's keyboard inset shrinks the parent, the footer shrinks with it, and the composer stays fully visible above the keyboard with a small bottom gap on web.

What alternative solutions did you explore? (Optional)

• Hide ReportActionsList via display: 'none' instead of conditional render — keeps the actions list mounted (preserves scroll position) but still re-runs its expensive virtualization on each Onyx tick. The user can't see it anyway while expanded, so the perf win of unmounting outweighs scroll restoration; we can persist scroll offset separately if needed.
• Add position: 'absolute' overlay for the expanded composer — would solve clipping but breaks KeyboardAvoidingView's padding/height behaviors and safe-area handling. Same reason MelvinBot rejected it.
• Bump only paddingBottom on chatFooterFullCompose without touching the flex/height issue — masks the web symptom but leaves the native keyboard-cover bug, since the root issue isn't padding, it's the height: '100%' not shrinking under KAV.

Heads up: This issue already has a canonical proposal from MelvinBot (comment) with the same root-cause family. My earlier attempt was auto-withdrawn as a duplicate. I'm posting this differently-framed angle (root cause: height: '100%' misuse on flex children + KAV interaction; fix: swap to flex: 1 everywhere rather than just hiding the sibling) but the dedup risk is high.