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

[Majid Valipour]

Contact emails

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

Spec

Unofficial spec (tests)

Summary

Add a new attribute to the history object allowing web developers to explicitly disable user agents default scroll restoration behavior on history navigation.  This document describes background and motivation for this change, and WhatWG and WICG discussion threads provide additional context for the API design.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/U1e2lmGs4tM/9_70ojL8TiIJ

Note that we are planing to ship a slightly different API than the one proposed in the original intent-to-implement. We have settled on the current API based on WhatWG feedback.

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

Yes.

Debuggability

The publicly exposed attribute may be inspected in DevTools similar to other web-exposed APIs. No special debug support is planned.

Compatibility Risk

The surface area of the change is small and we have consulted with relevant standard groups and vendors to ensure there is agreement around the issue and proposed solution. The API is publicly supported by Mozilla but until it becomes adopted by the HTML spec there is some amount of interoperability risks.

Web developers: Positive (on addressing the issue: 1 2 3 4)

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

OWP launch tracking bug

https://code.google.com/p/chromium/issues/detail?id=477353

Entry on the feature dashboard

[Darin Fisher]

Exciting. I had a little trouble understanding this sentence in the draft spec:

"It is best if this is done on load to ensure that no entry is added to history session with unexpected scroll restoration option."

I would have thought that if the web developer desired no automatic scroll restoration that they would be trying to swizzle the scrollRestoration attribute as early as possible. The load event fires quite late. It is possible the user has even scrolled the page and clicked on a link by then such that when they press back, scroll position would be restored.

-Darin

[Majid Valipour]

You are right. It should say 'as early as possible' instead of 'on load'. The key point I wanted to get across was that the attribute does not apply backward in history. For many pages this translates to setting it as early as possible. A better example is to perhaps set the scrollRestoration in an inline script in <head/>.

Majid

[Darin Fisher]

Ah, makes sense. Agreed, sample code showing scrollRestoration set early sounds right.

-Darin

[Rick Byers]

I'll avoid the conflict of interest and abstain from officially approving this :-).  But I want to weigh in unofficially with my support anyway.

Majid has been actively driving open discussion on this minor API change for quite some time, and it appears to have converged to consensus.  I'd prefer we had an official spec change before shipping this, but I believe it's not worth the cost to delay shipping past M46.  There's a clear, long-standing and urgent need from web developers here, a relatively straight forward / small solution, and apparent consensus with Mozilla at least on the design / spec change necessary.  I'm confident that the compat risk is relatively low and that we'll get the HTML spec updated eventually to incorporate this new API.  Shipping is the right next step IMHO.

Thanks,

  Rick

[Chris Harrelson]

On Tue, Aug 4, 2015 at 2:38 PM, Rick Byers <rby...@chromium.org> wrote:

I'll avoid the conflict of interest and abstain from officially approving this :-).  But I want to weigh in unofficially with my support anyway.

Majid has been actively driving open discussion on this minor API change for quite some time, and it appears to have converged to consensus.  I'd prefer we had an official spec change before shipping this, but I believe it's not worth the cost to delay shipping past M46.  There's a clear, long-standing and urgent need from web developers here, a relatively straight forward / small solution, and apparent consensus with Mozilla at least on the design / spec change necessary.  I'm confident that the compat risk is relatively low and that we'll get the HTML spec updated eventually to incorporate this new API.  Shipping is the right next step IMHO.

I agree. LGTM

 

Thanks,

  Rick

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

[Philip Jägenstedt]

LGTM2

[Jochen Eisinger]

lgtm3

[John Mellor]

The spec mentions page scale in the abstract but nowhere else. Presumably whenever it refers to scroll position, it is also referring to page scale?

[Majid Valipour]

No. That's just slightly outdated as we have changed our thinking on this issue. I will update the spec to remove that reference.

Unlike scroll position, page scaling (pinch-zoom) is not currently exposed extensively to web-authors. In particular, there are no APIs to set the page scale value. The intention of this feature is that by giving web authors control over disabling scroll restoration they are able to restore scroll position better that the browser itself (e.g., in single-page app context). In the case of scale, this is not really possible until we expose APIs to control scale.

