Tested this on OS X Sierra now - there it works fine in both Safari 9.1.3 and Chrome 54.0.2840.98 (64 bit). So this seems to be a Windows specific issue.

Seems to work fine for me on Windows (64bit version) and Ubuntu as well. I also tried backgrounding the tab because I wondered if it was caused by throttled timers in background tabs because you are holding onto the chunk in a setTimeout but it seems to work as well. I find that memory peaks around 600-700MB and then a GC kicks in and reduces the tab to ~60MB.

Perhaps you can provide a memory trace of the issue? See https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/README.md

Using IE/FF in Windows + and also on Chrome on OS X - memory never increases above ~150-200 MB when doing the same operation.

Try to open a 10GB file with this updated JSFiddle: https://jsfiddle.net/v0cu3npf/2/

(I increased chunksize to 200 MB).

It makes the browser crash after a few seconds after reaching 4 GB of consumed RAM.

Memory sheriffs PTAL.

Another demo of this http://jsbin.com/cekequd/quiet. Give the top input a large file & watch the console.

Firefox completes in ~500ms for a 900mb file, whereas Chrome chugs along then crashes.

Notably, Firefox doesn't offer result in progress events, which may be our downfall here.

If we were to offer progress events, we should allocate the whole array buffer before the first progress event, and write bytes to it for each progress event.

Related spec issue https://github.com/w3c/FileAPI/issues/79

As far as I can see, Chrome "deopts" if there's an onprogress listener. At least that makes it easy to put a use-counter on.

Looking at the code, in case of DataURLs we already should be not giving partial data URLs (but instead potentially give empty strings, which wouldn't be spec compliant either...)

But yeah, should be easy to use-count getting the result attribute before load has finished.

Actually it sees jake/the FileAPI spec issue are describing a very different situation from the original bug. Original bug had no progress events and did manual chunking, while jake's code does have a progress event and explicitly holds on to all the partial array buffers, which I'm not sure how that could do anything other than the described behavior.

Of course we could make it harder to shoot yourself in the foot by making the mentioned FileAPI change, but not sure there is really anything objectively wrong here.

And since I can't actually reproduce the originally reported issue anymore (memory usage stays low, even with several-GB files), marking this one as WontFix.

@jake: feel free to file a separate bug for your issue, although I'm not quite convinced that's actually a bug (other than that apparently other browsers don't behave the same).