[HOLD for payment 2024-08-05] [$250] Bottom docked button views does not use correct SafeSpace in mobile

[m-natarajan]

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: 1.4.86-0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @shawnborton
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1718816465053499

Action Performed:

1. Open app
2. Tap avatar
3. Tap display name
4. Observe the space at the bottom of docked button

Expected Result:

There should be proper bottom SafeSpace below the button

Actual Result:

Bottom button is very close to the home bar

Workaround:

unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01cab23d89474f1097
• Upwork Job ID: 1804290933858433766
• Last Price Increase: 2024-06-28
• Automatic offers:
• allgandalf | Reviewer | 102958436
• truph01 | Contributor | 102958440

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @sakluger / @sakluger

[melvin-bot]

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

[truph01]

Proposal

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

• Bottom button is very close to the home bar

What is the root cause of that problem?

• We do not use includeSafeAreaPaddingBottom:
  

  App/src/pages/settings/Profile/DisplayNamePage.tsx

  Line 71 in 7561439

  includeSafeAreaPaddingBottom={false}

  
  so there is no safe area padding bottom is applied.

• Also, currently, the "Save" button has style:
  

  App/src/components/Form/FormWrapper.tsx

  Line 117 in 29e4c54

  containerStyles={[styles.mh0, styles.mt5, submitFlexEnabled ? styles.flex1 : {}, submitButtonStyles]}

• As we can see, the "Save" button is always at the bottom of the screen without any safe area on its bottom side.

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

• We should add an addtional style safeAreaPaddingBottomStyle.paddingBottom && styles.pb5 to the containerStyles:
  

  App/src/components/Form/FormWrapper.tsx

  Line 117 in 29e4c54

  containerStyles={[styles.mh0, styles.mt5, submitFlexEnabled ? styles.flex1 : {}, submitButtonStyles]}

                        containerStyles={[styles.mh0, styles.mt5, submitFlexEnabled ? styles.flex1 : {}, submitButtonStyles, safeAreaPaddingBottomStyle.paddingBottom && styles.pb5]}

• With the above change: In the device where there is no safe area padding-bottom (web, desktop), we do not need to add the additional padding-bottom value 20px, in other words, keep it as it is. In the devices that have safe area padding-bottom (native), add the addtional padding-bottom value as mentioned in here.

What alternative solutions did you explore? (Optional)

• We have two positions that add the padding-bottom to the screen:

• One in ScreenWrapper:
  

  App/src/components/ScreenWrapper.tsx

  Lines 239 to 242 in 403cecb

  	// We always need the safe area padding bottom if we're showing the offline indicator since it is bottom-docked.
  	if (includeSafeAreaPaddingBottom || (isOffline && shouldShowOfflineIndicator)) {
  	paddingStyle.paddingBottom = paddingBottom;
  	}

  
  and one in FormWrapper:
  

  App/src/components/Form/FormWrapper.tsx

  Line 105 in 403cecb

  style={[style, safeAreaPaddingBottomStyle.paddingBottom ? safeAreaPaddingBottomStyle : styles.pb5]}

• Let say the safeAreaPaddingBottomStyle.paddingBottom is 20. If we use includeSafeAreaPaddingBottom={true} in ScreenWrapper, both of these above padding styles are applied, the real padding-bottom will be 20*2 = 40. If we use includeSafeAreaPaddingBottom={false}, the real padding-bottom will be 20.

• In case of this bug, we already applied the safe area padding-bottom, 20, but the design team think it is not enough. And if we need to add more padding-bottom value in case applying safe area padding-bottom is not enough, we can update this:
  

  App/src/components/Form/FormWrapper.tsx

  Line 105 in 403cecb

  style={[style, safeAreaPaddingBottomStyle.paddingBottom ? safeAreaPaddingBottomStyle : styles.pb5]}

  
  to:

                style={[style, safeAreaPaddingBottomStyle.paddingBottom ? {paddingBottom: safeAreaPaddingBottomStyle + 15} : styles.pb5]}

In there, 15 is just the example, we can modify in the future.

[shawnborton]

@truph01 I think you have the right solution but I think we need to make sure we implement this on all pages that use the bottom-docked green button, not just the display name page.

[truph01]

@shawnborton We can do it by remove includeSafeAreaPaddingBottom={false} in all screen as I mentioned.

[neonbhai]

Proposal

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

Onboarding modal uses incorrect row hover style when hovering over the options

What is the root cause of that problem?

We disable safeAreaPadding for screens with forms as because it is already accounted for in Form Provider here

This is also mentioned in docs here:

App/contributingGuides/FORMS.md

Lines 323 to 331 in 6dc6f81

	Any `FormProvider.js` that has a button will also add safe area padding by default. If the `<FormProvider>` is inside a `<ScreenWrapper>`, we will want to disable the default safe area padding applied there e.g.
	```jsx
	<ScreenWrapper includeSafeAreaPaddingBottom={false}>
	<FormProvider>
	{...}
	</FormProvider>
	</ScreenWrapper>
	```

​

We still seem to be missing the extra padding below the Form Submit button as we have not configured the styles correctly

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

We will remove the bottom padding style.pb5 added here in #40473:

App/src/components/Form/FormWrapper.tsx

Line 105 in 29e4c54

style={[style, safeAreaPaddingBottomStyle.paddingBottom ? safeAreaPaddingBottomStyle : styles.pb5]}

​
and apply it here:

App/src/components/Form/FormWrapper.tsx

