Bug 76102 - Add support for loadstart, progress, and loadend ProgressEvents to the IMG tag.
: Add support for loadstart, progress, and loadend ProgressEvents to the IMG tag.
Status: NEW
: WebKit
Images
: 528+ (Nightly build)
: All All
: P2 Enhancement
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2012-01-11 14:14 PST by
Modified: 2014-01-22 06:53 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-01-11 14:14:08 PST
Many applications that display large images, large numbers of images, or images that load slowly, would benefit from support for progress events. Displaying a progress indicator for work being done on the user's behalf is reassuring.  Support for progress events would make it straightforward for applications to do this when images are being loaded.

Currently some applications use XMLHttpRequest (XHR) to download image data while reporting progress. Doing so is somewhat complicated and can be inefficient.

This is a request to add support for loadstart, progress, and loadend events to the IMG tag. The semantics of the events would be roughly the same as for XHR or the File API. ProgressEvents would be dispatched for loadstart, progress, abort, error, load, and loadend. 

We suggest promoting the type of the existing IMG load, error, and abort events from Event to ProgressEvent.

ProgressEvents for cross-origin images should not reveal the actual resource size per http://www.w3.org/TR/progress-events/#security-considerations.  This could be avoided by dispatching ProgressEvents with lengthComputable=false (and loaded=0, total=0) for cross-origin images.   Alternatively we could dispatch a subclass of ProgressEvent with normalized total and loaded attributes.  A normalized image ProgressEvent wouldn't expose the actual size of the resource being downloaded but it would still enable developers to observe relative progress.  Normalization would set total to a constant like 1000, and loaded to a relatively correct value.
------- Comment #1 From 2012-02-06 15:17:26 PST -------
I'd recommend not sending any events at all for non-CORS-aware cross-domain images.
------- Comment #2 From 2012-02-06 16:44:52 PST -------
(In reply to comment #1)
> I'd recommend not sending any events at all for non-CORS-aware cross-domain images.

I assume that you don't mean that we should no longer dispatch the existing load/error/abort events for non-CORS-aware cross-domain images?   And if we're going to carry on dispatching those events, dispatching the companion loadend event wouldn't expose any new information.
------- Comment #3 From 2012-02-13 12:45:33 PST -------
I would only fire 'load' and 'error'.

I would avoid firing the other events because it either exposes information, in which case it's a security problem, or it exposes no information, in which case it's a useless API that will mislead authors.
------- Comment #4 From 2012-02-13 12:50:58 PST -------
(In reply to comment #3)
> I would only fire 'load' and 'error'.
> 
> I would avoid firing the other events because it either exposes information, in which case it's a security problem, or it exposes no information, in which case it's a useless API that will mislead authors.

The loadend event, which is what I assume you're characterizing as "useless", enables doing work after either the load or error listeners have run.   That seems useful on the face of it, and I assume that's why the ProgressEvent spec includes loadend.
------- Comment #5 From 2012-02-13 12:59:51 PST -------
"loadend" is basically uninteresting. It's just a shortcut to calling the same function from both the 'load' and 'error' handlers. It literally saves only a few characters:

   img.onloadend = function () { };

...vs:

   img.onload = img.onerror = function () { };
------- Comment #6 From 2012-02-13 15:32:32 PST -------
(In reply to comment #5)
If only one image error/load listener is used and you're defining it yourself then I agree that  there's definitely not much value in having a loadend event.  If other code contributes image listeners, then there is value.  For example:

function notMyShowImageFunction(image, url)
{
    image.onload = doSomethingAtLoadTime;
    image.src = url;
}

image.onloadend = doThisAfterAllLoadListenersHaveRun;
notMyShowImageFunction(image, "...");
------- Comment #7 From 2012-02-15 21:21:30 PST -------
That seems like a rather obscure edge case, and you can work around it using setTimeout() (in the load/error event handler) anyway.
------- Comment #8 From 2012-02-15 21:31:04 PST -------
(In reply to comment #7)
> That seems like a rather obscure edge case, and you can work around it using setTimeout() (in the load/error event handler) anyway.

Wouldn't it be better to move this discussion to #whatwg mailing list? I'd like to use bug reports for discussions about implementation details and not for general discussions about features.
------- Comment #9 From 2013-01-03 16:52:40 PST -------
Spec updated.
------- Comment #10 From 2013-05-21 03:50:25 PST -------
Any news on this?
Image progress events were added to the HTML spec:
http://www.whatwg.org/specs/web-apps/current-work/#the-img-element

Want this, need this. Been able to do this in Flash like, back in '99.. ;-(
------- Comment #11 From 2014-01-22 06:53:31 PST -------
Does anyone know if this bug is scheduled to be fixed soon?