Steps to reproduce: 1. Open the attached test case. 2. Drop a huge file. 3. See the elapsed time. 4. Comment out the `revokeObjectURL` call. 5. Repeat the above step 1 to 3. Actual result: 3. would be much slower than 5. Expected result: 3. should be as fast as 5. According to the spec, the blob object will be held when the URL is parsed in the open() method (for XHR).[1][2] But the current BlobURLChannel does not hold a blob, only nsInputStream.[3] So I think we need following changes: 1. Change BlobURLChannel to hold a BlobImpl instance instead of nsInputStream. 2. Add a method to get the BlobImpl instance from BlobURLChannel. 3. Blob responses should take the response using the added method instead of parsing the URL again using GetBlobURIFromChannel and NS_GetBlobForBlobURI. Also, an automated test should be added to make sure that we took the optimized path. In mochitests, `SpecialPowers.wrap(xhr).channel.status == Cr.NS_ERROR_FILE_ALREADY_EXISTS` will indicate if we took the optimized path. (I have no idea how we test `fetch` unless we have some ChromeOnly extensions.) [1] https://xhr.spec.whatwg.org/#dom-xmlhttprequest-open [2] https://url.spec.whatwg.org/#concept-url-parser [3] https://dxr.mozilla.org/mozilla-central/rev/f87eeba88f1cf3f4d41095f7a58cb518a59f844c/dom/file/uri/BlobURLChannel.h#43