User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36 Edg/88.0.705.81

Steps to reproduce:

Run this minimal repro: https://jsfiddle.net/hLqcxvu6/2/. Look at the console output.

Actual results:

The response arraybuffer has byteLength of 0.

Expected results:

The response arraybuffer should be a 20 byte buffer. Note that the same repro returns the correct result in Chrome. It also returns 0-byte arraybuffer in IE if that matters.

So, we took a quick look at this and we found that expanding the range to e.g. 100 or 200 does result in some response bytes. And those bytes match what Chrome is showing, but the overall content size that we see is smaller. One hypothesis is that because of the special content-type and also gzip compression, we don't know how to interpret the incoming data, and so when receiving only 20 bytes, we drop the content because we can't make any sense of it.

Could you let us know if this is reproducible with a simple content-type like text/plain and from a server that doesn't gzip the response bytes?

Unfortunately, I don't have a server with content-type text/plain that supports range requests or know how to set one up.

I hacked up one of the xpcshell-tests in this patch and it seems to work properly with a text/plain response.
So likely a bug related to our gzip decoding? I wonder if we're hitting this branch

Sounds like this can be downgraded to P3.