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 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.
Historically failure to interop on things that were "supposed to go wrong"
hasn't resulted in people avoiding those things but instead has resulted
in them depending on the specific behaviour of one implementation.
