[Bug 16790] The term microtask should be defined

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16790

--- Comment #7 from Ian 'Hixie' Hickson <ian@hixie.ch> 2012-04-18 21:30:46 UTC ---
(In reply to comment #6)
> (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).

If the author knows that the URL isn't being used anymore, I've nothing against
the author revoking it. But the browser doesn't know, so the browser shouldn't
do it automatically.


> 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.

Paging the data to disk is sufficient, and cheap.


> > 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.

Are we going to be specifying all the different places that can happen? I guess
if we specify it in detail that wouldn't be so bad.

-- 
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 21:30:57 UTC