[Due for Payment 2026-04-09][$250] Android - Book Travel - It is not possible to click the “Add Phone Number” tab

@mallenexpensify

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: v.9.3.38-0
Reproducible in staging?: Yes
Reproducible in production?: Unable to validate in Prod - Provide reasoning.
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #85143
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Galaxy A55/ Android 16
App Component: Other

Action Performed:

Prerequisite: You must have a workspace with travel enabled and have already selected the ticket prices.

On the Summary page, fill in the personal information with Alberta Charleson’s details.
Tap the “Save Changes” button.
You will be prompted to enter a phone number.

Expected Result:

You can add the phone number.

Actual Result:

You cannot add the phone number because the button is hidden behind the Android tab.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7104601_1773693512778.Book_travel_-_Cant_add_the_number_phone.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/~022033655130281316756
Upwork Job ID: 2033655130281316756
Last Price Increase: 2026-03-24

Proposal

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

On Android (Galaxy A55 / Android 16), when booking travel via Spotnana and being prompted to enter a phone number on the Summary page, the button to add the phone number is hidden behind the Android system navigation bar, making it impossible to tap.

What is the root cause of that problem?

The TravelDotLinkWebview component renders Spotnana's travel booking page inside a React Native WebView. The ScreenWrapper wrapping this WebView explicitly sets includeSafeAreaPaddingBottom={false}, which disables bottom safe area padding.

The app uses a transparent Android navigation bar (android:navigationBarColor=@android:color/transparent in styles.xml), meaning the app renders behind the system nav bar. Without bottom safe area padding, the WebView extends all the way to the bottom edge of the screen, causing the bottom portion of Spotnana's page content (the phone number button) to be obscured by the Android navigation bar.

This is exacerbated by Android 16, which enforces edge-to-edge display by default.

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

In src/pages/Travel/TravelDotLinkWebview.tsx, remove the includeSafeAreaPaddingBottom={false} prop from the ScreenWrapper (or change it to includeSafeAreaPaddingBottom). The default value is true, which will apply the appropriate bottom safe area inset, pushing the WebView content above the Android navigation bar.

What alternative solutions did you explore? (Optional)

Migrate to edge-to-edge mode by adding enableEdgeToEdgeBottomSafeAreaPadding to the ScreenWrapper — this is the newer pattern used by some travel pages like WorkspaceConfirmationForTravelPage. However, this is more complex and may not be necessary since the WebView content is not managed by the app's own scrollable components.
Add bottom padding directly to the WebView — this would work but is less idiomatic than using ScreenWrapper's built-in safe area handling.

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.

@FitseTLT

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

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

Proposal

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

On Android, the "Add Phone Number" button in the travel booking flow is hidden behind the system navigation bar. Users can't tap it, so they're stuck and can't complete the booking.

What is the root cause of that problem?

TravelDotLinkWebview.tsx (line 24) sets includeSafeAreaPaddingBottom={false} on its ScreenWrapper. This was there from the component's creation (commit d0f45cb, June 2025) — likely copied from a screen that didn't need bottom padding.

Here's how it breaks: ScreenWrapperContainer (lines 149-162) always renders a bottom spacer View in legacy mode, but when includeSafeAreaPaddingBottom is false, that spacer gets paddingBottom: undefined instead of the device's safe area inset. So the WebView fills the full screen height, extending behind Android's transparent navigation bar (edge-to-edge mode enabled since Nov 2024 in styles.xml:10). Spotnana's bottom content ends up behind the gesture bar.

No tests exist for this component, which is how it shipped.

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

Remove includeSafeAreaPaddingBottom={false} from the ScreenWrapper in TravelDotLinkWebview.tsx. The default is true, which gives the bottom spacer its proper paddingBottom via the safe area inset, constraining the WebView above the nav bar.

This is safe across platforms — on iOS, it works with the existing safe area handling. On web, the bottom inset is 0, so nothing changes visually. On devices without a gesture nav bar, the inset is also 0.

What alternative solutions did you explore? (Optional)

I looked at using enableEdgeToEdgeBottomSafeAreaPadding since WorkspaceConfirmationForTravelPage.tsx uses it. But it won't work here — edge-to-edge mode delegates padding to RN scrollable leaf components (ScrollView, SelectionList), and a WebView isn't one of those. Also, without bottomContent provided, the bottom spacer View doesn't render at all in edge-to-edge mode (ScreenWrapperContainer.tsx:149).

Adding padding directly to the WebView style would work but bypasses ScreenWrapper's built-in safe area handling, creating a maintenance burden for no real benefit.

Proposal

