Mistake, the spec doesn't say to fire both load and error. It says to fire load if the load was successful, without checking if the image is corrupt first.

I believe the spec matches reality here. Browsers fire 'load' before they inspect the data in some cases. Do you have a test case demonstrating otherwise?

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1318

The spec requires 'load' but Opera/Firefox/Chrome fire 'error'

This bug was cloned to create bug 18039 as part of operation convergence.

Huh. bz, can you take a look at this and see if you have any insight? I think it was you who pointed out that in some cases you fire 'load' before you have deeply inspected the image data (but I could be wrong).

I believe that Gecko will fire load or error after it has all the image data but possibly before it's decoded it all.  In particular, it will decode some amount of data (there's a data size below which the decode is sync), then do the rest of decode async and fire the load or error, depending on which one is relevant.

I'll double-check whether my believe is correct.

And in particular, there are various cases in which I think Gecko suppresses decoding indefinitely (until something asks for the decoded data).  And more in which we would like to do so.  It would be pretty unfortunate if the spec precluded this.

(In reply to comment #6)
> I believe that Gecko will fire load or error after it has all the image data
> but possibly before it's decoded it all.  In particular, it will decode some
> amount of data (there's a data size below which the decode is sync), then do
> the rest of decode async and fire the load or error, depending on which one is
> relevant.
> 
> I'll double-check whether my believe is correct.

Yes. The callback in which we fire onerror is unfortunately named OnStopDecode (jdm will fix this soon), but it's fired at the end of the load.

I investigated this behavior back when I was implementing decode-on-draw. Here's the relevant comment:

https://bugzilla.mozilla.org/show_bug.cgi?id=435296#c27

Here's the most relevant bit.

> If this instantiation fails, we fire "onerror". If it succeeds, we fire
> "onload". Thus, the only cases where we fire onerror are:
> 1) The URL is somehow invalid or ruffles the feathers of the content policy
> 2) A network error occurs before all the data arrives
> 3) The first few (sniffed) bytes give us an invalid mimetype, an we balk on
> decoder instantiation
>
> Otherwise, we fire onload once the network request completes. Furthermore, I
> did some testing and this exact behavior is replicated in safari and chrome
> (I don't have IE handy).


(In reply to comment #7)
> And in particular, there are various cases in which I think Gecko suppresses
> decoding indefinitely (until something asks for the decoded data).  And more in
> which we would like to do so.  It would be pretty unfortunate if the spec
> precluded this.

Indeed. It would kill decode-on-draw.

So, what do we want to do here? Fire 'load' for corrupt images, or fire both 'load' and 'error' for those images?

bz suggests that we should just fire onload once we have dimension metadata, and not ever fire onerror for corrupted image data. I'll move the spec to that.

(In reply to comment #10)
> bz suggests that we should just fire onload once we have dimension metadata,

Presumably you mean "as long as you have dimension metadata", but once the image is fully loaded (corrupt or not)?

dbaron: As soon as all the bytes are retrieved and enough of the image has been decoded that you have image data, but not later (in particular, not requiring the pixel data itself to be decoded at all).

I guess drawImage() needs to block waiting for the image to be decoded, right?

(In reply to comment #13)
> I guess drawImage() needs to block waiting for the image to be decoded, right?

If you defer image decoding (an optimization that this spec change allows, but does not require), then yes. Mozilla has a "SyncDecode()" function on images that we use for drawImage and a few other miscellaneous cases.

This doesn't change drawImage() behaviour. It's needed to be able to do sync decode for a while.

Original bug is now fixed.

Checked in as WHATWG revision r7349.
Check-in comment: Make onerror on <img> only fire when onload doesn't fire.
http://html5.org/tools/web-apps-tracker?from=7348&to=7349