Intent to Prototype: App history API

448 views

Skip to first unread message

Domenic Denicola

unread,

Mar 2, 2021, 11:14:52 AM3/2/21

to blink-dev, Nate Chapin

API spec

Yes

Summary

A new API, window.appHistory, which provides the ability to intercept navigations as well as introspect an application's history entries. This provides a more useful alternative to window.history, specifically aimed at the needs of single-page web applications.

Blink component

Blink>Loader

Motivation

The existing window.history API is hard to deal with in practice, especially for single-page applications. In the best case, developers can work around this with various hacks. In the worst case, it causes user-facing pain in the form of lost state and broken back buttons, or the inability to achieve the desired navigation flow for a web app.

Initial public proposal

https://github.com/WICG/proposals/issues/20

TAG review

https://github.com/w3ctag/design-reviews/issues/605

TAG review status

Pending

Risks

Interoperability and Compatibility

The biggest interoperability risk with this API is that it is building on a rocky foundation. The existing session history spec does not match browsers very well, and browsers do not match each other. Since this new API layers on top of the existing model, this could cause issues.

We plan to address this by having solid and well-tested specifications for all aspects of the new API, as well as every way the new API integrates with window.history. Additionally, we're working in parallel to improve interoperability on the base model through spec updates, writing web platform tests, and fixing browser bugs.

Gecko: No signal

WebKit: No signal

Web developers: Strongly positive: Twitter announcement engagement; WICG announcement engagement; issue tracker engagement; particularly strong individual cases: 1, 2, 3. Many developers have gotten excited and involved. In addition, we have several conversations going on with frameworks, libraries, and larger websites to ensure that we're solving the problems they see with today's history API.

Ergonomics

Although this API layers onto the same underlying model as window.history, and will have well-specified interactions with it, the exact integrations may be confusing. (For example, appHistory.push() will behave differently from history.pushState().) We'll do our best to smooth over these rough edges where possible, but will favor making the app history API pleasant to use over making it perfectly align with window.history.

From a performance standpoint, there are some potential challenges regarding exposing information and intercepting navigations that are usually handled in the browser process to the renderer process, and ensuring everything stays synchronized. We will explore this further as we prototype.

Activation

This feature would benefit significantly from polyfills, so that developers can use the new app history API even in browsers that don't yet support it. It's still an open question how polyfillable the API will be, which we'll be investigating as we go, but early indications are promising.

Security

We believe the security risks of this feature are minimal because of how it is scoped to same-origin contiguous history entries, and similarly only allows interception of same-origin navigations. We also need to ensure that we don't allow "trapping" the user by preventing them from using their back button; the API is designed to prevent this.

Is this feature fully tested by web-platform-tests?

Not yet, but this is a crucial part of the plan to address the interop risks.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1183545

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6232287446302720

This intent message was generated by Chrome Platform Status and then hand-edited.

Reply all

Reply to author

Forward

0 new messages