Open Bug 1497071 Opened 6 years ago Updated 2 years ago

The optimization for Blob responses does not work if the Blob URL is revoked early

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

People

(Reporter: emk, Unassigned)

References

Details

Attachments

(1 file)

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
Priority: -- → P3
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: