[$250] Public room - Sign in section not fit on the screen

[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: v9.3.66-3
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-24948/folder/13176964/41237765/1387588069
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 16 pro/ 26.3.1
App Component: Other

Action Performed:

Precondition: Log out the app

1. Tap on link https://staging.new.expensify.com/r/1540486774487195 from Note
2. Observe the screen

Expected Result:

Sign in section should be fit on the screen

Actual Result:

Sign in button is hidden under the bottom navigator bar

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7144529_1777925478252.Xcut1701_1_.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022051405329358866703
• Upwork Job ID: 2051405329358866703
• Last Price Increase: 2026-05-04

[MelvinBot]

Proposal

What is the root cause of that problem?

When a logged-out user views a public room on iOS native, the ReportScreen renders inside a ScreenWrapper whose bottom safe area padding is reduced to 70% of the actual inset by iosSafeAreaInsetsPercentage: 0.7. On iPhone 16 Pro (bottom inset ~34px), this yields only ~24px of bottom padding instead of the full 34px.

The AnonymousReportFooter (containing the "Sign In" button) is rendered by ReportFooter at the bottom of the screen with mb5 (20px) on narrow layout. The ScreenWrapperContainer adds the reduced safe area as a bottom padding View. Together, the total bottom spacing (~44px) is not enough to clear the home indicator + any visual overlap on newer iPhone models, causing the sign-in button to be clipped or hidden.

Additionally, unlike root screens (Home, Settings) which pass TabBarBottomContent as bottomContent to their ScreenWrapper (providing extra tab-bar-height spacing), the ReportScreen does not pass any bottomContent, relying solely on the reduced safe area padding.

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

The AnonymousReportFooter wrapper in ReportFooter should account for the bottom safe area inset on iOS native. The fix should add bottom padding using useSafeAreaInsets() to the anonymous footer container in ReportFooter.tsx (similar to how other bottom-docked content handles safe areas), ensuring the sign-in button clears the home indicator on all iOS devices.

Alternatively, the iosSafeAreaInsetsPercentage (0.7) could be revisited — the 30% reduction was likely an aesthetic choice that doesn't account for newer devices with larger home indicator areas.

What alternative solutions did you explore?

1. Increasing mb5 to a larger margin — This would be a hardcoded fix that might not adapt to different device insets.
2. Having ReportScreen pass bottomContent to ScreenWrapper — This would bring it in line with root screens but may introduce unintended layout changes for authenticated users' composer area.

Investigation details

Key code path:

• AnonymousReportFooter renders the sign-in button
• ReportFooter wraps it with styles.chatFooter, mt4, mb5
• ScreenWrapperContainer applies paddingBottom = insets.bottom * 0.7
• SafeArea (native) only handles left/right edges, delegating bottom to ScreenWrapper
• getPlatformSafeAreaPadding applies the 0.7 multiplier on iOS

Platforms affected: iOS and Android native (per the issue checklist), where the home indicator / navigation bar can overlap content.

---

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.

[oqildev]

Proposal

What is the root cause of that problem?

On narrow layout, the wrapper around the anonymous Sign-In footer in ReportFooter.tsx:117 only adds a fixed mb5 (20px). The base chatFooter style at styles/index.ts:2130 has no bottom padding either. The bottom safe-area inset is rendered by ScreenWrapper as an empty sibling view at ScreenWrapperContainer.tsx:246, not on the footer itself.

On iPhone 16 Pro / iOS 26, the home-indicator inset is larger and the bottom tab bar from TabNavigatorBar.tsx:84-94 is overlaid on the screen content via a negative marginTop (utils/index.ts:2301). The combination leaves the Sign-In CTA inside AnonymousReportFooter flush against that overlay band, so the button visually sits under the bottom navigator bar.

The recent fix in commit 174c269738a only restored bottom padding for the wide layout branch (gated by !shouldUseNarrowLayout), so mobile was left without any safe-area-aware bottom space.

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

In ReportFooter.tsx:117, replace the fixed shouldUseNarrowLayout && styles.mb5 on the anonymous branch with a safe-area-aware bottom padding equal to Math.max(insets.bottom, 20), read from useSafeAreaPaddings. Use paddingBottom (not marginBottom) so the footer's background extends into the inset region. The same change should be applied to the other read-only branches (archived, blocked, system, admins-only) at lines 103, 131, 145, 159, since they share the same wrapper pattern.

To avoid double-counting the inset (because ScreenWrapper also paints the safe-area below children), pass includeSafeAreaPaddingBottom={false} to ScreenWrapper in ReportScreen.tsx:123 only when one of these read-only footers is rendered. The composer path is unchanged.

What alternative solutions did you explore? (Optional)

• Adding bottom padding only to anonymousRoomFooter style: leaves the other read-only footers exposed to the same regression.
• Removing the !shouldUseNarrowLayout guard added in 174c269738a to reuse offlineIndicatorContainer: would render a second OfflineIndicator on mobile because ScreenWrapper already renders one for small screens.
• Switching ReportScreen to enableEdgeToEdgeBottomSafeAreaPadding: too broad, also affects the composer and keyboard-offset behavior.
• Blaming tab-bar visibility: SCREENS.REPORT is not a root tab screen, so shouldHide resolves to true and opacity0 is applied. The bar is invisible; the clipping comes from the missing inset on the footer wrapper.

[melvin-bot]

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

[wildan-m]

Proposal

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

When a logged-out user opens the app via a public room deep link from a Note (for example tapping https://staging.new.expensify.com/r/1540486774487195) on iOS App or Android App, the sign-in screen that appears does not fit the viewport and the Continue button at the bottom of the form is partially or fully hidden behind the system home indicator (iOS) or navigation bar (Android). Reproducible on iOS 26.3.1 (iPhone 16 Pro) and Android per the bug report.

What is the root cause of that problem?

The anonymous deep-link sign-in flow opens SignInModal, which renders inside the Right Modal Navigator. On native narrow layout the right modal occupies the whole screen, so SignInModal's ScreenWrapper is what owns the bottom inset for the visible page.

SignInModal explicitly opts the modal's ScreenWrapper out of bottom safe-area padding:

App/src/pages/signin/SignInModal.tsx

Lines 64 to 70 in e4b605b

	return (
	<ScreenWrapper
	style={[StyleUtils.getBackgroundColorStyle(theme.PAGE_THEMES[SCREENS.RIGHT_MODAL.SIGN_IN].backgroundColor)]}
	includeSafeAreaPaddingBottom={false}
	shouldShowOfflineIndicator={false}
	testID="SignInModal"
	>

Because includeSafeAreaPaddingBottom is false, the layout below HeaderWithBackButton (the SignInPage → SignInPageLayout ScrollView containing LoginForm's Continue button, the offline indicator, the SignInHeroImage, and the footer columns) extends all the way down to physical screen height. The bottom strip equal to safeAreaInsets.bottom is therefore drawn under the iOS home indicator on iPhone 16 Pro and under Android's gesture/navigation bar.

The LoginForm Continue button sits inside SignInPageContent's flexGrow:2 form column, which on a small screen is positioned roughly two-thirds down the available height of SignInPageLayout's narrow ScrollView. With no bottom inset reserved by the modal wrapper, the button's vertical position lands precisely inside the area occluded by the home indicator / nav bar, matching the screenshot/video in the report.

The reason false was originally set here matches the comment on SignInPageWrapper:

App/src/pages/signin/SignInPage.tsx

Lines 344 to 355 in e4b605b

	return (
	// Bottom SafeAreaView is removed so that login screen svg displays correctly on mobile.
	// The SVG should flow under the Home Indicator on iOS.
	<ScreenWrapper
	shouldShowOfflineIndicator={false}
	shouldEnableMaxHeight
	style={[styles.signInPage, StyleUtils.getPlatformSafeAreaPadding({...safeAreaInsets, bottom: 0, top: isInNarrowPaneModal ? 0 : safeAreaInsets.top}, 1)]}
	testID="SignInPageWrapper"
	>
	<SignInPage ref={ref} />
	</ScreenWrapper>
	);

That comment notes the bottom SafeAreaView is removed so the standalone sign-in page's hero SVG can flow under the iOS home indicator. That trade-off is appropriate for the standalone full-screen sign-in page (where the SVG is the prominent visual at the bottom and there is no interactive button anchored there). It is not appropriate for SignInModal, where the user is presented with an interactive form whose primary action button must remain tappable. The same {false} flag was copied into SignInModal from day one and never reconciled with the modal's different layout requirements.

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

In SignInModal, stop disabling bottom safe-area padding on the modal's ScreenWrapper. Concretely, drop the includeSafeAreaPaddingBottom={false} prop on the ScreenWrapper returned by SignInModal (the prop's default value is true). After this change, the modal reserves the bottom safe-area inset, the ScrollView and its children (Continue button, offline indicator, hero image, footer) lay out within windowHeight − topInsets − bottomInsets, and the Continue button is rendered above the home indicator / gesture bar instead of behind it. The fix is platform-agnostic — the same ScreenWrapper change naturally produces the right inset on iOS and Android because useSafeAreaPaddings already returns the correct per-platform bottom value.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/89560-signinmodal-bottom-safe-area?expand=1

This change does not affect the standalone /signin route: that route renders SignInPageWrapper (the default export of SignInPage.tsx), which applies its own bottom: 0 via getPlatformSafeAreaPadding(...) so the hero SVG can still flow under the home indicator on the standalone page. Only SignInModal's wrapper is changed.

The check if (!Session.isAnonymousUser()) in SignInModal ensures this modal is only ever shown for the anonymous-deep-link flow, so no other contributor surface is impacted.

What alternative solutions did you explore? (Optional)

1. Pass enableEdgeToEdgeBottomSafeAreaPadding={true} instead of toggling includeSafeAreaPaddingBottom. This would put ScreenWrapper into edge-to-edge mode and delegate bottom-inset handling to inner scrollables (per the branching at the top of the wrapper):

   App/src/components/ScreenWrapper/index.tsx

   Lines 124 to 134 in e4b605b

   	// When the `enableEdgeToEdgeBottomSafeAreaPadding` prop is explicitly set, we enable edge-to-edge mode.
   	const isUsingEdgeToEdgeMode = enableEdgeToEdgeBottomSafeAreaPaddingProp !== undefined;
   	const enableEdgeToEdgeBottomSafeAreaPadding = enableEdgeToEdgeBottomSafeAreaPaddingProp ?? false;
   	const {insets, safeAreaPaddingBottomStyle} = useSafeAreaPaddings(isUsingEdgeToEdgeMode);
   	// We enable all of these flags by default, if we are using edge-to-edge mode.
   	const shouldSmallScreenOfflineIndicatorStickToBottom = shouldSmallScreenOfflineIndicatorStickToBottomProp ?? isUsingEdgeToEdgeMode;
   	const shouldKeyboardOffsetBottomSafeAreaPadding = shouldKeyboardOffsetBottomSafeAreaPaddingProp ?? isUsingEdgeToEdgeMode;
   	// We disable legacy bottom safe area padding handling, if we are using edge-to-edge mode.
   	const includeSafeAreaPaddingBottom = isUsingEdgeToEdgeMode ? false : includeSafeAreaPaddingBottomProp;

   Rejected because SignInPageLayout uses a custom @components/ScrollView whose contentContainer is laid out with flexGrow1 on native and is not wired into the edge-to-edge inset context the way FormProvider/SelectionList are. Switching to edge-to-edge mode here is a larger refactor with no behavioural win over simply re-enabling the legacy bottom padding on the modal's outer wrapper.

2. Add explicit paddingBottom: safeAreaInsets.bottom inside SignInPageContent only when rendered in the modal context. Rejected because it requires threading a new "isInModal" prop through SignInPage → SignInPageLayout → SignInPageContent, duplicates inset handling that ScreenWrapper already provides correctly via useSafeAreaPaddings, and re-introduces the isInModal coupling that the TS conversion (7a5c68ad9d2) deliberately removed.

[melvin-bot]

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

[github-actions]

⚠️ @oqildev Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[twilight2294]

Proposal

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

When a logged-out user opens a public room, the Sign In button in the anonymous footer is hidden behind the bottom tab bar and can't be tapped.

What is the root cause of that problem?

All 6 non-composer footer branches in ReportFooter apply shouldUseNarrowLayout && styles.mb5 as their bottom margin — that's marginBottom: 20. The tab bar uses getTabBarNarrowStyle which sets marginTop: -(variables.bottomTabHeight + safeAreaPaddingBottom), overlaying the bottom 72px+ of screen content. With only 20px of clearance, the footer sits behind the tab bar.

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

Replace styles.mb5 with {marginBottom: variables.bottomTabHeight} in all 6 non-composer branches of ReportFooter (lines 103, 117, 131, 145, 159, 183). Add import variables from '@styles/variables' at the top.

+ import variables from '@styles/variables';

// All 6 non-composer branches (archived, anonymous, blocked, system chat, admins-only, read-only):
- <View style={[styles.chatFooter, styles.mt4, shouldUseNarrowLayout && styles.mb5]}>
+ <View style={[styles.chatFooter, styles.mt4, shouldUseNarrowLayout && {marginBottom: variables.bottomTabHeight}]}>

This is the exact same pattern already used in HomePage and SearchPageNarrow for the same problem. No new hooks, no new styles.

What alternative solutions did you explore?

MelvinBot and oqildev both propose using useSafeAreaInsets() / useSafeAreaPaddings to compute a dynamic bottom padding. That's the wrong abstraction here — the inset is the distance from screen edge to content (home indicator); the actual problem is clearance from the tab bar, which is variables.bottomTabHeight. On a device with no home indicator the safe area bottom is 0, but the tab bar is still 72px tall and would still obscure the footer. Using Math.max(insets.bottom, 20) as oqildev proposes yields ~34px on an iPhone 16 Pro, which is still less than the 72px needed. variables.bottomTabHeight is the right constant, and it's already the established codebase pattern for this exact scenario.

wildan-m's proposal targets SignInModal.tsx and includeSafeAreaPaddingBottom — that's a different codepath (the full-screen sign-in modal via deep link), not the AnonymousReportFooter visible when browsing a public room while logged out.

[wildan-m]

Proposal updated — added compare branch with implementation.