The first step here is to try running tryjobs on a CL that tweaks CORB so that it injects a net-error (instead of an empty-body) for responses destined to RESOURCE_TYPE_IMAGE, RESOURCE_TYPE_FONT_RESOURCE, RESOURCE_TYPE_MEDIA, RESOURCE_TYPE_FAVICON.

nick@, would you mind if I assign it to you for now?  I am not quite sure exactly how CrossSiteDocumentResourceHandler would need to be tweaked to inject a net error.  Maybe we can chat about this in person next Tuesday.

I've sketched this out, but after chatting with lukasz and charlie, I don't think we have as strong a motivation anymore to prefer a net error over an opaque filtered response.

If we want to pursue it, the basic idea that seems to work is to call next_handler_->OnResponseCompleted() with a net error, but not report a net error to |controller|, like this: https://chromium-review.googlesource.com/c/chromium/src/+/996397/4/content/browser/loader/cross_site_document_resource_handler.cc

Some issues: 
 - The CL above seems to break the "blocked by CORB" console warning.
 - There's a risk that changes here would break the "detach the response so that it can stream to the cache" behavior. I think we need a test of this, which I'll pursue separately.

Marking WontFix now, but if we decide to revisit this, hopefully there's enough information here to resume it.

We got some more feedback (see https://github.com/whatwg/fetch/issues/727) and it seems to me that we should revisit the decision to inject an empty response VS a network error for responses blocked by CORB.

Interestingly, CORB in Chromium *does* error out today if there is a DetachableResourceHandler present.  This is quite accidental and unexpected.  For a repro see the new CrossSiteDocumentBlockingTest.PrefetchIsNotImpacted test being added in https://crrev.com/c/1070601 - the test unexpectedly has to listen to link.onerror event (rather than to link.onload event).