Summary
When two Web routes render through the same shell position and each route contains a scrollable screen, navigating from a deeply scrolled first route can cause the second route to start at the old scroll offset rather than at its top.
In the observed case, the new route's leading content was outside the viewport. Resizing the browser caused another layout/render and made the expected initial content visible.
Representative reproduction
Build a small Fission Web application with:
- a Router;
- route A containing a tall
Scroll with enough rows to scroll several screens;
- route B containing a different screen in the same routed shell position; and
- a button near the bottom of route A that navigates to route B.
Steps:
- Open route A.
- Scroll near the bottom.
- Activate the button that navigates to route B.
- Observe the initial vertical position of route B.
- Resize the viewport and compare the result.
No explicit shared WidgetId or application-owned scroll state is used.
Expected behavior
A newly entered route should start at its own default scroll position unless the application explicitly supplies a stable scroll identity/state that requests restoration.
Retained widget optimization must not make unrelated routed screens accidentally share scroll state.
Actual behavior
The routed replacement can inherit the prior screen's scroll offset. Important leading content may appear missing until another viewport/layout event occurs.
Suggested implementation direction
Include route identity in retained subtree identity, or reset Scroll state when the routed child identity changes. Explicit application-owned restoration should remain possible.
Suggested regression test
Navigate from the bottom of a tall route to a distinct route rendered at the same tree position and assert the new route's Scroll offset is zero before any resize event.
Summary
When two Web routes render through the same shell position and each route contains a scrollable screen, navigating from a deeply scrolled first route can cause the second route to start at the old scroll offset rather than at its top.
In the observed case, the new route's leading content was outside the viewport. Resizing the browser caused another layout/render and made the expected initial content visible.
Representative reproduction
Build a small Fission Web application with:
Scrollwith enough rows to scroll several screens;Steps:
No explicit shared
WidgetIdor application-owned scroll state is used.Expected behavior
A newly entered route should start at its own default scroll position unless the application explicitly supplies a stable scroll identity/state that requests restoration.
Retained widget optimization must not make unrelated routed screens accidentally share scroll state.
Actual behavior
The routed replacement can inherit the prior screen's scroll offset. Important leading content may appear missing until another viewport/layout event occurs.
Suggested implementation direction
Include route identity in retained subtree identity, or reset Scroll state when the routed child identity changes. Explicit application-owned restoration should remain possible.
Suggested regression test
Navigate from the bottom of a tall route to a distinct route rendered at the same tree position and assert the new route's Scroll offset is zero before any resize event.