Fix reveal navigation under RHP + re-land reveal workspace route under RHP before dismissing on workspace creation

[JakubKorytko]

Explanation of Change

This PR makes revealRouteBeforeDismissingModal (and by extension preInsertFullscreenUnderRHP) reliable by addressing three distinct, latent bugs in the reveal flow, plus wiring the function into the workspace creation flow.

1. Stale deep-link params overriding the reveal target (handleReplaceFullscreenUnderRHP)

When the target TabNavigator had previously been created via a cross-tab PUSH, the inner tab kept a stale deep-link screen / params / path / initial / pop chain on params. React Navigation applied that chain as a follow-up NAVIGATE after the dismiss, overriding the patched state and landing the user on the previously viewed screen instead of the requested one (e.g. creating Workspace D landed on Workspace C's overview). Fix strips those STALE_DEEP_LINK_PARAM_KEYS from params in handleReplaceFullscreenUnderRHP's TAB branch.

Pre-fix structure:

Existing TabNavigator params
\-- WorkspaceNavigator
    |-- selected workspace: Workspace C
    \-- stale deep-link params
        |-- screen: WorkspaceOverview
        |-- params: {policyID: C}
        \-- path / initial / pop

Create Workspace D
\-- app prepares the Workspaces tab to open Workspace D
    \-- old nested route params still point to Workspace C
        \-- React Navigation applies that old target afterward

Result: Workspace C appears instead of Workspace D.

Post-fix structure (withSanitizedDeepLinkParams inside handleReplaceFullscreenUnderRHP's TAB branch):

Existing TabNavigator params
\-- WorkspaceNavigator
    |-- selected workspace: Workspace C
    \-- stale deep-link params stripped before replace

Create Workspace D
\-- app prepares the Workspaces tab to open Workspace D
    \-- withSanitizedDeepLinkParams removes old nested route params first
        \-- nothing redirects back to Workspace C

Result: Workspace D remains the revealed target.

2. Browser back-button losing the prior fullscreen entry (addRootHistoryRouterExtension)

revealRouteBeforeDismissingModal runs as a two-frame sequence: REPLACE_FULLSCREEN_UNDER_RHP swaps the under-modal fullscreen, then DISMISS_MODAL pops the RHP. The existing extension already froze state.history for REPLACE_FULLSCREEN_UNDER_RHP so useLinking saw historyDelta = 0 and didn't push/pop anything for that intermediate frame. The follow-up DISMISS_MODAL was then expected to update the browser entry naturally - but it didn't: post-dismiss state.routes was shorter than the (frozen) state.history, so useLinking's findMatchingState computed a negative historyDelta, then ran history.go(-1) followed by history.replace. That destructively overwrote the prior fullscreen entry (e.g. /workspaces), so pressing browser back from the newly-revealed page jumped past the list straight to whatever was below it (Account / Inbox).

Fix: when a DISMISS_MODAL completes a reveal sequence matching the snapshotted RHP key/routes/history depth, the extension now keeps the new state's history at the pre-dismiss length. useLinking sees historyDelta = 0 and just history.replaces the current browser entry (the dismissed RHP path) with the revealed fullscreen path, leaving the prior entry intact. The resulting history-vs-routes length offset is preserved across subsequent state changes with leading CUSTOM_HISTORY_ENTRY_REVEAL_PADDING sentinels prepended to the history array, so further inner navigations / modal opens / dismisses continue to produce correct deltas. If a popstate-driven resetRoot installs a fresh state (history length matching routes length), the offset is cleared so it doesn't bleed into the new navigation epoch.

The same history fix applies to existing reveal/pre-insert callers (Submit Expense, Share Details), which exhibited less-noticeable variants of the same bug.

Pre-fix structure:

Initial state before action
Visible stack:   [Workspaces list, create workspace RHP]
App routes:      [Workspaces list, create workspace RHP]
App history:     [Workspaces list, create workspace RHP]
Browser history: [Inbox] -> [/workspaces] -> [/workspaces/new]
                                          current ^

After user submits the modal, reveal starts.

Browser history before reveal commit
[Inbox] -> [/workspaces] -> [/workspaces/new]
                         current ^

Frame 1: REPLACE_FULLSCREEN_UNDER_RHP
state.routes  = [Workspace D, RHP]
state.history = [Workspaces list, RHP]   (frozen)
useLinking: historyDelta = 0

Frame 2: DISMISS_MODAL
state.routes  = [Workspace D]
state.history = [Workspace D]
useLinking compares against previous frozen depth and computes:
historyDelta = -1

Browser operation
history.go(-1)      -> moves current entry back to /workspaces
history.replace(...) -> overwrites /workspaces with Workspace D

Browser history after bug
[Inbox] -> [Workspace D] -> [/workspaces/new]

Back from Workspace D skips /workspaces and lands on Inbox.

Post-fix structure (getRevealDismissState):

Initial state before action
Visible stack:   [Workspaces list, create workspace RHP]
App routes:      [Workspaces list, create workspace RHP]
App history:     [Workspaces list, create workspace RHP]
Browser history: [Inbox] -> [/workspaces] -> [/workspaces/new]
                                          current ^

After user submits the modal, reveal starts.

Browser history before reveal commit
[Inbox] -> [/workspaces] -> [/workspaces/new]
                         current ^

Frame 1: REPLACE_FULLSCREEN_UNDER_RHP
state.routes  = [Workspace D, RHP]
state.history = [Workspaces list, RHP]   (frozen)
useLinking: historyDelta = 0

Frame 2: DISMISS_MODAL
state.routes  = [Workspace D]
state.history = [REVEAL_PADDING, Workspace D]
useLinking sees preserved depth:
historyDelta = 0

Browser operation
history.replace(...) -> replaces only current /workspaces/new entry

Browser history after fix
[Inbox] -> [/workspaces] -> [Workspace D]

Back from Workspace D correctly lands on /workspaces.

Padding lifecycle

The padding can stay for the rest of the current navigation epoch if the user only
keeps navigating inside the app.

Normal app navigation:
[REVEAL_PADDING, Workspace D] -> [REVEAL_PADDING, Workspace D, Workspace settings]

Examples that remove it:
- browser Back/Forward causing a popstate-driven resetRoot
- an explicit Navigation.resetRoot(...) that installs fresh routes without REVEAL_PADDING
- cold reload / fresh app launch from a URL

Fresh root install example:
partial state arrives without REVEAL_PADDING
getRehydratedState rebuilds history from routes
[REVEAL_PADDING, Workspace D] -> [Workspaces list]

Result: padding is removed exactly when a fresh root state is rehydrated without it.

3. Narrow layout showing the previous fullscreen during reveal

On narrow layouts, the under-RHP destination can have its own stack transition (for example, Workspaces list → Workspace overview uses a slide animation inside WorkspaceNavigator). revealRouteBeforeDismissingModal was dismissing the RHP after only one extra animation frame, so the RHP could start sliding away before that hidden destination transition finished. Visually this looked like: RHP slides out → previous fullscreen page appears briefly → destination page slides in.

Fix: on narrow layout only, revealRouteBeforeDismissingModal now waits for active navigation transitions before dispatching DISMISS_MODAL. The destination route is still inserted first, the RHP still uses its normal slide-out animation, but the slide-out now reveals the final destination page instead of an intermediate previous page. Wide layout behavior is unchanged.

As a testing ground, it uses the existing submit expense flows, but it also fixes the issue described in #88968 as well as the deploy blockers previous PR (#89605) caused.

Note: workspace creation can still navigate to a right-modal route (WORKSPACE_CONFIRMATION_SUCCESS) for the "different owner / don't keep me as admin" path. revealRouteBeforeDismissingModal only works for fullscreen reveal targets, so modal targets intentionally keep the older dismiss-then-navigate behavior via willRouteNavigateToRHP.

Pre-fix structure:

Initial state before action
Layout: narrow
Visible stack: [Workspaces list, create workspace RHP]
Hidden target: Workspace D overview

After user submits the modal, reveal starts.

Narrow layout reveal

T0: route is inserted under RHP
    [Workspaces list -> Workspace D transition starts behind RHP]

T1: one animation frame later
    DISMISS_MODAL fires while hidden transition is still running

T2: RHP slides out
    visible underneath: Workspaces list / previous fullscreen

T3: hidden transition finishes
    visible underneath: Workspace D

Result: brief flash of the previous fullscreen during RHP dismiss.

Post-fix structure (revealRouteBeforeDismissingModal):

Initial state before action
Layout: narrow
Visible stack: [Workspaces list, create workspace RHP]
Hidden target: Workspace D overview

After user submits the modal, reveal starts.

Narrow layout reveal

T0: route is inserted under RHP
    [Workspaces list -> Workspace D transition starts behind RHP]

T1: waitForTransition waits for hidden transition to finish
    underneath is now Workspace D

T2: DISMISS_MODAL fires
    RHP slides out

T3: RHP finishes dismissing
    visible underneath: Workspace D

Result: RHP dismiss reveals only the final destination.

Fixed Issues

$ #88968
$ #89647
$ #89667
PROPOSAL: N/A

Tests

Original test steps

1. Sign in with a new account (skip workspace creation during onboarding)
2. Tap the FAB button > Create Workspace
3. Fill in the workspace name and tap Confirm
4. Verify that the workspace overview page appears directly without the home page flashing underneath

A. Stale deep-link params (workspace creation lands on the right workspace)

1. Sign in to NewDot on a wide layout.
2. Open the Workspaces tab -> tap "New workspace" -> submit the confirmation modal. Verify that you land on the new workspace's overview page.
3. Press the in-app back button to return to the Workspaces list.
4. Tap the Inbox tab, then tap the Workspaces tab again. Verify that you land on the most recently viewed workspace's overview.
5. Press the in-app back button to return to the Workspaces list.
6. Tap "New workspace" again -> submit. Verify that you land on the newly created workspace's overview, NOT the previously viewed one.
7. From that overview, press the in-app back button. Verify that you land on the Workspaces list (not on a stale workspace).
8. Press the in-app back button again. Verify that the navigation pops cleanly to whatever was underneath (Inbox/Reports tab in the previous TabNavigator).

B. Browser back-button preserves the prior fullscreen entry (web only)

1. On web, sign in and open the Workspaces tab.
2. Tap "New workspace" -> submit. Verify the URL changes to the new workspace's overview path.
3. Press the browser back button. Verify that you land on the Workspaces list (/workspaces) - NOT on Account or whatever was underneath.
4. Press the browser forward button. Verify you return to the workspace overview.
5. Repeat the create flow once more on the same session and confirm browser back still goes back to /workspaces each time (no entry gets silently overwritten).

Repeat tests for the existing reveal callers to confirm no regression:

1. On a wide layout, start a Submit Expense flow -> submit. Verify that the modal slides away and reveals the expected report/Search screen with the new transaction.

C. Narrow layout reveal waits for the hidden destination transition

1. Switch to a narrow layout.
2. Open the Workspaces tab -> tap "New workspace" -> submit the confirmation modal.
3. Verify the RHP slides out directly to the new workspace's overview page.
4. Verify the Workspaces list does NOT appear briefly between the RHP dismiss and the overview page.
5. Press the in-app back button to return to the Workspaces list.
6. Repeat workspace creation once more and verify the same smooth reveal behavior.

D. Side panel & non-reveal modal flows are unaffected

1. Open and close the side panel several times. Verify the open/close state survives navigation state rebuilds (no spurious browser entries, side-panel sentinel preserved).
2. Open any plain RHP modal (e.g. profile, settings detail) and dismiss it via the close button. Verify the browser back stack behaves as before (one entry per modal open, popped on dismiss).

Offline tests

Same as tests. These fixes are purely navigation-state / browser-history concerns - no new API calls, no new Onyx writes, no behavior gated on connectivity. Workspace creation already runs offline (optimistic) and the reveal flow should land on the new workspace's overview locally without network. The browser back-button fix is a router-extension change that runs entirely client-side.

QA Steps

Same as tests.

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 any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • 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 shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • 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)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• 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)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• 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.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• 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.mov

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

