Re: [FileAPI] createObjectURL isReusable proposal

On 27.3.2012 11:43, Robert O'Callahan wrote: On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson mailto:i...@hixie.ch>> wrote: > Anything's possible, but I think the pain here would far outweigh the > benefits. There would be some

Re: [FileAPI] createObjectURL isReusable proposal

On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking wrote: > On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson wrote: > > Anything's possible, but I think the pain here would far outweigh the > > benefits. There would be some really hard questions to answer, too (e.g. > > what would innerHTML return? If yo

Re: [FileAPI] createObjectURL isReusable proposal

On 1.3.2012 4:38, Feras Moussa wrote: We think the new property bag (objectURLOptions) semantics in the latest editors draft are very reasonable. We have an implementation of this and from our experience have found it very widely used internally with app developers - many leverage it as a way t

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Feb 29, 2012 at 9:38 PM, Feras Moussa wrote: > >Another case: whether loading a one-shot URL from a different origin, > >where you aren't allowed to load the content, still causes the URL to > >be revoked. (My first impression was that it shouldn't affect it at > >all, but my second imp

RE: [FileAPI] createObjectURL isReusable proposal

like to see the spec updated to clarify the points listed above and I'd be happy to help with these changes in any way possible. Thanks, Feras > -Original Message- > From: Bronislav Klučka [mailto:bronislav.klu...@bauglir.com] > Sent: Friday, February 24, 2012 1:10

Re: [FileAPI] createObjectURL isReusable proposal

