- From: <bugzilla@jessica.w3.org>
- Date: Wed, 18 Apr 2012 20:08:58 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16790 --- Comment #6 from Glenn Maynard <glenn@zewt.org> 2012-04-18 20:08:57 UTC --- (In reply to comment #5) > I don't think it makes sense for URLs to ever start fail while the page that > created them is still up. This is arguing that URL.revokeObjectURL should be removed (or made into a no-op). This would mean that creating a blob URL would cause the blob's storage to be permanently unreleasable for the lifetime of the page. Blobs tend to be used for nontrivially large objects, so for any page that uses blob URLs in anything but a singleton fashion, this would cause significant memory leaks. This would make blob URLs essentially unusable. > Lots of things on the platform use URLs in a lazy > fashion. For example, <img src=""> doesn't necessarily load the image until the > user asks the browser to do so. All kinds of stuff in the HTML spec in fact > does fetching asynchronously, typically much later than the end of the current > task, let alone microtask. This has been discussed on the list: each API that performs fetches asynchronously will need to take a reference to the underlying blob data. For example, upon assigning a blob URL to img.src, HTMLImageElement would need to synchronously store the underlying data associated with the blob. It can then perform the fetch whenever it wants, without being affected by the URL being freed, or the Blob being neutered due to transfers or Blob.close. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 18 April 2012 20:09:04 UTC