In general we are OK with changing it to the autoRevoke behavior below, but have some concerns around changing the default behavior. Changing the default behavior is a breaking change and any apps which expect the URL to work multiple times will now be broken. In Windows 8, we also implemented the oneTimeOnly behavior and it was very widely used, these consumers will be broken as well.
We would like to support autoRevoke as the default as it helps reduce the chance of leaking unintentionally, but we think developers should have a way to feature detect the new change. If a developer can feature detect which default behavior is present, then they can reason about what to expect from the API. If a way is provided for developers to detect the change, then we support this change. Additionally, we support the changes outlined in the bug at https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765, and feel it resolves several of the edge cases we saw when implementing the File API. From: Arun Ranganathan [mailto:aranganat...@mozilla.com] Sent: Wednesday, July 11, 2012 1:20 PM To: Glenn Maynard Cc: Rich Tibbett; public-webapps; Arun Ranganathan; Jonas Sicking Subject: Re: [File API] Blob URI creation On May 30, 2012, at 6:48 PM, Glenn Maynard wrote: On your main question, I've had the same thought in the past--a "url" property on Blob which simply creates a new auto-revoking blob URL. I didn't bring it up since I'm not sure if creating a URL for a blob is actually something you do so often that it's worth having a shortcut. If so, a function is probably better than a property--more future-proof, and it'd be unusual on the platform to have a property that returns a different value every time you read it. On Wed, May 30, 2012 at 1:50 PM, Rich Tibbett <ri...@opera.com> wrote: Yes, this might be a better solution. I was working on what was available in the editor's draft and looking for a way to remove the need to ever call revokeObjectUrl. This is part of what's wrong with oneTimeOnly--it *doesn't* actually completely remove the need to call revokeObjectUrl. For example: function f(blob) { var url = URL.createObjectURL(blob, {oneTimeOnly: true}); if(showImage) img.src = url; else URL.revokeObjectURL(url); } Without the revoke case, the URL (and so the whole blob) is leaked as it's never actually used. autoRevoke doesn't have this problem. Arun/Jonas: Can we hide this feature in the spec before more people implement it, or at least tag it with "not ready for implementations" or something? I'll do one better, and introduce autoRevoke semantics: http://www.w3.org/TR/2012/WD-FileAPI-20120712/#creating-revoking By default, this does not need a corresponding revokeObjectURL() call. In order for Blob URLs to persist past a stable state (for that unit of script) createObjectURL has to be invoked with autoRevoke set to false. That is, you shouldn't ever have to pass a Blob URI obtained via Blob.getURL through revokeObjectUrl because it assumes some auto-revocation behavior. Using microtasks to release at the next stable state does seem ok as long as developers have a very good understanding of when a Blob URI will be implicitly revoked. Saying that you can use a Blob URI exactly once, as per onetimeonly could still end up being easier to understand though. (s/microtasks/stable states/; they're not quite the same) It's actually a bit hard to understand (or easy to misunderstand), since there's no clear concept of "using a URL". For example, if you start two XHR's on the same URL one after the other in the same script, the order in which the fetches actually begin is undefined (they happen in different task queues), so which would succeed is undefined. (Some work would also be needed here for the autoRevoke approach, but it's much simpler.) autoRevoke is pretty simple from the user's perspective: the URL is revoked when your script returns to the browser. In fact, I think this addresses the lion's share of use cases, and if a developer wants to explicitly create "longer lasting" Blob URLs, they have that option (just not by default). -- A*
