W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

RE: [FileAPI] createObjectURL isReusable proposal

From: Adrian Bateman <adrianba@microsoft.com>
Date: Wed, 14 Dec 2011 20:00:48 +0000
To: Glenn Maynard <glenn@zewt.org>
CC: Anne van Kesteren <annevk@opera.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, Feras Moussa <ferasm@microsoft.com>
Message-ID: <6895C7B67488C14AA23F0E079F0D7E8F199A57@TK5EX14MBXC284.redmond.corp.microsoft.com>
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) to implement. In our experience, createObjectURL is a good broker
> > in web developers minds for switching from object to URL space.
> 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 guarantees which one succeeds (presumably the first) and which fails
> (due to the first releasing the URL)?  The order in which synchronous sections
> after "await a stable state" are run isn't specified.  Combining different APIs
> which do similar things (eg. asynchronous XHR and HTMLMediaElement's resource
> selection algorithm) would compound the problem.
> Another possible problem, depending on where the blob release takes place: if
> the UA doesn't support images, "update the image data" for HTMLImageElement
> terminates at step 4; it would need to be careful to still release the blob
> URL when terminating before the fetch.
> This would probably have effects across a lot of specs, and couldn't be neatly
> tucked away in one place (such as inside the resource fetch algorithm); and it
> might force every API that performs fetches to worry about creating race
> conditions with other APIs.  Assigning the blob directly would still affect
> various specs, but it would be less likely to lead to blob leakage and subtle,
> possibly racy interop failures.

I don't think we need interop for race conditions. 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 applications today.

Received on Wednesday, 14 December 2011 20:19:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC