[Due for payment 2026-04-17] [$250] mweb Safari - Contacts - Huge empty space appears on the modal with "Remove" option

[izarutskaya]

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.50-2
Reproducible in staging?: Yes
Reproducible in production?:
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://github.com/Expensify/Expensify/issues/509485
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team
Bug source: undefined
Device used: undefined
App Component: undefined

Action Performed:

1. Go to staging.new.expensify.com
2. Go to Account > Profile > Contact methods.
3. Tap New contact method.
4. Enter magic code.
5. Enter any email > Add.
6. On magic code page, tap on the input to open the keyboard.
7. Tap 3-dot menu on the top right.

Expected Result:

Empty space will not appear on the modal with "Remove" option.

Actual Result:

Huge empty space appears on the modal with "Remove" option.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7087088_1771940372999.ScreenRecording_02-24-2026_21-36-21_1.1.mp4

Bug7087088_1774722482014.repro.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @neerajbachani

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022038558018328273470
• Upwork Job ID: 2038558018328273470
• Last Price Increase: 2026-03-30

[MelvinBot]

Proposal

What is the root cause of that problem?

On small screens (mWeb), the ThreeDotsMenu's PopoverMenu renders as a BOTTOM_DOCKED Modal via PopoverWithMeasuredContent — not a positioned popover.

For BOTTOM_DOCKED modals, there is a Safari-specific workaround in ModalStyleUtils.ts:236-239 that sets maxHeight: ${windowDimensions.windowHeight}px on the modal container. This was added because Safari doesn't support interactive-widget=resizes-content.

The modal container also has overflow: hidden and justify-content: center. On iOS Safari, the combination of max-height (set to the full viewport height) with overflow: hidden on a flex item can cause the element to expand to its max-height rather than staying content-sized. Since maxHeight equals the full window height, the modal container becomes nearly full-screen even though it only contains a single "Remove" menu item. The item is then centered vertically (due to justify-content: center), creating the large empty space above and below it.

Additionally, the PopoverMenu inner View uses styles.flex1 on web (PopoverMenu.tsx:625), which can contribute to the expansion when Safari's layout engine resolves the flex sizing.

This only reproduces on iOS mWeb Safari because:

1. The Safari-specific maxHeight: windowHeight workaround only applies when isMobileSafari() is true
2. Safari's flex layout engine handles max-height + overflow: hidden differently than Chrome/Firefox
3. The keyboard being open when the 3-dot menu is tapped adds a complicating factor — onThreeDotsButtonPress dismisses the keyboard concurrently with the modal opening, and Safari's viewport transition during keyboard dismiss may exacerbate the sizing issue

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

In PopoverMenu.tsx, conditionally avoid applying styles.flex1 on the inner View when on small screens, since the content renders as a BOTTOM_DOCKED modal (not a popover) and should be content-sized rather than expanding to fill available space:

At line 625, change isWeb ? styles.flex1 : styles.flexGrow1 to only apply flex1 on large screens where the popover positioning actually needs it. On small screens (where the component becomes a bottom-docked modal), the View should not expand.

If this alone doesn't fully resolve the issue, the Safari maxHeight workaround in ModalStyleUtils.ts:239 should also be revisited — instead of setting maxHeight to the full windowHeight, it could use window.visualViewport?.height (which correctly reflects the keyboard-reduced viewport on Safari) or be scoped to only apply for modals that contain scrollable form content (the original use case per PR #62799), not for small popover menus.

What alternative solutions did you explore? (Optional)

1. Use useCachedViewportHeight in BaseModal: useWindowDimensions already has a mechanism to cache viewport height for iOS WebKit, but BaseModal doesn't opt into it. Passing useCachedViewportHeight=true would make windowHeight reflect the visual viewport, but this could have unintended side effects for other modal types.

2. Dismiss keyboard before opening modal: Adding a small delay between keyboard dismiss and modal open (so the viewport is stable when the modal renders). This treats the symptom rather than the root cause and would add UX latency.

