Open abdullahtellioglu opened 2 weeks ago
I've marked this as enhancement. The effort is rather big for precise scrolling: Flow has to know what provides the scrolling - page body or some component, then Flow has to calculate where to scroll based on actual changes on the page, e.g. what is removed/added. If too many components are removed, maybe it doesn't make sense to scroll at all.
Description of the bug
When an application exceeds the viewport and has a scrollbar, any change recreates the whole UI after hot-swapping, and the scrollbar goes to initial position.
https://github.com/user-attachments/assets/cac625ea-57ca-4f34-a1f5-9286bcb15564
Expected behavior
The scroll position should remain after reloading. I proposed a solution in Copilot repository to restore selected element position but scrollbar initially goes top and scrolls back to the element. Scrollbar restoring should work regardless of Copilot state so we moved the issue here as it is suggested by Artur
Minimal reproducible example
Create a view that exceeds the viewport such as :
Update the code in IDEA and trigger hotswapping and you will see that scrollbar position resets the initial one.
Versions
Hilla: 24.6.0.alpha2 Flow: 24.6.0.alpha1 Vaadin: 24.6.0.alpha1 Copilot: 24.6-SNAPSHOT Frontend Hotswap: Enabled, using Vite OS: aarch64 Mac OS X 14.6.1 Java: JetBrains s.r.o. 17.0.10 Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Java Hotswap: Hotswap is not enabled IDE Plugin: 1.3.3 IntelliJ