[$250] Workspace - Workspace page auto scroll to top after opening a domain and swipe back

[jponikarchuk]

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: v9.2.65-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #74973
Email or phone of affected tester (no customers): applausetester@applause.expensifail.com
Issue reported by: Applause Internal Team
Device used: Pixel 7 Pro /Android 16
App Component: Workspace Settings

Action Performed:

1. Log in to the App with the applausetester@applause.expensifail.com
2. Tap on the Workspace tab
3. Scroll down to the bottom
4. Tap on any domain
5. Swipe back

Expected Result:

The app should retain the previous scroll position after swiping back, so the user stays at the Domain section like the iOS app

Actual Result:

The app jumps back to the top, forcing the user to scroll down again

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @rojiphil

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021995244710709556104
• Upwork Job ID: 1995244710709556104
• Last Price Increase: 2026-03-16
• Automatic offers:
• truph01 | Contributor | 109761272

[melvin-bot]

Triggered auto assignment to @NicMendonca (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[truph01]

Proposal

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

• When navigating away from and returning to the workspace list page, the scroll position is lost, causing the app to jump back to the top. This forces users to manually scroll down again, disrupting their workflow.

What is the root cause of that problem?

• The current implementation does not persist or restore the scroll position for the WorkspacesListPage. As a result, upon re-render or navigation back to the page, the scroll offset defaults to the top.

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

• In WorkspacesListPage.tsx, implement logic to persist and restore scroll position using ScrollOffsetContext. Specifically:

    const {saveScrollOffset, getScrollOffset} = useContext(ScrollOffsetContext);
    const onScroll = useCallback<NonNullable<ScrollViewProps['onScroll']>>(
        (e) => {
            // If the layout measurement is 0, it means the flash list is not displayed but the onScroll may be triggered with offset value 0.
            // We should ignore this case.
            if (e.nativeEvent.layoutMeasurement.height === 0) {
                return;
            }
            saveScrollOffset(route, e.nativeEvent.contentOffset.y);
        },
        [route, saveScrollOffset],
    );

    useLayoutEffect(() => {
        const scrollOffset = getScrollOffset(route);
        if (!scrollOffset || !flatlistRef.current) {
            return;
        }
        flatlistRef.current?.scrollToOffset({
            offset: scrollOffset,
            animated: false,
        });
    }, [getScrollOffset, route]);

• Attach the onScroll callback to the FlashList component by updating the prop at this line:

onScroll={onScroll}

• In ScrollOffsetContextProvider.tsx, update the logic to treat the workspace list as a target screen for scroll restoration:

            const sidebarRoutes = state.routes.filter((route) => isSidebarScreenName(route.name) || route.name === SCREENS.WORKSPACES_LIST);

• The above logic will preserve the scroll position in the workspace list as long as the screen remains appeared in the navigation stack. If needed, we can update the behavior so that the scroll position resets when the user navigates to a different tab. This decision depends on design preferences and can be addressed during the PR phase.

What alternative solutions did you explore? (Optional)

[truph01]

@mountiny This issue doesn't appear to be related to SAML Configuration. It seems to be a general bug affecting the workspace list screen behavior.

[ZhenjaHorbach]

@mountiny This issue doesn't appear to be related to SAML Configuration. It seems to be a general bug affecting the workspace list screen behavior.

Actually yes
The same behaviour and with workspaces (not only domains)
So I think it's a separate issue, and we can open this issue for contributors!