Line 117 in 29e4c54

containerStyles={[styles.mh0, styles.mt5, submitFlexEnabled ? styles.flex1 : {}, submitButtonStyles]}

[shawnborton]

Cool, I agree that removing includeSafeAreaPaddingBottom={false} is the way to go for native devices. cc @sakluger I think we are ready to open this one up.

[allgandalf]

@sakluger , can i be the C+ here? As i have context about this bug and it was found during the PR:

[melvin-bot]

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

[melvin-bot]

Current assignee @allgandalf is eligible for the External assigner, not assigning anyone new.

[sakluger]

@allgandalf sure thing!

[allgandalf]

Will review this today/tomorrow, reviewing an urgent deploy blocker today

[allgandalf]

I feel both of the proposals don't solve the issue at root, I am keeping this one open for proposal updates until tomorrow @neonbhai @truph01 if you can review this bug again and think of a better solution, or will ask on slack for more help!

You can go through my conversation with @shawnborton over the PR to understand more about the ideal solution

[truph01]

@allgandalf Thanks for your feedback.

Proposal updated

[allgandalf]

I think both the proposals still don't solve the issue at root, according to the C+ doc:

If C+ wants to submit a proposal to fix the issue they do so and tag the internal engineer (by adding “ 🎀👀🎀”) to review the proposal

🎀👀🎀

I would like to submit my proposal and get it reviewed by an internal engineer, if they agree with my proposal then i guess we need a new C+ and if they go with other proposals i can still review it.

Proposal

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

Form button is bottom docked, we need to have some padding added to it and not keep it close to the bottom.

What is the root cause of that problem?

This is a new requirement, we need to always have safe padding for forms.

In our docs :

App/contributingGuides/FORMS.md

Lines 323 to 324 in 6dc6f81

	Any `FormProvider.js` that has a button will also add safe area padding by default. If the `<FormProvider>` is inside a `<ScreenWrapper>`, we will want to disable the default safe area padding applied there e.g.

We previously added this to prevent extra bottom padding for form buttons.

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

The default value of includeSafeAreaPaddingBottom is true:

App/src/components/ScreenWrapper.tsx

Line 114 in 9d8e7fe

includeSafeAreaPaddingBottom = true,

So it was only for form inside screenwrappers that we added includeSafeAreaPaddingBottom to false.

So with the new requirement that we should always have bottom padding, we can remove the below condition:

App/src/components/ScreenWrapper.tsx

Lines 240 to 242 in 9d8e7fe

	if (includeSafeAreaPaddingBottom || (isOffline && shouldShowOfflineIndicator)) {
	paddingStyle.paddingBottom = paddingBottom;
	}

We will remove the if condition and always add padding. we should also now remove the usage of includeSafeAreaPaddingBottom as we always want to add bottom padding

• For desktop/macOS web, the value of bottom padding will be 0.
• For native devices, it will get the value of bottom padding and apply it successfully
• This will also solve the issue at root and will apply to all the places where we wrap form in screenwrapper

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

Triggered auto assignment to @puneetlath, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[truph01]

@allgandalf I think my solution and yours have the same implementation and output:

1. Output: Both my solution and yours make sure we always add the padding-bottom to the screen.
2. Implementation: Both solutions need to remove all the includeSafeAreaPaddingBottom={false} when using ScreenWrapper

• What do you think? Please correct me if I am wrong.

[allgandalf]

I felt that in your solution, you never mentioned that we should get ride of the condition all together because it is redundant and that is what i felt missing (i.e. issue is not solved at root), which is why i initially asked both of you to update your solutions. Also you mentioned to remove the use of includeSafeAreaPaddingBottom from the component usage, but didn't mention that the code is redundant now and we should get rid of the condition altogether

Lets wait on the internal engineers comments now :)

[truph01]

Proposal updated

• I add the new solution in alternative solution.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[allgandalf]

cool, thanks shawn, that’s what my proposal does 👍

[truph01]

@allgandalf

• I see that your solution will make the padding bottom to 23.79px + 23.79px in my example, but we need 23.79px + 20px right?
• Also, your solution introduce a regression with the screen that does not use form element as below:

Before	After

[truph01]

Proposal updated

• I updated main solution to match this comment

[truph01]

I updated comment

[sakluger]

Not overdue, Melvin, we're still discussing the proper solution.

[puneetlath]

It sounds like we have pretty much a working solution and the rest can be worked out in the PR. I'll assign @truph01 and @allgandalf can work with him in the PR to make sure we're not introducing any regressions. Thanks y'all!

[melvin-bot]

📣 @allgandalf 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[melvin-bot]

📣 @truph01 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[truph01]

@allgandalf PR #44761 is ready

[allgandalf]

Update

Still working through the PR, the updated changes are in a base component, so testing and working with the contributor to not cause any regression

[allgandalf]

Update

PR was deployed to staging, waiting to get it onto production

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.13-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix: Add more space to bottom docked button #44761

If no regressions arise, payment will be issued on 2024-08-05. 🎊

For reference, here are some details about the assignees on this issue:

• @allgandalf requires payment automatic offer (Reviewer)
• @truph01 requires payment automatic offer (Contributor)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@allgandalf] The PR that introduced the bug has been identified. Link to the PR:
• [@allgandalf] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@allgandalf] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@allgandalf] Determine if we should create a regression test for this bug.
• [@allgandalf] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@sakluger] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[sakluger]

All paid, thanks everyone.