Web.mov

[JakubKorytko]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1000db1bc9

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[codecov]

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
src/CONST/index.ts	92.30% <ø> (ø)
.../routerExtensions/addRootHistoryRouterExtension.ts	100.00% <100.00%> (ø)
src/libs/Navigation/Navigation.ts	51.55% <ø> (+0.20%)	⬆️
...ateRootStackNavigator/GetStateForActionHandlers.ts	30.54% <94.11%> (+5.94%)	⬆️
src/libs/actions/App.ts	52.01% <0.00%> (-0.58%)	⬇️
...erExtensions/addRootHistoryRouterExtensionUtils.ts	87.09% <87.09%> (ø)
... and 417 files with indirect coverage changes

[JakubKorytko]

@codex review

[JakubKorytko]

ESLint check failing on main, being fixed in #90050

Note: Android Inbox -> Workspaces tab slide in animation is reproducible on staging, not sure if bug or feature

SlideIn.mov

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Already looking forward to the next diff.

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[Copilot]

Pull request overview

Improves the reliability of the “reveal fullscreen under RHP, then dismiss” navigation flow (including browser history correctness on web) and applies it to workspace creation so the RHP dismiss reveals the intended workspace route without flashing/intermediate mis-navigation.

Changes:

• Sanitizes stale deep-link params when replacing fullscreen under the RHP to prevent React Navigation from performing a follow-up NAVIGATE that overrides the intended reveal target.
• Extends root router history handling to preserve the correct browser back-stack during the two-frame reveal sequence by introducing reveal-padding sentinels and stricter REPLACE↔DISMISS pairing.
• On narrow layouts, dismisses the modal with waitForTransition so the RHP slide-out reveals the final destination (not an intermediate/previous fullscreen).

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tests/unit/Navigation/routerExtensions/addRootHistoryRouterExtension.test.ts	Expands unit coverage for the reveal protocol, padding-offset behavior, and edge cases.
tests/unit/Navigation/createRootStackNavigator/withSanitizedDeepLinkParams.test.ts	Adds unit tests for deep-link param chain detection/sanitization behavior.
src/libs/Navigation/Navigation.ts	Makes reveal-dismiss on narrow layout wait for transitions before dismissing the modal.
src/libs/Navigation/AppNavigator/routerExtensions/addRootHistoryRouterExtensionUtils.ts	Introduces shared utilities for pending-reveal snapshotting and history padding logic.
src/libs/Navigation/AppNavigator/routerExtensions/addRootHistoryRouterExtension.ts	Refactors root history router extension to use snapshot + padding logic across REPLACE/REMOVE/DISMISS/default paths.
src/libs/Navigation/AppNavigator/createRootStackNavigator/GetStateForActionHandlers.ts	Adds withSanitizedDeepLinkParams and applies it in the TAB branch of handleReplaceFullscreenUnderRHP.
src/libs/actions/App.ts	Wires workspace creation to use reveal-before-dismiss for fullscreen targets, preserving legacy behavior for RHP/modal targets.
src/CONST/index.ts	Adds CUSTOM_HISTORY_ENTRY_REVEAL_PADDING sentinel used to preserve browser history length offsets.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated no new comments.

