LGTM2

/Daniel

On 2022-04-27 11:17, Yoav Weiss wrote:
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

    dome...@chromium.org, jap...@chromium.org <mailto:jap...@chromium.org>


            Specification

    https://github.com/whatwg/html/pull/7815
    <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
    
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHistory>


            Search tags

    popstate <https://chromestatus.com/features#tags:popstate>,
    hashchange <https://chromestatus.com/features#tags:hashchange>,
    load <https://chromestatus.com/features#tags: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
    <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 name

    DispatchPopstateSync


            Requires code in //chrome?

    False


            Tracking bug

    https://bugs.chromium.org/p/chromium/issues/detail?id=1254926
    <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
    <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 blink-dev+unsubscr...@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 <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fb7c5349-9ad8-4bce-bafc-764055e18f37n%40chromium.org?utm_medium=email&utm_source=footer>.

--
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+unsubscr...@chromium.org.
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.

Reply via email to