So when a user have scaled the page, not restoring the scale can be annoying when the page is restoring the scroll position. This needlessly punishes those sites that are trying to do best by their users by restoring the scroll position as best as they can.

At this point, we plan to keep restoring scale independent of the page's desired scroll restoration value. This not only reduces the potential to annoy users but also appropriately rewards pages that are correctly restoring the scroll position. In meantime, sites can still disable user-scaling altogether by using viewport meta tag. If there is enough interest we can expose scale restoration once there is an API to control scale. 

Majid

[PhistucK]

On Tue, Aug 4, 2015 at 11:51 PM, Majid Valipour <maj...@chromium.org> wrote:

A better example is to perhaps set the scrollRestoration in an inline script in <head/>

​Sounds like a worst practice (inline script). :( Why not add an HTML attribute (or a meta tag, if you must) version of it as well to cater for this?​

☆PhistucK

[Steve Kobes]

We don't restore the scroll position until we've finished loading the page.  Doesn't that mean it is safe to set scrollRestoration in the onload handler?  (I haven't tested this.)

[Steve Kobes]

Majid reminded me that we also restore scroll after layout.  So scrollRestoration must be set before the first layout, which means inline script is the only option. :-/

[PhistucK]

Yes, barring an HTML attribute or some similar mechanism. This is pretty bad.

☆PhistucK

[David Benjamin]

Why would the timing matter? It's not "should I restore scroll position right now?". If it were that, we would need to set it very early, yeah. But my read is that this is "should I *save* the scroll position into the history entry?". (Certainly that would be the simpler way to do this.) This makes the timing much more relaxed.

Earlier is, I suppose, better, but if you happen to navigate away while a page is doing its first few layouts and still setting itself up, there wouldn't really be any scroll position to restore if you were to try to navigate back. If there were, it wouldn't be any different than if the user tried to scroll before you installed an onscroll handler or whatever. Really the right time to set this field is right when you create whatever widgets in your page require custom scroll handling.

That is, think history.replaceState, not window.onpopstate.

[Majid Valipour]

On Wed, Aug 5, 2015 at 3:36 PM David Benjamin <davi...@chromium.org> wrote:

Why would the timing matter? It's not "should I restore scroll position right now?". If it were that, we would need to set it very early, yeah. But my read is that this is "should I *save* the scroll position into the history entry?". (Certainly that would be the simpler way to do this.) This makes the timing much more relaxed.

Your read is the correct one here. Setting the attribute does not affect the current navigation itself but next time we navigate back (or forward) to this entry. So the timing does not matter in that sense.

 

Earlier is, I suppose, better, but if you happen to navigate away while a page is doing its first few layouts and still setting itself up, there wouldn't really be any scroll position to restore if you were to try to navigate back.

If there were, it wouldn't be any different than if the user tried to scroll before you installed an onscroll handler or whatever. Really the right time to set this field is right when you create whatever widgets in your page require custom scroll handling.

That is, think history.replaceState, not window.onpopstate.

I think this is a good characterization. However setting it as soon as possible provides a convenient way to reduce the chances where user may scroll and navigate away without the page setting the attribute. But as you pointed out failing that should not be any different than the page not being able to set onscroll handlers before user scrolled. 

 

On Wed, Aug 5, 2015 at 3:25 PM PhistucK <phis...@gmail.com> wrote:

Yes, barring an HTML attribute or some similar mechanism. This is pretty bad.

I feel applications are best to judge where they want to set this attribute. In anycase, it is fairly easy to later add a declarative (e.g., <meta> tag) mechanism for setting the initial value of this attribute if we found this is how web apps are using it. Note that a declarative API has already been mentioned on WICG discussion and the current opinion is that we should stay away from it. I think WICG thread is the right place to continue this discussion.

Note that it is perfectly valid for a page to set different scrollRestoration values for each of its states. It is perhaps not the most common usage pattern but definitely supported.

Majid