[melvin-bot]

@ZhenjaHorbach 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]

[ZhenjaHorbach]

Minor comment But we have 2 Workspaces screens in the navigation history if we navigate using the arrows after creating a worskpace using FAB

2026-05-14.16.26.55.mov

@JakubKorytko
We have this issue on staging also
So you can skip this

[mountiny]

Thanks for confirming! I would still love a review from @WojtekBoman or @sumo-slonik

[JakubKorytko]

Per slack: @WojtekBoman already did see this PR and we have talked about it for a long time. The conclusion was that there is some room for improvements in semantics etc but let's not block, as we still have this issue and can be improved there

[mountiny]

Discussed with @JakubKorytko and @sumo-slonik that this was already reviewed by @WojtekBoman so not going to block it

[github-actions]

🚧 @mountiny has triggered a test Expensify/App build. You can view the workflow run here.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #90044.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-239a794-1898b9d-988f03df6ae3faa3250326d277a6fb86f80f2c6c/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-239a794-1898b9d-aec4e27cdfa1fac63828d75c0516b96ac6f9246d/index.html

Web 🕸️
https://90044.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[OSBotify]

🚀 Deployed to staging by https://github.com/mountiny in version: 9.3.74-7 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android
• iOS

[MelvinBot]

No help site changes are required for this PR.

