Intent to Ship: Allow popstate to fire before load

[Domenic Denicola]

Contact emails

dom...@chromium.org, jap...@chromium.org

Specification

https://github.com/whatwg/html/pull/7815

Summary

Before this change, Chromium would fire hashchange asynchronously (after a task), and delay popstate until the load event. This means the event ordering could be either [hashchange, popstate], or [popstate, hashchange], depending on how long the document took to load. After this change, Chromium will match Firefox and always fire popstate immediately upon URL changes, i.e. the order will always be [popstate, hashchange].

Blink component

Blink>History

Search tags

popstate, hashchange, load

TAG review

This is a small bugfix to increase interop and so should not need a TAG review.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Currently Chromium and Safari both have the nondeterministic delay-until-load behavior, whereas Firefox has the proposed deterministic behavior. We hope Safari will follow and adopt the deterministic behavior, since deterministic behavior is generally better for interop. We believe the compatibility risk here is minimal. Firefox has no reports of compat issues due to their timing. And sites can already observe both [popstate, hashchange] and [hashchange, popstate] orderings depending on network conditions; thus it should be quite hard for any sites to depend on the [hashchange, popstate] ordering which we are eliminating. We plan to launch this with a feature flag so that it can be remotely disabled using a Finch killswitch, just in case. And we will keep careful eye on any bug reports as this naturally makes its way through Canary/Dev/Beta channels.

Gecko: Shipped/Shipping

WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=239729) I don't think this is worth emailing webkit-dev about, so I just filed a bug. I am happy to email them if the API owners prefer.

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

As noted in the compat section, there is some risk here, although we believe it is small. We are using a base::Feature killswitch just in case this causes particular problems on Android WebView or elsewhere.

Debuggability

The usual DevTools ability to observe events is the only applicable thing here, and already exists.

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

Yes

Flag name

DispatchPopstateSync

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

DevTrial on desktop

103

DevTrial on Android

103

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5080172872073216

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

LGTM1

While this can be statistically web-observable (by origins noticing that they no-longer see hashchange followed by popstate), it seems safe to assume that it's hard for them to rely on this in some way. Thanks for improving interop here. Let's hope WebKit follows.

On Monday, April 25, 2022 at 7:00:11 PM UTC+2 Domenic Denicola wrote:

Contact emails

dom...@chromium.org, japhet@chromium.org

[Daniel Bratell]

LGTM2

/Daniel

--
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/fb7c5349-9ad8-4bce-bafc-764055e18f37n%40chromium.org.

[Mike Taylor]

LGTM3 - thanks for adding a killswitch just in case™.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/04fbe36a-19aa-53d6-29d8-2810e216b3fa%40gmail.com.