Promo modal - After swiping to next slide and rotating device, modal is stuck between pages

[applause-bot]

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: 9.4.33-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94012
Email or phone of affected tester (no customers): jsodinjsodjdsiodjsonj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Other

Action Performed:

1. Launch Expensify app.
2. Log in with new account.
3. Complete onboarding.
4. Relaunch the app.
5. When Concierge AI promo modal shows up, swipe to next slide.
6. Rotate device to landscape.
7. Swipe to next slide.
8. Rotate device to portrait.

Expected Result:

After swiping to next slide and rotating device, the modal will not be stuck between pages.

Actual Result:

After swiping to next slide and rotating device, the modal is stuck between pages.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7204916_1783703707205.Screen_Recording_20260711_003951_Expensify__1_.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7204916

Issue Owner

Current Issue Owner: @gijoe0295

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/25f1028532e858976ec8fa0e802e9217255d91c511c92bfb20855de010e7ff63

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #94012

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

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

The AI features promo modal (AIFeaturesPromoModal, from PR #94012) gets stuck between slides when the device is rotated while on a non-first slide.

What is the root cause of that problem?

The carousel is a horizontal FlatList whose page width comes from onLayout (carouselViewportWidth). Two things break on rotation, and nothing corrects for either:

1. The list remounts and resets to page 0. Wrapper = shouldUseScrollView ? ScrollView : View — and shouldUseScrollView is derived from isInLandscapeMode. On a phone, rotating flips landscape mode, so Wrapper changes React element type (View ⇄ ScrollView) at the same position. React can't reconcile that, so it unmounts and remounts the whole subtree — including the FlatList, which has no initialScrollIndex and so mounts back at offset 0.

2. The page width changes but the scroll offset isn't re-aligned. snapToInterval and getItemLayout both scale with carouselViewportWidth, but there is no effect keyed on carouselViewportWidth that re-scrolls the list to the current page. A surviving pixel offset from the old width no longer lands on a page boundary → partial two-slide "stuck between pages" view.

Meanwhile currentPage lives in the parent (survives rotation), so the pagination dots and body text still point at the old page while the list is at 0 or between pages — the visible mismatch.

Evidence / data flow

• Swipe to page 1 (portrait) → currentPage = 1, lastReportedPage = 1.
• Rotate → isInLandscapeMode flips → shouldUseScrollView flips → Wrapper switches View→ScrollView → FlatList remounts at offset 0.
• carouselViewportWidth updates via onLayout, but nothing re-scrolls the list.
• Only two effects exist (sync ref, vertical scrollToEnd) — neither touches the horizontal list.

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

In FeatureTrainingCarousel.tsx:

1. Add initialScrollIndex={currentPage} to the FlatList so it lands on the correct page immediately after the remount (no flash to page 0). getItemLayout is already provided, which makes this reliable.
2. Add an effect keyed on carouselViewportWidth that re-aligns the offset to the current page on any width change:

useEffect(() => {
    if (carouselViewportWidth <= 0) {
        return;
    }
    horizontalListRef.current?.scrollToOffset({offset: currentPage * carouselViewportWidth, animated: false});
    // eslint-disable-next-line react-hooks/exhaustive-deps -- re-align only when the viewport width changes (rotation)
}, [carouselViewportWidth]);

Read currentPage via a ref (or include it in deps — the re-snap is idempotent) so the effect stays keyed on width. This covers both the remount reset and the width-only relayout.

An alternative that also removes the remount trigger entirely is to keep Wrapper a single component type and toggle scroll behavior via props instead of swapping View/ScrollView, but the targeted fix above is the smaller change for a deploy blocker.

What alternative solutions did you explore? (Optional)

Since this is a deploy blocker on a brand-new feature (#94012), reverting that PR is the fastest option if a fix can't land quickly.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95853) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.