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

[lanitochka17]

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.

1. On the Summary page, fill in the personal information with Alberta Charleson’s details.
2. Tap the “Save Changes” button.
3. 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:

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

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

[MelvinBot]

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)

1. 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.

2. 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.

[melvin-bot]

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

[melvin-bot]

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

[shivang-goliyan]

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.

[chengyixu]

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)

1. 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.
2. 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.

[melvin-bot]

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

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>