Remove definition of Blob.close() and all related terms.

[mkruisselbrink]

As discussed in #10, the utility of the close() method is unclear, and
properly specifying it would add a large amount of complexity.

By removing closing entirely, this fixes #10, fixes #17 and fixes #18.

References to readability state and blobs being closed in other specs (in particular HTML) will be removed in follow-up changes.

[domenic]

Wow, I always thought this was implemented everywhere, but I guess not in Chrome and Firefox at least. Nice.

[mkruisselbrink]

Wow, I always thought this was implemented everywhere, but I guess not in Chrome and Firefox at least. Nice.

Yeah, no browsers that I'm aware off ever shipped a non-prefixed version of Blob.close(). IE/Edge have a prefixed msClose, but I don't believe it really matches the behavior the spec would probably end up with if we'd keep it around/fix the definition. And Chrome has an even buggier implementation behind a flag that was never shipped at all.

[annevk]

This looks good. Thanks for doing this!

[annevk]

(And extra thanks for doing it properly with tests and such.)

[guest271314]

Yeah, no browsers that I'm aware off ever shipped a non-prefixed version of Blob.close().

close was implemented at Chromium at some point recently.

Given that (when last checked) Chromium limits the number of Blob object which can be created at a document to 50, what is the current suggested or canonical procedure to free memory of an existing Blob?

[annevk]

close is not in Chrome. You can just let it GC. Also, I can easily allocate a 1000 in Chrome... Anyway, those type of usage questions are best asked on Stack Overflow going forward.

[guest271314]

@annevk

At some point Chromium did implement close https://github.com/guest271314/MediaFragmentRecorder/blob/master/demos/recordMediaFragments.html#L221.

You can just let it GC.

That is an extremely broad statement without clear parameters, including the specific processing steps of "just let it" before even reaching "GC".

What is the available RAM and HD space at the device where you are able to create 1000 Blob objects without the tab crashing?

Running this https://github.com/guest271314/MediaFragmentRecorder/blob/master/demos/recordMediaFragments.html, where multiple Blob and Blob URLs are created, multiple times at a device having minimal RAM or available HD space has arbitrarily and inconsistently crashed the browser tab at Chromium.

When the Blob or Blob URL was closed or revoked the same was reflected at chrome://blob-internals.

What is the canonical approach to remove/purge the Blob snapshot state from the file which stores that data at Chromium and Firefox?

[guest271314]

@annevk FYI

This account is temporarily suspended to cool down. The suspension period ends on Jan 30 '19 at 2:22.

Should probably stop asking questions and just write the code to the extent able and possible.

[mkruisselbrink]

Yes, chrome implemented some attempt of a close() method (never shipped it though), but it had many bugs (largely because the functionality was never really specified), and actually specifying what close would do would be really complicated. It also was never the case that closing a blob in chrome would immediately cause anything to be freed, as there could be other references to the same data, etc, so even back when chrome had a hard limit on how large the total number of blobs could be just closing one wouldn't be enough to know that you could create more, as closing/freeing memory/disk space is inherently an async operation.

[guest271314]

close had to have been shipped at some point. As did use the method in code within the past two years. Why cannot we simply free the reference regardless if any other code references the Blob?

[mkruisselbrink]

Nope, chrome never shipped close, you must be misremembering (or were running with experimental web platform features turned on). But anyway, actually defining what close would do is much more complicated than "simply free the reference", especially as implementations internally do all kinds of things to share data, asynchronously move data around, etc.

[guest271314]

@mkruisselbrink Yes, the --enable-experimental-web-platform-features flag was used with Chromium. The feature appeared to be helpful when using a HD with only 500MB of available disk space; unless what blob-internals listed were actually false-positives.

What is the goal moving forward to relevant to the ability to remove the Blob snapshot state to free memory? Or is the goal of implementing close or similar functionality now abandoned?

[Ajaay]

I do think this warrants an answer or at least some direction. In our experience garbage collection does not remove blobs, and therefore the creation of a large number of blobs over time causes the memory used by Chrome to increase until it crashes.

The only way we found of getting around that was to use the close method in an electron app where we could enable experimental features without the user needing to do it on their standalone Chrome build.
We're now in a position where we cannot upgrade our Electron app because we lose the close method, which renders our app useless.

It's a reasonable question to ask what the proper method is of controlling memory use when creating large numbers of blobs on even reasonably specced machines.

[annevk]

@Ajaay did you file a bug against Chrome? Not sure how that's relevant to the standard, unless it would prevent GC somehow, but I don't think it does?