The changes are entirely internal navigation/routing bug fixes (stale deep-link param cleanup, browser history preservation during reveal flow, and narrow-layout transition timing). No user-facing features, UI labels, settings, or workflows were added or modified — the workspace creation flow itself is unchanged, only the underlying navigation mechanics were fixed.

[OSBotify]

🚀 Deployed to production by https://github.com/Beamanator in version: 9.3.74-7 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[IuliiaHerets]

Hi @JakubKorytko. QA team failed this PR with with

1778893113822.N.mp4

[JakubKorytko]

@IuliiaHerets sorry, but I'm not sure I follow. You linked to the issue where the home page flashes after creating a workspace, but I can't see the flash in the video. What is the actual bug here?

This is how the flash looks in prod and on your video I do not see it?

prod.mp4

[IuliiaHerets]

@JakubKorytko Let me investigate with the team

[IuliiaHerets]

@JakubKorytko The issue reproduces while testing on a narrow screen, so step 3 of the PR is failing.
We believe the root cause is the same as in the original open issue.
If we need to create a new issue, please let us know

1778893124365.N3.mp4

[JakubKorytko]

Oh I see, I assume this is not really a blocker since without the PR the issue is still there so let me take a deeper look tomorrow and get back to you, thanks a lot!

[ZhenjaHorbach]

We decided to skip this issue in another PR
So I think we can fix it in a separate PR later

#90310 (comment)
#90310 (comment)

[JakubKorytko]

Ohh I see, thanks @ZhenjaHorbach so much for the context, I would have probably not find this myself :D

@IuliiaHerets you can notice that it is the list of workspaces below the RHP that is visible for a moment, not the homepage. This was noted in the PR that Zhenja linked, so it is not the same issue (homepage before navigation to overview). I was confused for a while (had to re-read and slow down videos a few times), so I understand why you thought this was the same issue, but it's not. They're pretty similar, and we worked on these two at around the same time, but overall so we're good to go with this PR.

[IuliiaHerets]

@JakubKorytko can we create a new issue then?

[sumo-slonik]

@JakubKorytko can we create a new issue then?

@IuliiaHerets It looks like this is related to my changes. If you create an issue, I’ll take care of it right away

[IuliiaHerets]

Deploy Blocker #90880 was identified to be related to this PR