For the record, the current CORB error message looks as follows:

    Cross-Origin Read Blocking (CORB) blocked
    cross-origin response <URL> with MIME type <type>.
    See https://www.chromestatus.com/feature/5629709824032768 for more details.

The message above is suppressed for:
- 4xx, 5xx error responses
- 204 empty responses (or responses with Content-Length: 0)

The message is generated in _finishNetworkRequest in third_party/blink/renderer/devtools/front_end/sdk/NetworkManager.js
This method has access to SDK.NetworkRequest object which includes
a |_resourceType| field of type Common.ResourceType which can be used
to differentiate between Common.resourceTypes.XHR and Common.resourceTypes.Fetch
and other types.

creis@ - can you please sanity-check the idea to suppress the CORB error message for XHR/fetch scenarios (but keep emitting it for other resource types like <img>, <script>, stylesheet, font, media, etc.)?

Good idea to improve these error messages where we can.

1) In the XHR/fetch no-cors case, is it true that there's no web visible change in behavior whether CORB kicks in or not?  That sounds plausible based on https://fetch.spec.whatwg.org/#concept-filtered-response-opaque.  If so, then I agree the CORB error message is just noise (and leads to confusion in cases likhttps://github.com/whatwg/fetch/issues/854), and I'm ok with skipping it.

If there are visible differences between no-cors fetches with and without CORB, then maybe we could use a customized error message for them?  Might depend on what the differences are, and whether we need to point out to developers why they might be seeing them.

(For your idea to suggest using cors mode on the fetch as a way of pointing out why the response is opaque, I think that's more in realm of fetch and CORS features than CORB.  We probably don't need to build a CORB message to suggest it.)

2) Skipping the CORB error message for XHR/fetch when cors mode is used makes sense, assuming that a CORS message would always be shown.  The CORS message is more useful to developers in this case, since it points them to how to fix it.

3) I think we want to keep CORB error messages for other subresource cases, since those technically have observable differences (e.g., whether a script tag generates a syntax error or not).


However, that's an interesting point about NetworkService not wanting to distinguish based on ResourceType-- is your plan in comment 3 feasible?  (How will we tell the difference between XHR/fetch and other types?)

RE: #c4: However, that's an interesting point about NetworkService not wanting to distinguish based on ResourceType-- is your plan in comment 3 feasible?  (How will we tell the difference between XHR/fetch and other types?)

Initially, I thought that the differentiation has to be done in //services/network/cross_origin_read_blocking.cc, but we can also tweak the error message and/or suppress the error message in _finishNetworkRequest in third_party/blink/renderer/devtools/front_end/sdk/NetworkManager.js.  While //services/network doesn't want to know about the resource type, this information is already available to //third_party/blink (and renderer/devtools/front_end/sdk/NetworkManager.js in particular - see #c2).

Charlie, for fetch() "no-cors" I think there's some interest in making it observable through https://github.com/whatwg/fetch/issues/727 (i.e., return a network error rather than a new kind of response). (XMLHttpRequest does not have "no-cors".)

I think the main ask here is that in addition to mentioning CORB as the reason something got blocked, it makes sense to advice folks to make a CORS request instead if they are so able, as that will also resolve the problem (CORB never blocks anything with mode "cors").

And that applies in general, as most subresources can be either "no-cors" or "cors" fetched.

Hope that helps.

One thing I realized is that CORS does not apply to extensions and their content scripts - this is an argument against suppressing CORB error message for no-"no-cors" scenarios.