Fetch: Add tests for AbortSignal's abort reason

[nidhijaju]

This PR adds test cases to check the functionality of AbortSignal's abort reason when aborting fetch.

See whatwg/fetch#1343 for accompanying spec changes.

[yutakahirano]

The added cases look good. I think we should test that the service worker can observe the fetch abort and see the contents of the abort reason.

[nidhijaju]

The added cases look good. I think we should test that the service worker can observe the fetch abort and see the contents of the abort reason.

I added a new test for this case, so hopefully it's looking better :) PTAL. Thank you!

[yutakahirano]

LGTM, thank you!

[noamr]

I'm missing a test that shows that the serialization happens on abort.
I would expect something like a live JS object that increments a counter every time it's accessed. The reason observed by the SW should show a "frozen" version from when the abort took place while other callers would still get the live object.

[nidhijaju]

I'm missing a test that shows that the serialization happens on abort. I would expect something like a live JS object that increments a counter every time it's accessed. The reason observed by the SW should show a "frozen" version from when the abort took place while other callers would still get the live object.

Apologies for the delay! I added a test, but I'm not sure if it's exactly what you were looking for. Would you be able to take a look? Thank you!

[MayyaSunil]

The test does not produce the required failure messages in the tests

I think the await here should be removed.
The above code will return a response object and not the promise which we need to pass it to promise_rejects_exactly.
The following code should solve the problem:

    const fetchPromise =  w.fetch('data.json', { signal });

Kindly check, I am not a JS expert :)

[annevk]

That seems correct @MayyaSunil. Could you create a PR?

[MayyaSunil]

Sure @annevk. I will submit the fix in mozilla's repo and let the sync bot do the job? Is it acceptable to you?

[annevk]

Yeah that works. It might be worth having another test like this whereby we do wait for the response and then check that response.body was errored with the correct exception if that doesn't exist already.

[MayyaSunil]

Bug 1798921 is created to track this

[MayyaSunil]

If the below patch is fine, I will submit it to our repo.

--- a/testing/web-platform/tests/fetch/api/abort/serviceworker-intercepted.https.html
+++ b/testing/web-platform/tests/fetch/api/abort/serviceworker-intercepted.https.html
@@ -114,13 +114,31 @@
     const controller = new w.AbortController();
     const signal = controller.signal;
 
-    const fetchPromise = await w.fetch('data.json', { signal });
+    const fetchPromise = w.fetch('data.json', { signal });
 
     controller.abort(error1);
 
     await promise_rejects_exactly(t, error1, fetchPromise);
   }, "fetch() rejects with abort reason");
 
+
+  promise_test(async t => {
+    const scope = SCOPE + "?q=aborted-with-abort-reason-in-body";
+    await setupRegistration(t, scope, '../resources/sw-intercept.js');
+    const iframe = await with_iframe(scope);
+    add_completion_callback(_ => iframe.remove());
+    const w = iframe.contentWindow;
+
+    const controller = new w.AbortController();
+    const signal = controller.signal;
+
+    const fetchResponse = await w.fetch('data.json', { signal });
+    const bodyPromise  = fetchResponse.body.getReader().read();
+    controller.abort(error1);
+
+    await promise_rejects_exactly(t, error1, bodyPromise);
+    }, "fetch() response body has abort reason");

[annevk]

That looks correct, yeah. Thanks @MayyaSunil!