Intent to Implement: API to disable scroll restoration on history navigation

[Majid Valipour]

Contact emails

maj...@chromium.org, rby...@chromium.org

Spec

https://docs.google.com/document/d/1Tiu8PjvBtNOAgeh6yrs7bOrXxQcavQLiNtRJ_ToLlVM

The proposal is being actively discussed in whatwg as well.

Summary

The goal is to allow web applications to explicitly disable user agents default scroll restoration behavior on history navigation. This is achieved by defining a new optional boolean flag on history entry to indicate whether its scroll restoration is handled by the application or the user agent. Relevant History APIs will be modified** to support this new flag. This spec document has more details on current API design, alternatives considered, and motivation.

** The exact shape of API is still being discussed in whatwg but it is either adding a fourth optional parameter to existing methods or creating two brand new methods (i.e., history.push, and history.replace) that deprecate existing ones.

Motivation

The existing scroll restoration behaviour works well for document style web sites but it is often not appropriate for single-page web applications where the page content may be reconstructed (often asynchronously) upon navigation and where the application wants to control the details of visual transition between UI states.  

Because of this constraint, single-page app authors have resorted to various imperfect hacks to implement their own scroll restoration logic e.g., using a inner scrollable with a fixed sized document, or double scrolling. These hacks are brittle (for example in M42 we broke a popular workaround used by Image Search when blink became more spec conformance!), provide bad UX, and break browser features that depend on document scrolling such as top controls hiding, or overscroll visuals. here, here, and here are few documented cases of web developers struggling with this problem.

Compatibility Risk

The surface area of the change is small but given that there is no public signal from other vendors yet there is some amount of interoperability risks.

Web developers: Positive

Firefox: No public signals
Internet Explorer: No public signals
Safari: No public signals

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug?

http://crbug.com/477353

Link to entry on the Chromium Dashboard
https://www.chromestatus.com/features/5657284784947200

Requesting approval to ship?

No

[Chris Harrelson]

This is great, and fixing an important problem with web apps. Thanks for driving this.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

I agree, this is really important and urgent (as the recent google image search regression shows).  Hopefully we'll be able to get some consensus with at least one other vendor (seems probably important for Mozilla too) and ship this ASAP!

[Philip Jägenstedt]

This makes sense. There are some open questions about details and I commented in the document.

Whatever the eventual solution, https://html.spec.whatwg.org/#the-history-interface is where this would make most sense spec-wise, so moving that along in the WHATWG before shipping would be good.

Philip