It is unclear if blocking no-cors is web-compatible

[smaug----]

Some background
https://wpt.fyi/results/fetch/orb/tentative/known-mime-type.sub.any.html?label=master&label=experimental&aligned&view=subtest&q=fetch%2F

Soon after orb was enabled on early Firefox beta we got
https://bugzilla.mozilla.org/show_bug.cgi?id=1823877
https://bugzilla.mozilla.org/show_bug.cgi?id=1823864

It is unclear though if any site is really broken.

@domenic do you know if Google has data about cross-origin no-cors usage?

[domenic]

I don't, but I'll try asking the teams working on ORB to comment.

[mikewest]

@otherdaniel can almost certainly help here.

[otherdaniel]

I don't have specific numbers on 'no-cors' usage, unfortunately.

Generally, ORB is surely a compatibilty risk, and we've had to rollback our initial attempts due to site breakage. (E.g. crbug.com/1359788) Our approach is to gradually increase our coverage of the proposal until we cover the whole functionality. The example in your bug reports wouldn't block in our current implementation, because so far we still inject empty responses and we don't implement the JS sniffing step.

[Edit: See comment below. The referenced bug isn't an ORB thing.]

[annevk]

@otherdaniel that breakage is due to CORB, not ORB, though. Only CORB attempts to sniff for HTML and therefore misidentifies the SVG.

[farre]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1823877 we're trying to make sure that filtered responses are filtered in such a way that we don't leak the filtered data. With ORB and Window.fetch+no-cors we have to do this anyway. I guess that ideally ORB would want to block all Window.fetch+no-cors? With the reasoning that a filtered response is almost indistinguishable from a NetworkError. I get that that would be hard right now, but that should be the end-game, right?

[annevk]

Ideally all "no-cors" would result in a network error, yes.

For fetch(), opaque responses can be stored (any context) and replayed (with a service worker) and when that is done for <img> the current setup ensures that continues to work.

[farre]

FetchEvent.respondWith's behavior for "no-cors" then becomes a thing to discuss I guess. In the ideal case I mean, since that is specified to have the behavior for "no-cors" fetches pre-ORB. Would we expect that to throw as well?

[annevk]

To be clear, my ideal above would also make <img> not work (as it does "no-cors" requests by default), so it's rather theoretical.

I would expect respondWith() to continue to work for "no-cors" things that do not get network error'ed by the ORB filter.