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 [email protected], [email protected] > > Specificationhttps://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 componentBlink>History > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHistory> > > Search tagspopstate <https://chromestatus.com/features#tags:popstate>, > hashchange <https://chromestatus.com/features#tags:hashchange>, load > <https://chromestatus.com/features#tags:load> > > TAG reviewThis is a small bugfix to increase interop and so should not > need a TAG review. > > TAG review statusNot 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 > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ?Yes > > Flag nameDispatchPopstateSync > > Requires code in //chrome?False > > Tracking bughttps://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 > <https://chromestatus.com/>. > -- 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 [email protected]. 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.
