This issue is blocked on  issue 627309 : There are some tests calling promise-returning functions with this=null.

Looks like the blocking issue (627309) has been fixed. Anything else blocking work on this now?

There are still some failures in these tests, though it's hard to tell if they're the same as when this issue was filed.

Let's leave this as untriaged for someone working on Fetch to import these tests into Blink, or judge it as actually fixed already.

We will try to generate this data again, so closing this doesn't risk losing track of the problem long term.

I did a quick triage of what remains, in Canary (Version 57.0.2971.0 (Official Build) canary (64-bit)):

- http://w3c-test.org/fetch/api/basic/integrity-worker.html: causes a crash, and in fact causes a crash of all open tabs if I open all the tests in a single Canary window

- http://w3c-test.org/fetch/api/basic/scheme-about.html and -worker.html version: we disallow fetching about:blank, when we shouldn't

- http://w3c-test.org/fetch/api/headers/headers-idl.html: https://bugs.chromium.org/p/chromium/issues/detail?id=643712

- http://w3c-test.org/fetch/api/request/request-cache.html: this test seems to have been removed

- http://w3c-test.org/fetch/api/request/request-idl.html and http://w3c-test.org/fetch/api/request/request-structure.html :
  - https://bugs.chromium.org/p/chromium/issues/detail?id=643712
  - Request is mising attributes type, destination, and cache, as well as the formData method
- http://w3c-test.org/fetch/api/response/response-idl.html
  - https://bugs.chromium.org/p/chromium/issues/detail?id=643712
  - Response is missing the formData method
- http://w3c-test.org/fetch/nosniff/importscripts.html, http://w3c-test.org/fetch/nosniff/parsing-nosniff.html, http://w3c-test.org/fetch/nosniff/worker.html: presumably our nosniff implementation is not per spec
 

Thanks!

- http://w3c-test.org/fetch/nosniff/importscripts.html, http://w3c-test.org/fetch/nosniff/parsing-nosniff.html, http://w3c-test.org/fetch/nosniff/worker.html: presumably our nosniff implementation is not per spec

I've wondered where sniffing is specified. Can you tell me?

http://w3c-test.org/fetch/nosniff/parsing-nosniff.html

MimeSniffingResourceHandler::ShouldSniffContent() is using HttpResponseHeaders::GetNormalizedHeader() which returns values of headers with the specified name concatenated with ", ".

The test is expecting that the last occurrence of the "X-Content-Type-Options" header to be parsed and it prevents sniffing. When sniffing is prevented, the Content-Type header value is used which is "x/x" to fail the script element.

https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff? is saying that the first header should be used and these tests are for testing that (see https://github.com/w3c/web-platform-tests/pull/1715 ) though this algorithm is not used to control sniffing yet in the Fetch Standard.

http://w3c-test.org/fetch/nosniff/importscripts.html

Expecting a network error on importScripts() on a resource with non JavaScript MIME type as specified in the Main Fetch's step 16. Chrome doesn't throw a network error.

See
- https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-classic-worker-imported-script
- https://html.spec.whatwg.org/multipage/workers.html#dom-workerglobalscope-importscripts

Sniffing is defined by https://mimesniff.spec.whatwg.org/

Setting blocked on issue 643712 for fetch/api/headers/headers-idl.html so this bug will track however that turns out.

Is there a plan to import Fetch tests to external/wpt?

The workers team is starting to fix service worker WPT tests, and we're seeing  some failures are due to the Fetch API. For example, the Request constructor:
 https://codereview.chromium.org/2772013002/

We're going to add more Request tests to http/tests/fetch as we go, but it'd possibly de-duplicate effort if there are WPT tests already covering this or if we can commit directly to WPT tests.

> Is there a plan to import Fetch tests to external/wpt?

This just happened in bug 705490:
https://codereview.chromium.org/2778753002

From the above discussion it sounds like this is "triaged" - legitimate potential work on the network API team's backlog, just not given any particular priority yet.  Right?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

A few of the pass also in Safari and are thus Chrome-only failures:
https://wpt.fyi/results/fetch/api/policies/csp-blocked-worker.html?products=chrome%5Bexperimental%5D,edge%5Bstable%5D,firefox%5Bstable%5D,safari%5Bstable%5D&sha=434ca47448
https://wpt.fyi/results/fetch/api/redirect/redirect-location.any.html?products=chrome%5Bexperimental%5D,edge%5Bstable%5D,firefox%5Bstable%5D,safari%5Bstable%5D&sha=434ca47448

(from https://gist.github.com/foolip/bb5dc2b02cc87ac4412dcd348868edd1)