Fix bottom sheet showing scroll position of triggering page#193
Open
noah44846 wants to merge 1 commit intohotwired:mainfrom
Open
Fix bottom sheet showing scroll position of triggering page#193noah44846 wants to merge 1 commit intohotwired:mainfrom
noah44846 wants to merge 1 commit intohotwired:mainfrom
Conversation
When the shared WebView moves into a ScrollingView container (bottom sheet), its native scrollY carries over from the previous page. Turbo's JS performScroll() cannot reset it because a WRAP_CONTENT WebView inside a NestedScrollView is not scrollable from JS's perspective. Reset the native scroll in visitRendered(), after Turbo has updated history.restorationIdentifier to the current page's ID, so the resulting scroll event does not corrupt the previous page's saved scroll position.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When opening a bottom sheet from a scrolled page, the bottom sheet inherits the scroll position of the page that triggered it. The content appears offset — scrolled down by however far the user had scrolled on the underlying page.
Screen_recording_20260312_172301.webm
The screen recording was made on v1.2.6 and the Demo app was using a version of hotwire-native-demo with the path config modified so that the modal pages are shown in a bottom sheet (
uri: "hotwire://fragment/web/modal/sheet")I think this happens because the
WebViewcarries its nativescrollYwhen it moves between fragment containers. For normal page navigation this is not an issue: Turbo's JSperformScroll()callswindow.scrollTo(0, 0)which successfully resets the scroll. But in a bottom sheet, theWebViewis sized withWRAP_CONTENTinside aNestedScrollView— in this layout theWebViewis not internally scrollable from the JS perspective, sowindow.scrollTo()has no effect. The nativescrollYpersists and gets rendered as an offset inside theNestedScrollView.Proposed fix
Reset the
WebView's native scroll in visitRendered(), guarded by a check that theWebView's parent is aScrollingView. At this point in the lifecycle, Turbo has already calledchangeHistory()which updateshistory.restorationIdentifierto the new page's own ID — so the scroll event that fires fromscrollTo(0, 0)updates the correct page's restoration data and does not corrupt the underlying page's saved scroll position. The reset also happens beforeremoveTransitionalViews(), so the progress view is still visible and there is no visible flash.Screen recording with fix:
Screen_recording_20260312_173620.webm