On 24.2.2012 20:49, Arun Ranganathan wrote: On 24.2.2012 20:12, Arun Ranganathan wrote: Bronislav, I could also go with reverse approach, with createObjectURL being oneTimeOnly by default createObjectURL(Blob aBlob, boolean? isPermanent) instead of current createObjectURL(Blob aBlob, boolea

Re: [FileAPI] createObjectURL isReusable proposal

> On 24.2.2012 20:12, Arun Ranganathan wrote: > > Bronislav, > > > > > >> I could also go with reverse approach, with createObjectURL being > >> oneTimeOnly by default > >> createObjectURL(Blob aBlob, boolean? isPermanent) > >> instead of current > >> createObjectURL(Blob aBlob, boolean? isOneTime)

Re: [FileAPI] createObjectURL isReusable proposal

On 24.2.2012 20:12, Arun Ranganathan wrote: Bronislav, I could also go with reverse approach, with createObjectURL being oneTimeOnly by default createObjectURL(Blob aBlob, boolean? isPermanent) instead of current createObjectURL(Blob aBlob, boolean? isOneTime) the fact, that user would have

Re: [FileAPI] createObjectURL isReusable proposal

Bronislav, > I could also go with reverse approach, with createObjectURL being > oneTimeOnly by default > createObjectURL(Blob aBlob, boolean? isPermanent) > instead of current > createObjectURL(Blob aBlob, boolean? isOneTime) > the fact, that user would have to explicitly specify, that such URL

Re: [FileAPI] createObjectURL isReusable proposal

On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful in mitigating

Re: [FileAPI] createObjectURL isReusable proposal

On 14.2.2012 15:20, Glenn Maynard wrote: 2012/2/14 Bronislav Klučka > The point of reusable Blob URL is the compatibility with regular URL, not having reusable URL would create unpleasant dichotomy in data manipulating... The point is avoiding

Re: [FileAPI] createObjectURL isReusable proposal

2012/2/14 Bronislav Klučka > The point of reusable Blob URL is the compatibility with regular URL, not > having reusable URL would create unpleasant dichotomy in data > manipulating... > The point is avoiding the error-prone need to release resources by hand. -- Glenn Maynard

Re: [FileAPI] createObjectURL isReusable proposal

On 14.2.2012 14:39, Charles Pritchard wrote: On 2/14/2012 5:35 AM, Bronislav Klučka wrote: On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality?

Re: [FileAPI] createObjectURL isReusable proposal

On 2/14/2012 5:35 AM, Bronislav Klučka wrote: On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most commo

Re: [FileAPI] createObjectURL isReusable proposal

On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful in mitigating

Re: [FileAPI] createObjectURL isReusable proposal

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson wrote: > On Thu, 2 Feb 2012, Arun Ranganathan wrote: >> >> 2. Could we modify things so that img.src = blob is a reality? Mainly, >> if we modify things for the *most common* use case, that could be useful >> in mitigating some of our fears. Hixie, is th

Re: [FileAPI] createObjectURL isReusable proposal

If you can't be civil, I'm not going to discuss with you. 2012/2/4 Bronislav Klučka > > > On 4.2.2012 5:55, Glenn Maynard wrote: > >> 2012/2/3 Bronislav Klučka > Bronislav.Klucka@**bauglir.com >> >> >> >>How would you create copies programmaticaly? How would you >>reassign src attribute

Re: [FileAPI] createObjectURL isReusable proposal

On 4.2.2012 5:55, Glenn Maynard wrote: 2012/2/3 Bronislav Klučka > How would you create copies programmaticaly? How would you reassign src attribute of one image to another? The idea, that sometimes the attribute would return string (regular URL

Re: [FileAPI] createObjectURL isReusable proposal

2012/2/3 Bronislav Klučka > How would you create copies programmaticaly? How would you reassign src > attribute of one image to another? The idea, that sometimes the attribute > would return string (regular URL, FileSystem APi URL) sometimes Blob... > What would you do in case like this > > img.

Re: [FileAPI] createObjectURL isReusable proposal

On 3.2.2012 15:13, Anne van Kesteren wrote: On Thu, 02 Feb 2012 22:40:12 +0100, Ian Hickson wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful in

Re: [FileAPI] createObjectURL isReusable proposal

On Thu, 02 Feb 2012 22:40:12 +0100, Ian Hickson wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful in mitigating some of our fears. Hixie, is this poss

Re: [FileAPI] createObjectURL isReusable proposal

On 3.2.2012 8:24, Charles Pritchard wrote: On 2/2/12 11:08 PM, Bronislav Klučka wrote: On 3.2.2012 7:51, Charles Pritchard wrote: I see no reason why an author should expect to stash 100MB of objects into createObjectURL, nor any reason why a UA could not manage 100MB for the application lif

Re: [FileAPI] createObjectURL isReusable proposal

On 2/2/12 11:08 PM, Bronislav Klučka wrote: On 3.2.2012 7:51, Charles Pritchard wrote: I see no reason why an author should expect to stash 100MB of objects into createObjectURL, nor any reason why a UA could not manage 100MB for the application lifetime; the user can certainly be informed, as

Re: [FileAPI] createObjectURL isReusable proposal

On 3.2.2012 7:51, Charles Pritchard wrote: On 2/2/12 10:40 PM, Bronislav Klučka wrote: On 3.2.2012 7:34, Bronislav Klučka wrote: On 28.1.2012 8:47, Ian Hickson wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher wrote: I'm not sure what a concret

Re: [FileAPI] createObjectURL isReusable proposal

On 2/2/12 10:40 PM, Bronislav Klučka wrote: On 3.2.2012 7:34, Bronislav Klučka wrote: On 28.1.2012 8:47, Ian Hickson wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher wrote: I'm not sure what a concrete proposal would look like. Maybe Element.URL

Re: [FileAPI] createObjectURL isReusable proposal

On 3.2.2012 7:34, Bronislav Klučka wrote: On 28.1.2012 8:47, Ian Hickson wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher wrote: I'm not sure what a concrete proposal would look like. Maybe Element.URL.createObjectURL or just Element.createObject

Re: [FileAPI] createObjectURL isReusable proposal

On 28.1.2012 8:47, Ian Hickson wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher wrote: I'm not sure what a concrete proposal would look like. Maybe Element.URL.createObjectURL or just Element.createObjectURL? Wouldn't returning an object (which can

Re: [FileAPI] createObjectURL isReusable proposal

On 2.2.2012 21:25, Arun Ranganathan wrote: Well, I'm a fan of img.src = blob being made a reality, *and* of the URL API being solidified. I'm not 100% sure how we can scope create* to an Element in the DOM. While open to a suggestion that clarifies your thoughts on this, I'm worried that

Re: [FileAPI] createObjectURL isReusable proposal

On Thu, Feb 2, 2012 at 4:48 PM, Charles Pritchard wrote: > Blob.prototype.toString=function(){ return URL.createObjectURL(this); > }; > We *really* don't want to make a function that gets automatically called "leak" memory like this. - Kyle

Re: [FileAPI] createObjectURL isReusable proposal

On Feb 2, 2012, at 1:40 PM, Ian Hickson wrote: > On Thu, 2 Feb 2012, Arun Ranganathan wrote: >> >> 2. Could we modify things so that img.src = blob is a reality? Mainly, >> if we modify things for the *most common* use case, that could be useful >> in mitigating some of our fears. Hixie, i

Re: [FileAPI] createObjectURL isReusable proposal

On Thu, 2 Feb 2012, Arun Ranganathan wrote: > > 2. Could we modify things so that img.src = blob is a reality? Mainly, > if we modify things for the *most common* use case, that could be useful > in mitigating some of our fears. Hixie, is this possible? Anything's possible, but I think the pain

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson < i...@hixie.ch > wrote: > > (From Glenn Maynard) > > > I think it's dangerous to assume that the URL will only be > > dereferenced > > > once. For example, it would mean that the above image would break > > if > > the > > > user toggled images off

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 17:51, Boris Zbarsky wrote: The same blob should have different URLs in different documents, no? All documents originated from the same application/session/same-origin? No. That's the point. Unless you want the lifetime of the Blob to immediately become "while you have any do

Re: [FileAPI] createObjectURL isReusable proposal

On Sat, 28 Jan 2012, Kyle Huey wrote: > > Why though? What stops UAs from accepting the relevant objects for .src > properties? You don't necessarily have an object, e.g. if you're using innerHTML or document.write(). -- Ian Hickson U+1047E)\._.,--,'``.fL

Fwd: Re: [FileAPI] createObjectURL isReusable proposal

Original Message Subject:Re: [FileAPI] createObjectURL isReusable proposal Date: Mon, 30 Jan 2012 17:51:55 +0100 From: Bronislav Klučka To: Boris Zbarsky On 30.1.2012 17:29, Boris Zbarsky wrote: On 1/30/12 11:15 AM, Bronislav Klučka wrote: In this case

Re: [FileAPI] createObjectURL isReusable proposal

On 1/30/12 11:44 AM, Bronislav Klučka wrote: Both could be solved by Blob.URL, there is no strange string somehow connected to blob. Blob belongs to URL and URL belongs to blob... who cares how exactly is the string created (split -> join), it is string identification, not pointer reference...

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 17:29, Boris Zbarsky wrote: On 1/30/12 11:15 AM, Bronislav Klučka wrote: In this case you got me... what sense does it make? If there is no reference to original blob or any other object using that URL, why is it kept? Because given a string there is no way to tell whether someo

Re: [FileAPI] createObjectURL isReusable proposal

On 1/30/12 11:15 AM, Bronislav Klučka wrote: In this case you got me... what sense does it make? If there is no reference to original blob or any other object using that URL, why is it kept? Because given a string there is no way to tell whether someone has a "reference" it. Consider this:

Re: [FileAPI] createObjectURL isReusable proposal

2012/1/30 Bronislav Klučka > so just a line > URL.createObjectUrl(blob) > creates a memory leak? Heh? > > Which brink me to my previous question, what happened to Blob.URL? Just > brink it back and this whole conversation can go away... > The only way blob.URL differs from URL.createObjectUrl is

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 16:56, Boris Zbarsky wrote: On 1/30/12 10:40 AM, Bronislav Klučka wrote: img1 = document.getElementById("my-image"); img1.src = URL.createObjectUrl(myBlob); img2.src = img1.src; should work like a charm and the URL and blob will be released as soon as all references will be 0 (des

Re: [FileAPI] createObjectURL isReusable proposal

On 1/30/12 10:40 AM, Bronislav Klučka wrote: img1 = document.getElementById("my-image"); img1.src = URL.createObjectUrl(myBlob); img2.src = img1.src; should work like a charm and the URL and blob will be released as soon as all references will be 0 (destroying the image) No, it won't. As curre

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 16:14, Glenn Maynard wrote: 2012/1/30 Bronislav Klučka > And how? Using src attribute? that would have to be changed to accept both string and Blob object? What it would return on get operation? Libraries managing images (lightboxes

Re: [FileAPI] createObjectURL isReusable proposal

2012/1/30 Bronislav Klučka > And how? Using src attribute? that would have to be changed to accept both > string and Blob object? What it would return on get operation? Libraries > managing images (lightboxes) would have to consider, what does src mean? Or > do you propose other attribute? What w

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 15:18, Glenn Maynard wrote: 2012/1/30 Bronislav Klučka > it would seem that you do not understand the point here... if we allow img.src = blob approach we would HAVE TO have memory management on language level as well, either UR

Re: [FileAPI] createObjectURL isReusable proposal

2012/1/30 Bronislav Klučka > it would seem that you do not understand the point here... if we allow > img.src = blob approach we would HAVE TO have memory management on language > level as well, > either URL reference or blob must be freed/nulled/whatever somewhere. > This is not simple reference

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 14:40, Kyle Huey wrote: 2012/1/28 Bronislav Klučka > img.src = blob; tells nothing about possible access to underlying data using URL identifier And I think that if we're concerned about the blob being "leaked" for the lifetime

Re: [FileAPI] createObjectURL isReusable proposal

2012/1/28 Bronislav Klučka > img.src = blob; > > tells nothing about possible access to underlying data using URL identifier > And I think that if we're concerned about the blob being "leaked" for the lifetime of the document (because the URL was never revoked) we should abandon the blob URL app

Re: [FileAPI] createObjectURL isReusable proposal

It's reference issue img.src = URL.createObjectUrl(blob) means, that you cannot GC that blob, because URL is just text representation of reference. img.src = URL.createObjectUrl(blob, true) means, that you can GC that blob, because once URL is dereferenced, it will not be dereferenced again (B

Re: [FileAPI] createObjectURL isReusable proposal

Why though? What stops UAs from accepting the relevant objects for .src properties? - Kyle On Sat, Jan 28, 2012 at 2:47 AM, Ian Hickson wrote: > On Sat, 28 Jan 2012, Kyle Huey wrote: > > On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher > wrote: > > > > > > I'm not sure what a concrete proposal w

Re: [FileAPI] createObjectURL isReusable proposal

On Fri, Jan 27, 2012 at 6:14 PM, Glenn Maynard wrote: > Something else that needs to be defined: does "xhr.open('GET', url)" > consume the URL, or does that only happen when xhr.send() is called? (I'm > not looking for the answer here, just giving an example of something that > needs to be clear

Re: [FileAPI] createObjectURL isReusable proposal

On 28.1.2012 7:10, Darin Fisher wrote: On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson > wrote: On Wed, 14 Dec 2011, Adrian Bateman wrote: > > [...] the first dereference of the URL revokes it. > > This means that you can do something like: > > im

Re: [FileAPI] createObjectURL isReusable proposal

On Sat, 28 Jan 2012, Kyle Huey wrote: > On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher wrote: > > > > I'm not sure what a concrete proposal would look like. Maybe > > Element.URL.createObjectURL or just Element.createObjectURL? > > Wouldn't returning an object (which can be GCd) be a better solu

Re: [FileAPI] createObjectURL isReusable proposal

On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher wrote: > I'm not sure what a concrete proposal would look like. Maybe > Element.URL.createObjectURL or just Element.createObjectURL? > Wouldn't returning an object (which can be GCd) be a better solution? - Kyle

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson wrote: > On Wed, 14 Dec 2011, Adrian Bateman wrote: > > > > [...] the first dereference of the URL revokes it. > > > > This means that you can do something like: > > > > imgElement.src = URL.createObjectURL(blob,false) > > > > and not worry about havin

Re: [FileAPI] createObjectURL isReusable proposal

On Fri, Jan 27, 2012 at 11:57 AM, Arun Ranganathan wrote: > I'd expect making this fully interoperable to be a complex problem. It > makes fetch order significant, where it currently isn't. > > For example, if two images have their @src attribute set to a URL one > after the other, what guarant

Re: [FileAPI] createObjectURL isReusable proposal

Glenn points out that the issues raised in this thread weren't totally taken to the mat. Once again, sorry for bad nesting in my response: > > We can certainly talk through some of these issues, though the > > amount > > of > > > work we'd need to do doesn't go down. Our proposal is a small > >

Re: [FileAPI] createObjectURL isReusable proposal

Adrian, - Original Message - > At TPAC [1,2] I described our proposal for adding an isReusable flag > to > createObjectURL. A common pattern we have seen is the need for a blob > URL > for a single use (for example, loading into an element) and then > revoking the URL. This requires a fa

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, 14 Dec 2011 11:25:38 +0100, Jonas Sicking wrote: On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren wrote: I think we should solve this by assigning an object directly to attributes that take a URL. So instead you would get imgElement.src = blob The problem is that we have tons

Re: [FileAPI] createObjectURL isReusable proposal

On 12/14/11 7:55 PM, Ian Hickson wrote: Browsers do keep them around for the lifetime of the page, in their HTTP cache. Browsers limit the size of the HTTP cache and evict as needed. -Boris

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 4:55 PM, Ian Hickson wrote: > On Wed, 14 Dec 2011, Glenn Maynard wrote: >> >> The problem isn't the cost of the URL mapping, it's the cost of keeping >> the backing Blob around.  If you drag around Google Maps for a long >> time, and it used object URLs to load its tile ima

Re: [FileAPI] createObjectURL isReusable proposal

On 12/14/2011 5:10 PM, Ian Hickson wrote: On Wed, 14 Dec 2011, Jonas Sicking wrote: On Wed, Dec 14, 2011 at 4:55 PM, Ian Hickson wrote: On Wed, 14 Dec 2011, Glenn Maynard wrote: The problem isn't the cost of the URL mapping, it's the cost of keeping the backing Blob around. If you drag aroun

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, 14 Dec 2011, Jonas Sicking wrote: > On Wed, Dec 14, 2011 at 4:55 PM, Ian Hickson wrote: > > On Wed, 14 Dec 2011, Glenn Maynard wrote: > >> > >> The problem isn't the cost of the URL mapping, it's the cost of > >> keeping the backing Blob around.  If you drag around Google Maps for > >> a

Re: [FileAPI] createObjectURL isReusable proposal

On 12/14/2011 4:55 PM, Ian Hickson wrote: On Wed, 14 Dec 2011, Glenn Maynard wrote: The problem isn't the cost of the URL mapping, it's the cost of keeping the backing Blob around. If you drag around Google Maps for a long time, and it used object URLs to load its tile images, it'd be very bad

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, 14 Dec 2011, Glenn Maynard wrote: > > The problem isn't the cost of the URL mapping, it's the cost of keeping > the backing Blob around. If you drag around Google Maps for a long > time, and it used object URLs to load its tile images, it'd be very bad > if the browser had to keep ever

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 7:40 PM, Ian Hickson wrote: > I think the better solution is to have implementations make keeping object > URLs defined be very cheap, so that nobody needs to ever release them. > The problem isn't the cost of the URL mapping, it's the cost of keeping the backing Blob aro

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, 14 Dec 2011, Adrian Bateman wrote: > > [...] the first dereference of the URL revokes it. > > This means that you can do something like: > > imgElement.src = URL.createObjectURL(blob,false) > > and not worry about having to call URL.revokeObjectURL to release the > Blob. I think it's d

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 3:56 PM, Glenn Maynard wrote: > Trying to use a one-time URL > >> twice is supposed to go wrong and I don't think it necessarily has to go >> wrong >> in exactly the same way in all browsers. You might have the same problem >> based >> on when you call revokeObjectURL in a

RE: [FileAPI] createObjectURL isReusable proposal

On Wed, 14 Dec 2011, Adrian Bateman wrote: On Wednesday, December 14, 2011 10:46 AM, Glenn Maynard wrote: We can certainly talk through some of these issues, though the amount of work we'd need to do doesn't go down. Our proposal is a small change to the lifetime management of the Blob URL and

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 3:00 PM, Adrian Bateman wrote: > I don't think we need interop for race conditions. The platform generally tries to eliminate the possibility for race conditions whenever possible. It's not always possible, of course, but adding a new category of races should be thought

RE: [FileAPI] createObjectURL isReusable proposal

On Wednesday, December 14, 2011 10:46 AM, Glenn Maynard wrote: > > We can certainly talk through some of these issues, though the amount of > > work we'd need to do doesn't go down. Our proposal is a small change to > > the lifetime management of the Blob URL and was relatively simple (for > > us)

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 11:27 AM, Adrian Bateman wrote: > On Wednesday, December 14, 2011 1:43 AM, Anne van Kesteren wrote: > > imgElement.src = blob > > 3. It's not very obvious what the lifetime of the blob should be if it goes > out of scope after this happens. > This, at least, seems st

RE: [FileAPI] createObjectURL isReusable proposal

On Wednesday, December 14, 2011 2:26 AM, Jonas Sicking wrote: > On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren > wrote: > > On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman > > wrote: > >> This means that you can do something like: > >> > >> imgElement.src = URL.createObjectURL(blob,false)

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 11:31 AM, Tab Atkins Jr. wrote: > On Tue, Dec 13, 2011 at 4:52 PM, Adrian Bateman > wrote: > > At TPAC [1,2] I described our proposal for adding an isReusable flag to > > createObjectURL. A common pattern we have seen is the need for a blob URL > > for a single use (for ex

RE: [FileAPI] createObjectURL isReusable proposal

On Wednesday, December 14, 2011 1:43 AM, Anne van Kesteren wrote: > On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman > wrote: > > This means that you can do something like: > > > > imgElement.src = URL.createObjectURL(blob,false) > > > > and not worry about having to call URL.revokeObjectURL to

Re: [FileAPI] createObjectURL isReusable proposal

On Tue, Dec 13, 2011 at 4:52 PM, Adrian Bateman wrote: > At TPAC [1,2] I described our proposal for adding an isReusable flag to > createObjectURL. A common pattern we have seen is the need for a blob URL > for a single use (for example, loading into an element) and then > revoking the URL. This

RE: [FileAPI] createObjectURL isReusable proposal

On Tuesday, December 13, 2011 10:41 PM, Simon Pieters wrote: > On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman > wrote: > > At TPAC [1,2] I described our proposal for adding an isReusable flag > > to createObjectURL. A common pattern we have seen is the need for a > > blob URL for a single use

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren wrote: > On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman > wrote: >> >> At TPAC [1,2] I described our proposal for adding an isReusable flag to >> createObjectURL. A common pattern we have seen is the need for a blob URL >> for a single use (f

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman wrote: At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a blob URL for a single use (for example, loading into an element) and then revoking the URL. This re

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman wrote: At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a blob URL for a single use (for example, loading into an element) and then revoking the URL. This

Re: [FileAPI] createObjectURL isReusable proposal

I've seen the same pattern, though mysteriously, running a revoke in the same loop still allows the image to be loaded. I may have made a mistake in reading those source files or it may be a special quirk in the order of event loading. However this is approached, I think it should have firm root

[FileAPI] createObjectURL isReusable proposal

At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a blob URL for a single use (for example, loading into an element) and then revoking the URL. This requires a fair amount of boilerplate code to handle the load/er