3. Remove overflow: hidden from BOTTOM_DOCKED container style: This would avoid the Safari layout bug, but overflow: hidden is needed for the border radius clipping.

---

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.

[melvin-bot]

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

[melvin-bot]

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

[MobileMage]

Proposal

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

When the magic code input has keyboard focus on mweb Safari and the user taps the three-dot menu button, a bottom-docked modal appears with a large empty space above the "Remove" option equal roughly to the keyboard height.

What is the root cause of that problem?

On mweb Safari, window.innerHeight (used by React Native's useWindowDimensions) does not shrink when the software keyboard appears — only window.visualViewport.height does. The BOTTOM_DOCKED modal in ModalStyleUtils.ts uses height: '100%' with justifyContent: 'flex-end', which on web anchors the content to the bottom of the full document height container. When the keyboard is open, the visible area is the upper portion of that document, not the bottom, so the modal's content renders offscreen below the visual viewport. The keyboard then dismisses, and the viewport snaps to show the bottom of the document — but the user sees the bottom-docked sheet preceded by a huge blank space that was previously hidden behind the keyboard.

The onThreeDotsButtonPress handler in ContactMethodDetailsPage calls blurActiveElement() and KeyboardUtils.dismiss() synchronously and then immediately opens the popover. On non-Safari mobile browsers this is fine because interactive-widget=resizes-content causes the layout to shrink with the keyboard. Safari does not support that meta value, so the layout stays full-height while only the visual viewport shrinks, creating the empty space.

App/src/pages/settings/Profile/Contacts/ContactMethodDetailsPage.tsx

Lines 354 to 359 in 84815b8

	onThreeDotsButtonPress={() => {
	// Hide the keyboard when the user clicks the three-dot menu.
	// Use blurActiveElement() for mWeb and KeyboardUtils.dismiss() for native apps.
	blurActiveElement();
	KeyboardUtils.dismiss();
	}}

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

The popover menu should only open after the keyboard has fully dismissed. On mweb Safari, we can listen to the visualViewport resize event and wait for the viewport height to stabilise (i.e. reach the initial full height) before triggering the menu open. For all other platforms the existing behaviour (open immediately) is preserved.

Change onThreeDotsButtonPress in ContactMethodDetailsPage to defer the popover open until the keyboard is gone on mobile Safari:

App/src/pages/settings/Profile/Contacts/ContactMethodDetailsPage.tsx

Lines 347 to 360 in 84815b8

	>
	<HeaderWithBackButton
	title={formattedContactMethod}
	threeDotsMenuItems={getThreeDotsMenuItems()}
	onBackButtonPress={() => Navigation.goBack(ROUTES.SETTINGS_CONTACT_METHODS.getRoute(backTo))}
	shouldShowThreeDotsButton={getThreeDotsMenuItems().length > 0}
	shouldOverlayDots
	onThreeDotsButtonPress={() => {
	// Hide the keyboard when the user clicks the three-dot menu.
	// Use blurActiveElement() for mWeb and KeyboardUtils.dismiss() for native apps.
	blurActiveElement();
	KeyboardUtils.dismiss();
	}}
	/>

+import {isMobileSafari} from '@libs/Browser';
+import addViewportResizeListener from '@libs/VisualViewport';

 <HeaderWithBackButton
     title={formattedContactMethod}
     threeDotsMenuItems={getThreeDotsMenuItems()}
     onBackButtonPress={() => Navigation.goBack(ROUTES.SETTINGS_CONTACT_METHODS.getRoute(backTo))}
     shouldShowThreeDotsButton={getThreeDotsMenuItems().length > 0}
     shouldOverlayDots
     onThreeDotsButtonPress={() => {
         blurActiveElement();
         KeyboardUtils.dismiss();
+        // On mweb Safari the layout height never shrinks with the keyboard, so the
+        // bottom-docked modal opens with a blank space equal to the keyboard height.
+        // Wait for the visualViewport to reach full height before opening the menu.
+        if (isMobileSafari() && window.visualViewport) {
+            const initialHeight = window.visualViewport.height;
+            const removeListener = addViewportResizeListener(() => {
+                if (!window.visualViewport || window.visualViewport.height <= initialHeight) {
+                    return;
+                }
+                removeListener();
+                onThreeDotsPress?.();
+            });
+            return;
+        }
     }}
 />

Because ThreeDotsMenu exposes onThreeDotsPress via threeDotsMenuRef, the HeaderWithBackButton already wires an onThreeDotsButtonPress prop that can be used to intercept the press. Alternatively, the same deferral logic can live inside ThreeDotsMenu.onThreeDotsPress gated on isMobile() + isMobileSafari() so it benefits all popover menus, not just this one screen.

A simpler, more broadly applicable fix is to apply the deferral inside ThreeDotsMenu itself:

 const onThreeDotsPress = () => {
     if (isPopupMenuVisible) {
         hidePopoverMenu();
         return;
     }
     hideProductTrainingTooltip?.();
     buttonRef.current?.blur();

+    const openMenu = () => {
         if (getMenuPosition) {
             getMenuPosition?.().then((value) => {
                 setPosition(value);
                 showPopoverMenu();
             });
         } else {
             showPopoverMenu();
         }
         onIconPress?.();
+    };
+
+    // On mweb Safari, wait for the keyboard to fully dismiss before opening the
+    // bottom-docked modal, otherwise empty space equal to the keyboard height appears.
+    if (isMobile() && window.visualViewport) {
+        const heightOnPress = window.visualViewport.height;
+        const removeListener = addViewportResizeListener(() => {
+            if (!window.visualViewport || window.visualViewport.height <= heightOnPress) {
+                return;
+            }
+            removeListener();
+            openMenu();
+        });
+        // If keyboard was not open (viewport already full), open immediately.
+        if (window.visualViewport.height >= (window.visualViewport.width > window.visualViewport.height ? window.screen.height : window.screen.width)) {
+            removeListener();
+            openMenu();
+        }
+        return;
+    }
+
+    openMenu();
 };

The preferred approach is the ThreeDotsMenu fix since it covers all places where a bottom-docked popover can be opened while the keyboard is active, not just the contacts page.

What alternative solutions did you explore? (Optional)

An alternative would be to use visualViewport.height instead of window.innerHeight when computing the maxHeight of the BOTTOM_DOCKED modal container in ModalStyleUtils.ts. However, windowHeight flows from useWindowDimensions, which deliberately uses window.innerHeight to keep layout dimensions stable during keyboard transitions. Changing that value would cause layout thrashing across the entire app. Deferring the menu open until the keyboard is dismissed is a more targeted and side-effect-free fix.

[trasnake87]

Proposal

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

On mWeb Safari, when the keyboard is open on the contact method magic code page and the user taps the three-dot menu, the bottom-docked modal with the "Remove" option displays a huge empty space, making the modal appear nearly full-screen for a single menu item.

What is the root cause of that problem?

The ColorSchemeWrapper component on web (src/components/ColorSchemeWrapper/index.tsx#L10) wraps all modal children in a <View style={[styles.flex1, ...]}>. The flex: 1 style (which maps to flex-grow: 1; flex-shrink: 1; flex-basis: 0%) is applied inside BaseModal's inner container (src/components/Modal/BaseModal.tsx#L380). For BOTTOM_DOCKED modals on Safari, the parent container has a Safari-specific maxHeight set to the full viewport height along with overflow: hidden. The flex-basis: 0% on ColorSchemeWrapper tells Safari's layout engine to start the element at zero size and grow to fill all available space — which on Safari becomes the entire maxHeight (full viewport). This causes the ColorSchemeWrapper to expand to the full viewport height, creating the huge empty space around the single "Remove" menu item.

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

We should change ColorSchemeWrapper/index.tsx to use flexGrow1 instead of flex1. This keeps flex-basis: auto (the default), meaning the element sizes to its content first and only grows when the parent explicitly distributes extra space. On Safari, this prevents the wrapper from expanding to the full maxHeight since flex-basis: auto respects the intrinsic content size.

--- a/src/components/ColorSchemeWrapper/index.tsx
+++ b/src/components/ColorSchemeWrapper/index.tsx
@@ -7,7 +7,7 @@ function ColorSchemeWrapper({children}: React.PropsWithChildren): React.ReactElem
     const theme = useTheme();
     const styles = useThemeStyles();
 
-    return <View style={[styles.flex1, styles.colorSchemeStyle(theme.colorScheme)]}>{children}</View>;
+    return <View style={[styles.flexGrow1, styles.colorSchemeStyle(theme.colorScheme)]}>{children}</View>;
 }
 
 export default ColorSchemeWrapper;

This is a minimal, targeted change that fixes the Safari expansion issue for BOTTOM_DOCKED modals while preserving the grow behavior needed for full-screen modals (like RIGHT_DOCKED and CENTERED), since those modals' containers have explicit heights that naturally constrain the layout.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[JasimMalook]

Proposal
Please re-state the problem that we are trying to solve in this issue.
On mweb Safari, when the keyboard is open and the user taps the three-dot menu, a bottom-docked modal appears with a huge empty space above the "Remove" option. This only happens on iOS Safari, not Chrome or other browsers.
What is the root cause of that problem?
The root cause is in ModalStyleUtils.ts. For BOTTOM_DOCKED modals on Safari, the code sets maxHeight: windowHeight where windowHeight comes from useWindowDimensions which uses window.innerHeight. On Safari, window.innerHeight does NOT shrink when the keyboard opens — only window.visualViewport.height reflects the actual visible area.
So when the keyboard is open:

window.innerHeight = full screen height (e.g. 844px)
window.visualViewport.height = visible area above keyboard (e.g. 500px)

The modal gets maxHeight: 844px but the visible viewport is only 500px. The modal container becomes nearly full-screen with justify-content: center, pushing the single "Remove" item to the center of an 844px container — creating ~172px of empty space above and below it.
This is purely a Safari issue because other browsers support interactive-widget=resizes-content which makes window.innerHeight shrink with the keyboard. Safari ignores this.
What changes do you think we should make in order to solve the problem?
The fix should be in ModalStyleUtils.ts — use window.visualViewport?.height instead of windowHeight when computing maxHeight for BOTTOM_DOCKED modals on Safari:
ts// ModalStyleUtils.ts — Safari BOTTOM_DOCKED modal maxHeight fix
if (isMobileSafari()) {
const safeHeight = window.visualViewport?.height ?? windowDimensions.windowHeight;
modalStyle.push({maxHeight: safeHeight});
}
This is a one-line targeted fix that:

Only applies to Safari (isMobileSafari() guard)
Only applies to BOTTOM_DOCKED modals (existing condition)
Uses the correct visible height that already accounts for keyboard
Requires no event listeners, no delays, no async logic
Does not affect useWindowDimensions or layout elsewhere in the app

Why this is better than deferring the modal open:
Deferring via visualViewport resize listener (MobileMage's approach) adds async complexity — what if the keyboard doesn't dismiss? What if visualViewport resize fires multiple times? The fix also has to be added to every screen that has this pattern. A fix in ModalStyleUtils.ts solves it once for ALL bottom-docked modals everywhere in the app.
Why this is better than fixing PopoverMenu.tsx flex:
The flex1 issue in PopoverMenu.tsx is a secondary contributing factor. The primary cause is the incorrect maxHeight value. Even without flex1, a container with maxHeight: 844px and justify-content: center will create empty space around a small content item.
What alternative solutions did you explore?
Adding useCachedViewportHeight to BaseModal was considered but it has side effects for other modal types. Removing overflow: hidden from the container breaks border radius clipping. The visualViewport resize listener approach works but is async and must be applied per-screen rather than once globally.

Contributor details
Your Expensify account email: jasimmalook@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~014c25762fc2275193