Add persistent bottom-right product marketing window

[KJ21-ENG]

Explanation of Change

This PR adds the persistent, dismissible bottom-right product marketing window described in the linked issue:

• App-wide persistence: A new ProductMarketingWindowManager is mounted in both platform variants of RootNavigatorExtraContent, the extra content slot of the authenticated root stack navigator. Because this host renders outside the changing route screens, the window stays mounted while the user navigates between Home, Reports, Workspaces, etc. It never renders for logged-out users (the host only exists in AuthScreens), for anonymous public-room sessions (explicit authTokenType guard), or while acting as a copilot (delegates must not see or permanently dismiss the account owner's announcement, matching the other product training surfaces).
• Single active announcement: ACTIVE_PRODUCT_MARKETING_ANNOUNCEMENT (in ProductMarketingWindowUtils) holds exactly one marketing-authored announcement (or null for none), with a stable announcementID and separate admin/member content variants (illustration, heading, body, CTA label, CTA route). There is no list scanning, stacking, or queueing: when the active announcement is dismissed, nothing is shown until a future release ships a new announcement ID.
• Localized content: The announcement's heading/body/CTA copy lives in src/languages (all supported locales), and the variant config carries translation paths, following the agentsPromoBanner precedent.
• Audience targeting: The variant is resolved with the existing hasActiveAdminPoliciesSelector (the same selector behind useHasActiveAdminPolicies) — users who administer at least one active workspace get the admin variant (so admin prevails for users who are both member and admin), everyone else gets the member variant. The selector is subscribed directly so its loading state is available (see below).
• Per-announcement dismissal: Both the Dismiss button and completing the primary CTA store a namespaced key (productMarketingWindow:<announcementID>) in the existing dismissed product training NVP via dismissProductTraining(). The DismissedProductTraining Onyx type is extended to accept that key pattern, and the dismissal check reuses the existing isProductTrainingElementDismissed helper. The CTA records the dismissal before navigating so the window doesn't flash during navigation. A future announcement has a different ID, so it remains eligible even if a prior one was dismissed.
• No flash on cold start or fresh sign-in: The manager waits for the dismissal NVP and the policy collection to load (isLoadingOnyxValue) and for the initial OpenApp fetch to finish (IS_LOADING_APP, defaulting to true, mirroring useAIFeaturesPromoModal) before rendering. A dismissed window therefore doesn't flash on refresh/app start or when signing in on a new device, and admins don't briefly see the member variant while policies arrive. Both variants' illustrations are resolved up front so an audience flip mid-session never shows a blank illustration.
• Centered modal precedence: The manager subscribes to ONYXKEYS.MODAL with the existing isModalCoveringSelector() (covers all react-native-modal-based centered modals via BaseModal) and additionally hides while a screen-based centered modal navigator (onboarding, feature training, migrated-user welcome, submit plan, AI features promo, test drive demo, test tools) is the topmost root route. The window and a centered modal are therefore never shown at the same time, and the still-mounted manager shows the window again when the modal closes.
• Responsive design: The window renders as a fixed-width card anchored to the bottom-right on wide layouts and as a near-full-width, safe-area-aware bottom card on narrow layouts, using the dark branded style from the issue's design in both themes. Per the design mock, on narrow layouts the card floats at the bottom edge of the screen (over the tab bar area) until dismissed — flagging for design confirmation.

The initial active announcement ships with the two content variants shown in the issue's design mock ("Upload your expense policy PDF" for admins, "Attach multiple receipts to one expense" for members).

Unit tests cover the single-active/dismissal/audience helpers, and component tests cover audience resolution, namespaced dismissal, dismissal persistence after pressing either button, dismiss-before-CTA-navigation ordering, centered-modal suppression/restore (both Onyx-modal and screen-based), anonymous-session exclusion, wide/narrow layout styles, and (via the real root stack navigator) persistence across route changes.

Fixed Issues

$ #95791
PROPOSAL: #95791 (comment)

Tests

Member variant, persistence, and CTA (account A: not an admin on any workspace)

1. Sign in with account A.
2. Verify a dark product marketing window appears anchored to the bottom-right of the app (bottom of the screen on narrow layouts) with an illustration, the heading "Attach multiple receipts to one expense", body copy, a green "Try it out" button, and a "Dismiss" button.
3. Navigate between Inbox, Reports, Workspaces, and Account. Verify the window stays visible in the same position on every page.
4. Open your self-DM, send a message, then open the message's context menu and choose "Delete comment" so the centered confirmation modal appears. Verify the marketing window is hidden while the modal is open, then press Cancel and verify the window reappears.
5. Press "Try it out". Verify you are routed to the Reports > Expenses view, the window closes without flashing back during navigation, and it does not reappear after a page refresh / app restart (no flash of the window while the app loads).

Member dismissal (account B: another account that is not an admin on any workspace)

6. Sign in with account B and verify the window appears.
7. Press "Dismiss". Verify the window closes, does not reappear while navigating around the app, and stays gone after a page refresh / app restart (no flash of the window while the app loads).

Admin variant and CTA (account C: admin on at least one active workspace)

8. Sign in with account C (an account that is also a member of other workspaces should still see the admin variant).
9. Verify the window shows the admin heading "Upload your expense policy PDF".
10. Press "Try it out". Verify you are routed to the workspaces list and the window closes without flashing back during navigation.

• Verify that no errors appear in the JS console

Offline tests

Dismissal is written optimistically to Onyx, so it works offline:

1. Sign in and verify the marketing window is visible.
2. Go offline.
3. Press "Dismiss". Verify the window closes immediately.
4. Go back online. Verify the window stays dismissed (including after a refresh once the request syncs).

QA Steps

Same as the Tests section above, on staging. This requires two accounts with no admin role on any workspace (the CTA leg dismisses the announcement for the first account) and one account that is an admin on at least one active workspace.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari (Admin variant and CTA)

Screen.Recording.2026-07-16.at.3.36.25.AM-compressed.mp4

MacOS: Chrome / Safari (Member CTA)

Screen.Recording.2026-07-16.at.3.40.55.AM.mov

MacOS: Chrome / Safari (Member dismissal)

Screen.Recording.2026-07-16.at.3.44.27.AM.mov

[melvin-bot]

Hey, I noticed you changed src/languages/en.ts in a PR from a fork. For security reasons, translations are not generated automatically for PRs from forks.

If you want to automatically generate translations for other locales, an Expensify employee will have to:

1. Look at the code and make sure there are no malicious changes.
2. Run the Generate static translations GitHub workflow. If you have write access and the K2 extension, you can simply click: [this button]

Alternatively, if you are an external contributor, you can run the translation script locally with your own OpenAI API key. To learn more, try running:

npx ts-node ./scripts/generateTranslations.ts --help

Typically, you'd want to translate only what you changed by running npx ts-node ./scripts/generateTranslations.ts --compare-ref main

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/CONST/index.ts	94.81% <ø> (ø)
...igation/RootNavigatorExtraContent/index.native.tsx	100.00% <100.00%> (ø)
.../ProductMarketingWindow/ProductMarketingWindow.tsx	100.00% <100.00%> (ø)
...tMarketingWindow/ProductMarketingWindowManager.tsx	100.00% <100.00%> (ø)
src/libs/actions/Welcome/index.ts	61.42% <100.00%> (ø)
src/styles/index.ts	63.40% <ø> (ø)
src/styles/variables.ts	100.00% <ø> (ø)
src/types/onyx/DismissedProductTraining.ts	0.00% <ø> (ø)
src/libs/ProductMarketingWindowUtils.ts	92.30% <92.30%> (ø)
...nts/Navigation/RootNavigatorExtraContent/index.tsx	0.00% <0.00%> (ø)
... and 89 files with indirect coverage changes

[melvin-bot]

@huult Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 292fa34b95

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Hide behind bottom-docked confirm modals

On narrow screens ConfirmModal renders as CONST.MODAL.MODAL_TYPE.BOTTOM_DOCKED, and BaseModal reports bottom-docked modals with isPopover: true, so this selector returns false for them. Because the marketing window is also bottom-anchored on narrow layouts, opening any confirm/bottom-docked modal (for example the delete-comment confirmation on mWeb/native narrow) leaves the marketing card mounted instead of suppressing it; treat bottom-docked modal visibility as covering here rather than relying on the popover-filtered selector.

Useful? React with 👍 / 👎.