- From: Glenn Maynard <glenn@zewt.org>
- Date: Thu, 3 Jan 2013 19:42:24 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@whatwg.org, Hans Muller <hmuller@adobe.com>, Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>
On Thu, Jan 3, 2013 at 6:49 PM, Ian Hickson <ian@hixie.ch> wrote:
> > As an aside, it's odd that if images are unsupported or disabled, no
> > event is fired at all ("update the image data", step 4). That means
> > that if you do this:
> >
> > var url = URL.createObjectURL(blob);
> > img.src = url;
> > img.onload = img.onerror = function(e) { URL.revokeObjectURL(url); }
> >
> > the blob will leak a reference if images are disabled. This seems like
> > a very easy mistake to make, with no clean workaround...
>
> It'd be pretty sad to use up all that bandwidth for no reason...
>
Loading the image and discarding the data isn't an option, of course--the
very reason some people disable images is to save bandwidth.
It might make sense to fire onerror if the image doesn't get loaded because
images are disabled. Guaranteeing (or coming closer to guaranteeing, at
least) that onload or onerror will always be fired would reduce the
differences in event flow when images are disabled.
The particular case above should be fixed, at least in the most common
cases, by auto-revoking blobs, since you'll no longer need to carefully
call revokeObjectURL. (I've come to the conclusion that
URL.revokeObjectURL was a very badly flawed idea, since it introduces
manual resource management in a platform not designed for it.)
--
Glenn Maynard
Received on Friday, 4 January 2013 01:42:49 UTC