beacon-readablestream.window.html fails because Gecko doesn't throw a TypeError when sendBeacon is called with a readable stream.

See
https://www.w3.org/TR/beacon/#sec-sendBeacon-method
https://www.w3.org/TR/beacon/#sec-processing-model
https://fetch.spec.whatwg.org/#concept-fetch
https://fetch.spec.whatwg.org/#concept-main-fetch
https://fetch.spec.whatwg.org/#concept-http-fetch
https://fetch.spec.whatwg.org/#ref-for-bodyinit-safely-extract
https://fetch.spec.whatwg.org/#bodyinit-safely-extract
https://fetch.spec.whatwg.org/#concept-bodyinit-extract

The problem here is that https://searchfox.org/mozilla-central/source/dom/webidl/Fetch.webidl#11 does not mention ReadableStream and we cannot really mention it because we don't support "upload" streams. This means however that IDL kicks in when someone passes a ReadableStream. What IDL does in that case is stringify as one of the BodyInit types is USVString. And that is allowed in combination with keepalive.

As there still doesn't seem to be much interest in pushing ReadableStream for "upload" streams to completion (more specification work is required), perhaps the solution here should be to remove that and split BodyInit in RequestBodyInit and ResponseBodyInit or some such?

Junior, this problem is with fetch()'s IDL which sendBeacon() uses. So I think the component should be DOM: Networking. Also, sendBeacon() is probably best maintained alongside fetch() and XMLHttpRequest.

That's fair. I was referring some beacon bugs before.

The component has been changed since the priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.