Intent to Experiment: App history API

310 views
Skip to first unread message

Domenic Denicola

unread,
Sep 24, 2021, 6:03:51 PMSep 24
to blink-dev, Nate Chapin

Contact emails

dom...@chromium.orgjap...@chromium.org

Explainer

https://github.com/WICG/app-history/blob/main/README.md

Specification

https://wicg.github.io/app-history/

Summary

The window.appHistory API 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>History

TAG review

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

TAG review status

Issues addressed

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 (https://github.com/mozilla/standards-positions/issues/543) Initial positive opinions on the issue, but not yet an official position

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-September/031987.html)

Web developers: Strongly positive (https://github.com/WICG/proposals/issues/20) The initial public proposal, as well as the issue tracker and Twitter, has had great engagement and enthusiasm from developers. 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.navigate() 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 is hard to polyfill, but developers have managed to produce something that works in many cases: https://github.com/frehner/appHistory We've also seen a pattern where developers have existing history wrappers (e.g. router libraries or app-specific history code) which they can adapt with a new app history-based backend for browsers that support it.



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.



Goals for experimentation

We have much of the core API developed, and want to validate that it helps developers in production. At least one large site is interested in swapping out their existing history API wrapper for one based on app history, and we want to validate that doing so produces the expected code simplifications and opportunities for new capabilities like loading spinner control. And, we want to validate that running it in production does not expose any new bugs that we have missed during dev trials.


Debuggability

This feature mostly has no need for extended tooling. https://bugs.chromium.org/p/chromium/issues/detail?id=1252940 tracks adding the newly-introduced events to the Event Listener Breakpoints panel.


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

Yes

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

Yes. (As of this writing, the Chromium results look bad because we landed a big API change that hasn't yet made its way to the wpt.fyi bots.)

Flag name

AppHistory

Requires code in //chrome?

False

Tracking bug

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

Launch bug

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

Estimated milestones

M96-M99

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6232287446302720

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/R1D5xYccqb0/m/8ukfzdVSAgAJ

This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Sep 24, 2021, 6:53:08 PMSep 24
to Domenic Denicola, blink-dev, Nate Chapin
LGTM to experiment M96-M99

On Sat, Sep 25, 2021 at 12:03 AM Domenic Denicola <dom...@chromium.org> wrote:

Contact emails

dom...@chromium.orgjap...@chromium.org

Explainer

https://github.com/WICG/app-history/blob/main/README.md

Specification

https://wicg.github.io/app-history/

Summary

The window.appHistory API 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>History

TAG review

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

I noticed that feedback from both the TAG and Mozilla mentioned the API's name as confusing. It might be worthwhile to consider alternatives.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_dVUPAFLrKYT6E7_tUO31B6w8Tt6ir1-OEETdf%2B-Atdw%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages