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/CAM0wra_5ZASTw%2BwLQVceU9%2BbxfH_m6smp%3DCZJV%3DRkBv3TxpyiQ%40mail.gmail.com.
