[Due for payment 2025-05-05] [$250] mweb-card-Delete modal have extra bottom margin in card feed page

[nlemma]

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.1.26-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: No, reproducible on hybrid only
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): Slottwo1 dooriya1@gmail.com
Issue reported by: Applause Internal Team
Device used: Redminote 10s android 13
App Component: Other

Action Performed:

1. Go to https://staging.new.expensify.com/home
2. Go to workspace settings - company card
3. Create an American card
4. Tap settings - delete

Expected Result:

Delete modal must not have extra bottom margin in card feed page.

Actual Result:

Delete modal have extra bottom margin in card feed page.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6798083_1744285683967.Screenrecorder-2025-04-10-17-06-04-157.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021910415189943815409
• Upwork Job ID: 1910415189943815409
• Last Price Increase: 2025-04-17

Issue Owner

Current Issue Owner: @maddylewis

[melvin-bot]

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

[linhvovan29546]

Proposal

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

mweb-card-Delete modal have extra bottom margin in card feed page

What is the root cause of that problem?

The ConfirmModal uses the BOTTOM_DOCKED type when isSmallScreenWidth is true. By default, shouldAddBottomSafeAreaPadding is set to true for BOTTOM_DOCKED, which results in extra bottom.

App/src/components/ConfirmModal.tsx

Line 163 in 248f253

type={isSmallScreenWidth ? CONST.MODAL.MODAL_TYPE.BOTTOM_DOCKED : CONST.MODAL.MODAL_TYPE.CONFIRM}

App/src/styles/utils/generators/ModalStyleUtils.ts

Line 215 in 248f253

shouldAddBottomSafeAreaPadding = true;

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

We should conditionally set shouldAddBottomSafeAreaPadding to false on MWeb(or only for mobile chrome):

App/src/styles/utils/generators/ModalStyleUtils.ts

Line 215 in 248f253

shouldAddBottomSafeAreaPadding = true;

         shouldAddBottomSafeAreaPadding = !isMobileChrome(); // or isMobile for both android and ios

Note: On iOS MWeb, there’s also a slight extra bottom margin, so we can use isMobile() for consistency mweb.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None, UI bug

What alternative solutions did you explore? (Optional)

• In the ConfirmModal we can pass enableEdgeToEdgeBottomSafeAreaPadding is true if the platform is mweb
  https://github.com/Expensify/App/blob/main/src/components/ConfirmModal.tsx#L163

            enableEdgeToEdgeBottomSafeAreaPadding={isMobileChrome()}

• We can introduced new prop to disable the padding bottom for mweb

[bernhardoj]

Proposal

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

Delete card modal has extra spaces on mobile web.

What is the root cause of that problem?

This actually happens to every bottom-docked modal. shouldAddBottomSafeAreaPadding is true for bottom-docked modal and on mobile web, the inset is 0, so it fallbacks to padding top.

App/src/styles/utils/index.ts

