- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 16 Nov 2010 12:15:40 -0800
- To: Dmitry Titov <dimich@chromium.org>
- Cc: Anne van Kesteren <annevk@opera.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Adrian Bateman <adrianba@microsoft.com>, Arun Ranganathan <aranganathan@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>
On Tue, Nov 16, 2010 at 10:42 AM, Dmitry Titov <dimich@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
Received on Tuesday, 16 November 2010 20:16:34 UTC