On Tue, Nov 16, 2010 at 10:42 AM, Dmitry Titov <dim...@chromium.org> wrote: > I have a clarifying question about how it would work: > > How, if at all, the lifetime of the generated urls will be defined in case > of having those functions on URL interface object? > > If those methods are on a global object, the lifetime of the urls created > would be gated by the lifetime of that global object, and in browser > implementations that lifetime is usually defined well - and used for other > things like lifetime of shared workers for example. There is certain times > when the document/page/window are 'closed and detached', and while it varies > in implementations and it is more complex then that, it provides a > well-understood lifetime boundary. > > By having those methods on some static object, doesn't the lifetime becomes > unclear? Do we grab 'current context of the call'?
We'll use the window object through which the URL object was retrieved. So for example: myurl1 = frames[0].URL.createObjectURL(blob); myurl2 = frames[1].URL.createObjectURL(blob); in this case lifetime of the two urls are bound to the lifetime of the two different windows. Does that make sense? This is similar to how base-uri resolving works in XMLHttpRequest where the base uri for a given XMLHttpRequest is determined by which constructor was used to create it, not based by who is calling .open or calling the constructor. / Jonas