[$250] "Next" and "split" button moves a bit when navigate back

@youssef-lr

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.71-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
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: @youssef-lr
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1715122550547929

Action Performed:

Launch the app
Tap the fab > Split expense
Enter amount and Choose from contacts
Tap Next > Tap the back arrow
Tap Next again

Expected Result:

No visual issues when navigating back and forth

Actual Result:

After step 4 and 5 "Next" and "Split" button moves

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

RPReplay_Final1715122397.MP4

RPReplay_Final1715186635.MP4

Add any screenshot/video evidence

View all open jobs on GitHub

Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01419f469e7473b289
Upwork Job ID: 1789073733749583872
Last Price Increase: 2024-05-10
Automatic offers:

Ollyws | Reviewer | 0
bernhardoj | Contributor | 0

Issue Owner

Current Issue Owner: @Ollyws

@alexpensify

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

Proposal

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

The next and split button moves down when navigating between pages while a keyboard is open.

What is the root cause of that problem?

The button is wrapped with FixedFooter.

App/src/components/FixedFooter.tsx

Lines 17 to 29 in 807c945

    
           function FixedFooter({style, children}: FixedFooterProps) { 
        
               const {isKeyboardShown} = useKeyboardState(); 
        
               const insets = useSafeAreaInsets(); 
        
               const styles = useThemeStyles(); 
        
               if (!children) { 
        
                   return null; 
        
               } 
        
               const shouldAddBottomPadding = isKeyboardShown || !insets.bottom; 
        
               return <View style={[styles.ph5, shouldAddBottomPadding && styles.pb5, styles.flexShrink0, style]}>{children}</View>; 
        
           }

The confirmation page uses BaseOptionsSelector which uses FixedFooter.

In FixedFooter, we add a bottom padding if the keyboard shown state is true. When we move to the confirmation page while the keyboard is shown, both the padding-bottom from FixedFooter and the confirmation page itself are added. After the keyboard state is fully hidden, the padding-bottom from FixedFooter is gone, so the button moves down a bit.

In the money request participants page, we are using BaseSelectionList and only add the padding-bottom if the keyboard is hidden. The list footer also uses FixedFooter.

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 517 to 518 in 807c945

    
           {({safeAreaPaddingBottomStyle}) => ( 
        
               <View style={[styles.flex1, !isKeyboardShown && safeAreaPaddingBottomStyle, containerStyle]}>

So, when we open/close the keyboard, you will see the button move up/down based on the keyboard state.

I believe the reason we add the padding-bottom in FixedFooter only when the keyboard is shown is because the padding-bottom in BaseSelectionList is gone when the keyboard is shown. It's to replace the removed padding-bottom so the list footer content has a padding-bottom.

Without padding-bottom (if we remove the padding-bottom logic from FixedFooter):

The reason we don't apply padding-bottom in BaseSelectionList when the keyboard is shown is to fix a small blank space above the keyboard. This is because of the padding bottom that we apply to the list. If we apply it (includeSafeAreaPaddingBottom) to the ScreenWrapper, the issue won't happen

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

Remove the padding-bottom logic based on the keyboard state from FixedFooter. Then, we will apply the padding-bottom in BaseSelectionList if there is a footer.

App/src/components/SelectionList/BaseSelectionList.tsx

Line 518 in 807c945

    
           <View style={[styles.flex1, !isKeyboardShown && safeAreaPaddingBottomStyle, containerStyle]}>

(!isKeyboardShown || !!footerContent || showConfirmButton) && safeAreaPaddingBottomStyle

What alternative solutions did you explore? (Optional)

Remove the safe area padding bottom from BaseSelectionList and enable includeSafeAreaPaddingBottom to every page that uses BaseSelectionList. Currently, all pages that use BaseSelectionList disables includeSafeAreaPaddingBottom to not have double padding bottom.

On my testing list, I'll get to it soon.

@alexpensify

@alexpensify I think this fits as a general improvement to the UI and not particularly tied to any project. It makes the UI looks glitchy and unpolished. Can we get a C+ assigned to review the proposal? Also I think we need to tackle this everywhere in the UI where it happens, and not just the two pages mentioned in this issue.

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

@Ollyws

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

@kevinksullivan

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

@kevinksullivan

Heads up, I will be offline until Tuesday, May 28, 2024, and will not actively watch over this GitHub during that period.

@kevinksullivan - While I'm offline, I need help here completing the payment process after this one clears the 7-day period. Thanks!

@kevinksullivan

Thanks, @kevinksullivan for the help here. I'm back online and taking over again as the BZ member. Tomorrow, I'll start the payment process since it looks like automation failed in this GH.

@bernhardoj

Payouts due: 2024-05-29

Contributor: $250 @bernhardoj
Contributor+: $250 @Ollyws

Upwork job is here.

@bernhardoj

I've paid @bernhardoj via Upwork. @Ollyws, please accept the invite and I can complete the payment process. Thanks!

Requested in ND.

Awesome, and sorry for the confusion. I didn't see you listed in the SO. Closing since the final payment will happen in Chat.

@Ollyws

$250 approved for @Ollyws

Navigation Menu

Repository navigation

[$250] "Next" and "split" button moves a bit when navigate back #41855

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

18 remaining items

Heads up, I will be offline until Tuesday, May 28, 2024, and will not actively watch over this GitHub during that period.

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	function FixedFooter({style, children}: FixedFooterProps) {
	const {isKeyboardShown} = useKeyboardState();
	const insets = useSafeAreaInsets();
	const styles = useThemeStyles();

	if (!children) {
	return null;
	}

	const shouldAddBottomPadding = isKeyboardShown \|\| !insets.bottom;

	return <View style={[styles.ph5, shouldAddBottomPadding && styles.pb5, styles.flexShrink0, style]}>{children}</View>;
	}

	{({safeAreaPaddingBottomStyle}) => (
	<View style={[styles.flex1, !isKeyboardShown && safeAreaPaddingBottomStyle, containerStyle]}>

[$250] "Next" and "split" button moves a bit when navigate back #41855

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

melvin-bot commented on May 8, 2024

bernhardoj commented on May 9, 2024

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

alexpensify commented on May 10, 2024

youssef-lr commented on May 10, 2024

melvin-bot commented on May 10, 2024

melvin-bot commented on May 10, 2024

18 remaining items

melvin-bot commented on May 17, 2024

alexpensify commented on May 17, 2024

Heads up, I will be offline until Tuesday, May 28, 2024, and will not actively watch over this GitHub during that period.

alexpensify commented on May 28, 2024

alexpensify commented on May 29, 2024

alexpensify commented on May 29, 2024

Ollyws commented on May 30, 2024

alexpensify commented on May 30, 2024

JmillsExpensify commented on May 31, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions