This is the test in question:

 const client = new XMLHttpRequest client.onloadstart = t.step_func(() => { assert_throws("InvalidStateError", () => client.setRequestHeader("General", "Organa")) assert_throws("InvalidStateError", () => client.withCredentials = true) assert_throws("InvalidStateError", () => client.send()) client.onloadstart = null client.open("GET", "data:,BB-8") client.send() }) client.onload = t.step_func_done(() => { assert_equals(client.responseText, "BB-8") }) client.open("GET", "data:,R2-D2") client.send() 

The outer send() call will first get to step 11.1, with the XHR's state being "opened with the send flag set". The onloadstart handler will then be run. After that completes its inner send() call (which will initiate a fetch), the XHR's state will again be "opened with the send flag set", so step 11.3 will be skipped and a second fetch will begin for the outer send() call's request.

Now for this specific test it's likely that the data URLs will complete in the order given, and the test will consistently pass. However, there would be no guarantee of their ordering if the requests are made over the network, so this test doesn't seem to work in the general case with the current spec text. Given that this test implies that the web relies on the inner fetch "winning" and terminating the outer one, it seems that step 11.3 will need to be strengthened to better-detect this kind of recursion and skip doing the outer fetch.