Lines 606 to 613 in bf6f3d6

	// use fallback value for safeAreaPaddingBottom to keep padding bottom consistent with padding top.
	// More info: issue #17376
	const safeAreaPaddingBottomWithFallback = insets.bottom === 0 && typeof modalContainerStyle.paddingTop === 'number' ? modalContainerStyle.paddingTop ?? 0 : safeAreaPaddingBottom;
	return {
	marginTop: getCombinedSpacing(modalContainerStyle.marginTop, safeAreaPaddingTop, shouldAddTopSafeAreaMargin),
	marginBottom: getCombinedSpacing(modalContainerStyle.marginBottom, safeAreaPaddingBottomWithFallback, shouldAddBottomSafeAreaMargin),
	paddingTop: getCombinedSpacing(modalContainerStyle.paddingTop, safeAreaPaddingTop, shouldAddTopSafeAreaPadding),
	paddingBottom: getCombinedSpacing(modalContainerStyle.paddingBottom, safeAreaPaddingBottomWithFallback, shouldAddBottomSafeAreaPadding),

App/src/styles/utils/generators/ModalStyleUtils.ts

Lines 197 to 215 in bf6f3d6

	case CONST.MODAL.MODAL_TYPE.BOTTOM_DOCKED:
	modalStyle = {
	...modalStyle,
	...{
	alignItems: 'center',
	justifyContent: 'flex-end',
	},
	};
	modalContainerStyle = {
	width: '100%',
	borderTopLeftRadius: variables.componentBorderRadiusLarge,
	borderTopRightRadius: variables.componentBorderRadiusLarge,
	paddingTop: variables.componentBorderRadiusLarge,
	justifyContent: 'center',
	overflow: 'hidden',
	boxShadow: theme.shadow,
	};
	shouldAddBottomSafeAreaPadding = true;

This doesn't happen on native because there is an inset value there. The fallback logic was added in #17376 to add extra padding at the bottom of the modal. But adding it based on whether the platform has a bottom inset or not makes it inconsistent.

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

We have 2 choices. Add the padding bottom to all platforms by padding the padding bottom here

App/src/styles/utils/generators/ModalStyleUtils.ts

Lines 197 to 215 in bf6f3d6

	case CONST.MODAL.MODAL_TYPE.BOTTOM_DOCKED:
	modalStyle = {
	...modalStyle,
	...{
	alignItems: 'center',
	justifyContent: 'flex-end',
	},
	};
	modalContainerStyle = {
	width: '100%',
	borderTopLeftRadius: variables.componentBorderRadiusLarge,
	borderTopRightRadius: variables.componentBorderRadiusLarge,
	paddingTop: variables.componentBorderRadiusLarge,
	justifyContent: 'center',
	overflow: 'hidden',
	boxShadow: theme.shadow,
	};
	shouldAddBottomSafeAreaPadding = true;

Or remove the fallback bottom padding.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

[melvin-bot]

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

[melvin-bot]

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

[inwake]

🚨 Edited by proposal-police: This proposal was edited at 2025-04-10 21:22:27 UTC.

Contributor details
Expensify account email: vitaliy@inwake.io
Upwork Profile Link: https://www.upwork.com/freelancers/vitaliyd33

Proposal

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

There is an unexpected extra bottom margin appearing in the modal on the card feed page, causing incorrect spacing in the layout.

What is the root cause of that problem?

I took a look at your current implementation, and I believe the unexpected margin issue in the modal may be occurring because you're using Dimensions.get('window') from the variables object, which returns static dimensions that do not update when the screen changes (e.g., device rotation or resizing).
This can cause incorrect layout calculations leading to extra spacing or margins.

React Native provides the built-in hook useWindowDimensions, which automatically updates dimensions and triggers re-renders when window dimensions change, ensuring responsive layouts remain accurate across different devices or orientations.
It seems you are already using this hook in other places, but not here.

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

• Replace the use of the static Dimensions.get('window') calls with the React-provided hook useWindowDimensions().
• Update the component logic to depend on dynamic values from this hook, ensuring consistent behavior and layout calculations.

This should immediately resolve the extra margin issue you're seeing, especially if it's related to dynamic window dimension changes.

I've implemented similar responsive solutions extensively in my own React Native applications, and this fix should be straightforward, effective, and maintainable.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

• Verify that the modal displays correct margins on different device sizes (small, medium, and large screens).
• Test device rotation (portrait to landscape) to confirm that margins stay consistent after dimension changes.
• Simulate dynamic resizing (especially on web and tablet layouts) and ensure no extra margins appear.

What alternative solutions did you explore? (Optional)

An alternative approach could be to manually add event listeners for dimension changes and force updates manually, but using useWindowDimensions() is the cleaner, more reliable, and standard approach in React Native.

[melvin-bot]

📣 @inwake! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[github-actions]

⚠️ @inwake 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).