I nominate @domenic :)

This test would be greatly improved by testing the values that document.readyState transitions through

I have greatly improved the test :)

It's worth noting (e.g. in the <p>) that this is only testable because both promise rejections and readystate change tasks use the DOM manipulation task source.

Sounds good to me

The fact that Chrome fails this is very believable to me; I believe there is a known bug (likely inherited from WebKit) with not doing the readyState transitions properly. /cc @domfarolino

I couldn't find anything, so I created some bug reports:

https://bugs.chromium.org/p/chromium/issues/detail?id=1027230
https://bugs.webkit.org/show_bug.cgi?id=204465

I'll give this a day in case anyone finds my modifications objectionable

Given the combined market share of Chrome & WebKit, I'm not certain changing the behaviors of Blink & WebKit make much sense here. It's probable that some web content out there is relying on the current behaviors of Blink and WebKit.

I believe we're planning to fix this in Blink.

It's starting to look like the behavior is dependent on network latency. Reviewers for both bug reports experienced a different (although also non-compliant) sequence of events.

For me, when I run this test over the web, I mostly see Chromium report all three events in the wrong sequence (unhandledrejection is first).

http://wptpr.live/20329/html/webappapis/scripting/processing-model-2/unhandled-promise-rejections/promise-rejection-event-during-parse.html

Though sometimes it fails by reporting, "assert_array_equals: lengths differ, expected 3 got 2" (because the unhandledrejection event didn't fire until after the load event).

However, if I use this URL:

http://wptpr.live/20329/html/webappapis/scripting/processing-model-2/unhandled-promise-rejections/promise-rejection-event-during-parse.html?pipe=trickle(147:d0.1)

...I see the second failure much more frequently. (That's using wptserve's "trickle" feature to delay the delivery of the document, inserting a 0.1-second pause after the 147th byte--immediately after the <script> tag for testharness.js.)

Both behaviors are incorrect according to the specification, and the inconsistency makes an argument about web compatibility less convincing.

I would remain skeptical and not supportive of this behavior change in WebKit until Chrome successfully ships. Even then I don't think we can commit to changing our behavior depending on how our compatibility story goes.

@domfarolino fixed the nit. Apologies for the delay, but I think this can be merged if it's green in CI.