net::ERR_INSUFFICIENT_RESOURCES error when loading ~10 MB large blob by XHR
Reported by
bug.iss...@gmail.com,
Apr 4 2018
|
||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3387.0 Safari/537.36
Steps to reproduce the problem:
The general structure for the XHR is:
var xhr = new XMLHttpRequest();
xhr.onload = function()
{
if (xhr.status == 200)
{
var blob = xhr.response;
// do something...
}
};
xhr.open('GET', urlForLargeBlob, true);
xhr.responseType = 'blob';
xhr.send();
The mime-type for the response Content-Type header is application/octet-stream, and the returned blob is 10924129 bytes.
(There are also handlers defined for onerror, onabort, ontimeout, onprogress, and onloadend.)
What is the expected behavior?
No error during the XHR.
What went wrong?
Got error "Failed to load resource: net::ERR_INSUFFICIENT_RESOURCES".
Did this work before? Yes
Does this work in other browsers? Yes
Chrome version: 67.0.3387.0 Channel: n/a
OS Version: 10.0
Flash Version:
Workaround:
Set the response type to 'arraybuffer' instead of 'blob' and create a new Blob object from the response.
Worked with a Chromium build from this commit: https://chromium.googlesource.com/chromium/src/+/db579a7be98ed19502005f8ff27bce942cf393d4
Did not work with a Chromium build from this commit: https://chromium.googlesource.com/chromium/src/+/42cd4a84003a14c2098bc919534a912caaf86bce
It seems somewhere in between those commits, something broke it. This commit stands out: https://chromium.googlesource.com/chromium/src/+/090b1a4fea8bd71d2bd5e3503d3397985ad58022
,
Apr 5 2018
Attaching a simplified test.html that displays SUCCESS or FAILURE. Confirming the bisect range: 547242 (good) - 547257 (bad) https://chromium.googlesource.com/chromium/src/+log/1f34e493..42cd4a84?pretty=fuller Suspecting same.
,
Apr 5 2018
,
Apr 5 2018
Able to reproduce the issue on reported version 67.0.3387.0 using Mac 10.12.6, Ubuntu 14.04 and Windows-10, hence providing Bisect Info and assigning to suspect from comment#2 Bisect Info: ================ Good build: 67.0.3384.0 Bad build: 67.0.3385.0 Change Log: https://chromium.googlesource.com/chromium/src/+log/67.0.3384.0..67.0.3385.0?pretty=fuller&n=10000 Commit: https://chromium.googlesource.com/chromium/src/+/42cd4a84003a14c2098bc919534a912caaf86bce Change-Id: I4ca9bd292f53c897d2faf6d7d8a4faeb4dc1b18d Reviewed-on: https://chromium-review.googlesource.com/986716 @Tommy C. Li: Please confirm the issue and help in re-assigning if it is not related to your change. Adding ReleaseBlock-Stable as it is seems a receent break, feel free to remove it if not applicable. Thanks!
,
Apr 5 2018
No, the suspected CL from #c2 is same as reported originally: 090b1a4fea8bd71d2bd5e3503d3397985ad58022
,
Apr 5 2018
Hmm, seems to be something weird going on with how the blob system decides how much disk space it has available for blobs (and this is definitely caused by my CL)
,
Apr 5 2018
Well, it breaking XHR is caused by my CL. The blob system itself unfortunately was already broken, as it is never using more than 0 bytes of disk space (according to UMA histograms)
,
Apr 5 2018
,
Apr 23 2018
I believe this should be fixed with the bug it was blocked in being fixed. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by krajshree@chromium.org
, Apr 5 2018