[Exploratory] - Workspaces - Scroll position not preserved if returning to WS list after navigating to inbox

[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.3.80-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90970
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 / Chrome
App Component: Workspace Settings

Action Performed:

Prerequisite: Account has at least 5 workspaces and workspaces list is scrollable.

1. Open the staging.new.expensify.com
2. Navigate to "Workspaces"
3. Scroll to the bottom of workspaces list and open the last workspace.
4. Click on the back button on the top left corner to return to workspaces list.
5. Note that scroll position was preserved.
6. Reopen last workspace.
7. Click on "Inbox" and return to "Workspaces"
8. From workspace menu, click on back button again to return to workspaces list.
9. Note that scroll position wasn´t preserved.

Expected Result:

Everytime the user returns from workspace menu to workspaces list, scroll position should be preserved.

Actual Result:

Scroll position is not preserved when returning from workspace overview to workspaces list if user navigated to "Inbox" previously.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7161057_1779503573511.Position.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7161057

[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/525dc61021b9679a760971e1cdb70c610eab0134d08c642634a29b7c44611920

[harryautomazione]

Proposal

What is the root cause of that problem?

When the user navigates from the Workspaces list page to the Inbox tab, the WorkspacesListPage screen is unmounted from the navigation stack. Consequently, all local component-level states and references (such as a local useRef storing the scroll offset) are destroyed. When returning to the workspaces list, a brand new instance of WorkspacesListPage is mounted, resetting the local scroll offset reference to 0 and causing the scroll position to be lost.

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

We should persistently save and restore the scroll position using the global ScrollOffsetContext, which is defined at the root level of the application (under ScrollOffsetContextProvider) and designed exactly to preserve list offsets across unmount/mount lifecycles.

Specifically, in src/pages/workspace/WorkspacesListPage.tsx:

1. Import ScrollOffsetContext from @components/ScrollOffsetContextProvider.
2. Access saveScrollOffset and getScrollOffset from the context using the useContext hook.
3. In the useEffect hook that handles refocus/mount (triggered by isFocused and useRoute), retrieve the saved scroll offset via getScrollOffset(route) and call flatlistRef.current?.scrollToOffset({ offset: scrollOffset, animated: false }) using a requestAnimationFrame callback.
4. Update the onScroll prop of the FlatList component to save the current scroll offset using saveScrollOffset(route, event.nativeEvent.contentOffset.y), ignoring events where event.nativeEvent.layoutMeasurement.height === 0.

What alternative solutions did you explore? (Optional)

An alternative solution is using Onyx keys to store the scroll position, but using the built-in ScrollOffsetContext is the standard pattern in the codebase (e.g., used by InitialSettingsPage, LHNOptionsList, and search screens) and does not introduce Onyx read/write latency.

[melvin-bot]

Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[melvin-bot]

10 days overdue. I'm getting more depressed than Marvin.

[melvin-bot]

12 days overdue. Walking. Toward. The. Light...