majido/scroll-restoration-proposal

A proposal to enable disabling scroll restoration

Scroll Restoration API

This API is now part of WhatWG HTML spec. It has been implemented in Chrome since version 46 and is expected to be in Firefox from version 46.

This repository hosts the early draft spec for scroll restoration API which aims to make it possible for web authors to disable the automatic scroll restoration in their web apps. This draft is now out-dated and superseded by the official spec .

There are also tests covering the spec.

References

• Chromium Dashboard entry and launch bug
• Firefox tracking bug
• WebKit tracking bug
• Background of the problem
• Whatwg mailing list discussions

scroll-restoration-proposal's Issues

Impact on restoring form state

Should cancelling restorestate prevent restoration of form state too? If so, then can/should we expose the raw form state in the event somehow? If not, what do we do if we decide we want to add such support later?

Latest editors draft link is the wrong one

It should probably be http://majido.github.io/scroll-restoration-proposal/history-based-api.html, not the link to the github repo. You could add extra URLs for GitHub though (I modeled the links in my recent specs off of pointer events, eg. see InputDevice).

prevent* methods on Event considered wierd

From Olli Pettay:

It is unusual Events to have methods like preventScrollRestoration() or preventScaleRestoration() ( ServiceWorker events are weird special cases.)
Usually events just carry data/state and information that something will happen unless preventDefault() is called, or information that something just happened (in which case preventDefault() doesn't do anything).
Using the same event to prevent scroll restoration and scale restoration sounds is like merging two features to one event. What if there is no scaling restoration involved and preventScaleRestoration() is called? what should happen?

Is there some reason to not dispatch separate events for different features:
"restoreScrollPosition", "restoreScale". I'd argue that usually pages want to prevent scroll position, but preventing scale restoration can be rather annoying for user at least in case of cross-page navigations.

I'm certainly not strongly against the model defined in event-based-api.md, but just thinking also other options.

Swap step 3 and 4 in persisted user state restoration process (3.1.1)

From Olli:

   In 3.1.1 Persisted user state restoration steps 3 and 4 should probably 
   be swapped, since the current (3) may run scripts, and if those scripts 
   happen to use history API, they see wrong history.scrollRestoration value.

Expose recorded scroll position

It is useful for applications to be able to read the recorded scroll position even if they are implementing their own custom scroll restoration. It allows them to no longer record the scroll position themselves. For example an infinite-scroller page can disable scroll restoration but use the recorded scroll position to load enough content to render.

Notes:

• The main advantage is that it eliminates the need for web apps to implement logic for recording scroll position themselves. However once scroll restoration is disabled, recording scroll position becomes quite simple so this may not be as valuable.
• Some user-agents do restore iframe scroll positions. Exposing these iframe scroll position may add too much complexity that is not worth the benefit.

Scroll restoration not working on history.back() handler

I try to set history.scrollRestoration = 'manual' in my history module (placed before tag) but Chrome (47 Win8, 46 - 48 Fedora) still scroll page to top after history.back() handler fired.

README is out of date

This is no longer a "proposed" spec - update README and links!

When is the 'restorestate' event fired?

From Jonas Sicking:

When we designed the pushState() API we ran into problems with a
similar event which caused some significant problems and required a
last-minute redesign. The resulting design for pushState() is that the
'popstate' event does not fire when the user does a session-history
traversal that navigates between Documents. There simply was no good
time to fire such an event.

If we fired 'popstate' before the 'load' event, then the <script

which added the event listener might not have loaded yet. If we fired
'popstate' after the 'load' event then the page didn't know what state
to render the page in until the 'load' event fired, which results in
crappy UX.

Instead we made the current state available through history.state, and
then 'popstate' only fires for sessionhistory transitions within the
same Document, i.e. when history.state changes.

So when does 'restorestate' fire? Does it fire before or after 'load'?
Keep in mind that browsers start restoring the scroll state long
before 'load' but doesn't load all <script>s until 'load' has been
fired.

Add this to the HTML Standard

https://github.com/whatwg/html is now accepting pull requests! We'd love for you to be able to integrate this into the official HTML Standard, instead of having to monkey-patch a bunch of its algorithms.

Let us know if there's any way we can help with this!

Consider supporting disabling scale restoration

Some browsers (e.g., Chrome Android, IE Mobile) restore scale as well as scroll position. We should be able to allow developers to disable this as well.

Note that most mobile web-apps disable user scaling altogether which is why this is not as bad as scroll restoration problem