Limits of Turbo Frame fallback scroll restoration behavior

Limits of Turbo Frame fallback scroll restoration behavior

The goal is to clarify whether Turbo should attempt to restore the previous scroll position when a Turbo Frame request returns HTML that lacks a matching frame element, causing a full‑page fallback.

In Turbo 7.x the fallback performs a full‑page navigation that preserves the original request method and headers, but Turbo does not intervene in scroll restoration; the browser’s default scroll restoration applies, which can lead to unexpected jumps.

The Turbo team has noted that the decision to add explicit scroll restoration on such fallbacks is still under discussion, with no settled behavior documented.

Should Turbo attempt to restore the previous scroll position on frame‑missing fallback? If so, what mechanism should be used to capture and restore the scroll offset? Should this behavior be configurable via a data attribute or meta tag?