Intent to Ship: Allow popstate to fire before load

Skip to first unread message

Domenic Denicola

Apr 25, 2022, 1:00:11 PMApr 25
to blink-dev, Nate Chapin

Contact emails



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


Search tags


TAG review

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

TAG review status

Not applicable


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 ( 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.


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?


Flag name


Requires code in //chrome?


Tracking bug

Estimated milestones

DevTrial on desktop103
DevTrial on Android103

Anticipated spec changes


Link to entry on the Chrome Platform Status

This intent message was generated by Chrome Platform Status.

Yoav Weiss

Apr 27, 2022, 5:17:47 AMApr 27
to blink-dev, Domenic Denicola, Nate Chapin

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:

Daniel Bratell

Apr 27, 2022, 7:30:23 AMApr 27
to Yoav Weiss, blink-dev, Domenic Denicola, Nate Chapin



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
To view this discussion on the web visit

Mike Taylor

Apr 27, 2022, 9:17:42 AMApr 27
to Daniel Bratell, Yoav Weiss, blink-dev, Domenic Denicola, Nate Chapin
LGTM3 - thanks for adding a killswitch just in case™.
Reply all
Reply to author
0 new messages