Please re-state the problem that we are trying to solve in this issue.
On Android (tested on Galaxy A55 / Android 16), the "Add Phone Number" button in the Spotnana travel booking flow is hidden behind the Android system navigation bar, preventing users from completing the train booking.

What is the root cause of that problem?
In src/pages/Travel/TravelDotLinkWebview.tsx, the ScreenWrapper component is explicitly configured with includeSafeAreaPaddingBottom={false} (line 24). Since the app uses a transparent Android navigation bar (android:navigationBarColor=@android:color/transparent in android/app/src/main/res/values/styles.xml), the app renders behind the system nav bar. Without bottom safe area padding, the WebView extends to the absolute bottom edge of the screen, causing Spotnana's page content at the bottom (the phone number button) to be occluded by the Android gesture bar / navigation bar. This is made worse by Android 16's enforced edge-to-edge display.

What changes do you think we should make in order to solve the problem?
Remove the includeSafeAreaPaddingBottom={false} prop from the ScreenWrapper in src/pages/Travel/TravelDotLinkWebview.tsx. The default value of includeSafeAreaPaddingBottom is true, which will cause ScreenWrapperContainer to apply the correct bottom safe area inset via its bottom spacer View, pushing the WebView content above the Android navigation bar.

This change is safe cross-platform: on iOS, the existing safe area handling applies the correct inset; on web, the bottom inset is 0, so there is no visual change; on Android devices without a gesture nav bar, the inset is also 0.

What alternative solutions did you explore? (Optional)

Using enableEdgeToEdgeBottomSafeAreaPadding (as seen in WorkspaceConfirmationForTravelPage.tsx) — this delegates padding to RN scrollable leaf components (ScrollView, SelectionList), but a WebView is not one of those components, so the padding would not be applied. Additionally, without bottomContent provided, the bottom spacer View does not render in edge-to-edge mode (ScreenWrapperContainer.tsx:149), so this approach would not work.
Adding paddingBottom directly to the WebView style — this would work but bypasses ScreenWrapper's built-in safe area handling, creating a maintenance burden for no benefit.

@chengyixu

📣 @chengyixu! 📣
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:

Make sure you've read and understood the contributing guidelines.
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.
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.
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>

Contributor details
Your Expensify account email: Chengyi_xu@outlook.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01d70946e6b723bb6f

BugZero Checklist:

[Contributor] 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: https://github.com/Expensify/App/pull/65176/changes#r3047901398
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source 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:
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

Link to issue:

Test:

Open the app on an Android device (ideally Android 16 or a device with gesture navigation)
Navigate to a workspace with travel enabled
Start booking travel and reach the Summary page with Spotnana's webview
Fill in personal information and tap "Save Changes"
When prompted to enter a phone number, verify the button is visible and tappable (not hidden behind the Android navigation bar)

Do we agree 👍 or 👎

Zapier Logs

Run ID: 00040eee-d75a-adc0-d6d2-35d97df88204

@FitseTLT

Payment Summary

Contributor+: @FitseTLT paid $250 via Upwork

^ Test case created

Thx

@mallenexpensify

Payment Summary

Contributor+: @FitseTLT due $250 via NewDot

^ Test case created

Thx

@mallenexpensify I get paid on Upwork

@FitseTLT

@FitseTLT can you please accept the job below? Please reply here and tag me once you have.
https://www.upwork.com/jobs/~022033655130281316756

sorry... again...

@mallenexpensify

@mallenexpensify

@FitseTLT

@FitseTLT paid, summary updated above. Thx.

Navigation Menu

Repository navigation

[Due for Payment 2026-04-09][$250] Android - Book Travel - It is not possible to click the “Add Phone Number” tab #85462

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)

Proposal

24 remaining items

BugZero Checklist:

Test:

Payment Summary

Payment Summary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Due for Payment 2026-04-09][$250] Android - Book Travel - It is not possible to click the “Add Phone Number” tab #85462

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

MelvinBot commented on Mar 16, 2026

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)

melvin-bot commented on Mar 16, 2026

melvin-bot commented on Mar 16, 2026

shivang-goliyan commented on Mar 16, 2026

Proposal

chengyixu commented on Mar 19, 2026

melvin-bot commented on Mar 19, 2026

chengyixu commented on Mar 19, 2026

24 remaining items

FitseTLT commented on Apr 7, 2026

BugZero Checklist:

Test:

mallenexpensify commented on Apr 10, 2026

Payment Summary

FitseTLT commented on Apr 10, 2026

Payment Summary

mallenexpensify commented on Apr 10, 2026

FitseTLT commented on Apr 10, 2026

mallenexpensify commented on Apr 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions