[whatwg] ProgressEvents for Images

[Ian Hickson]

On Thu, 12 Jan 2012, Hans Muller wrote:
>
> A group of us at Adobe has been looking into adding support for 
> ProgressEvents to images.  The overall goal is to simplify image 
> download progress reporting by supporting roughly the same progress 
> events as XHR and the File API for image elements.  For example one 
> could connect an image to a progress element like this:
> 
> <img id="image" src="sample.jpg"
>     onloadstart="showProgressBar()"
>     onprogress="updateProgressBar(event)"
>     onloadend="hideProgressBar()"/>
> 
> Developers have taken various tacks to enable progress reporting, for 
> example in some cases XHR can be used to download image files.  Max 
> Vujovic just published a blog about the practicalities of doing so: 
> http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/.  
> We think it would be preferable to provide support for image progress 
> events directly.
> 
> We're working on a prototype implementation for WebKit and have filed a 
> bug that explains what we're up to in a little more detail: 
> https://bugs.webkit.org/show_bug.cgi?id=76102).
> 
> It's probably worth pointing out that the beforeload event, which is 
> currently under discussion, addresses a different use case.  Our 
> proposal is intended to enable applications to give the user feedback 
> about image download progress, it's not intended to enable security or 
> efficiency by preemptively blocking or transforming image downloads.

I've added progress events (loadstart, progress, and loadend) to <img> 
processing.


On Mon, 23 Jan 2012, Jonas Sicking wrote:
> 
> For cross-site images this would leak the compressed size in bytes of 
> the loaded image (except when the crossorigin attribute is set). This 
> would very unfortunately in many cases leak sensitive information.
> 
> But if we restrict these events to only fire for same-origin loads, as 
> well as loads where the crossorigin attribute is in effect, then this 
> sounds like an awesome idea.

I've restricted the events in this way. ('loadstart' always fires; 
'progress' only fires if it's CORS-same-origin, and 'load', 'error', and 
'loadend' fire as simple rather than progress events if it's not 
CORS-same-origin).


On Mon, 23 Jan 2012, Hans Muller wrote:
> 
> A normalized image ProgressEvent would still reveal a little bit about 
> the server, even dispatching ProgressEvents with lengthComputable=false 
> would do so.  As you pointed out, we could avoid this issue altogether 
> by not dispatching progress events at all in the unauthorized cross-site 
> case, although doing so diminishes the utility of dispatching the 
> events.

If you want the events, just use CORS.


On Thu, 23 Feb 2012, Hans Muller wrote:
>
> Ian Hickson and I have been debating the merits of adding support for 
> the loadend event to images on 
> https://bugs.webkit.org/show_bug.cgi?id=76102. Dirk Schulze requested 
> that the discussion be relocated here, since it's about a feature and 
> not the details of an implementation change.
> 
> Here's a recap, if you don't want to wade through the bug comments:
> 
>   Hans - You're saying that the [image] loadend event is useless?
> 
>   Ian - Yes.  It only saves typing a few characters, img.onloadend =
> function () { }; vs:  img.onload = img.onerror = function () { };
> 
>   Hans - It's useful if you want your listener to run after all of the
> load listeners have run, and code that you haven't written adds its own
> load listeners.
> 
>   Ian - That seems like a rather obscure edge case, and you can work
> around it using setTimeout() (in the load/error event handler) anyway.
> 
> Before carrying on, I should point out that the proposal to add 
> loadstart, progress, and loadend events to Image was modeled on XHR and 
> based on the ProgressEvent spec http:// www.w3.org/TR/progress-events/. 

Note that progress events are now specced in http://xhr.spec.whatwg.org/.

 
> It may be that supporting the complete set of ProgressEvents for images 
> doesn't add enough utility to be warranted.  We proposed supporting all 
> of the ProgressEvents (even loadend) for the sake of consistency.  And 
> we're aware of the CORS issues.

I did add them all for consistency (well, almost all, I didn't add 
'stalled' and 'timeout'), but loadend is still basically useless. :-)


On Fri, 24 Feb 2012, Glenn Maynard wrote:
>
> It seems odd that loadend is considered useful enough to be recommended 
> by Progress Events, but not useful enough to be used here.

I don't think it's useful in other uses of Progress Events either.


> 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...

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'