15000 2011-11-30 09:15:09 +0000 Don't fire load until the image is fully decodable. If the image is corrupt or unsupported, the spec says to fire load *and* error, but browsers don't do that. 2012-09-15 02:10:04 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#img-load P3 normal Unsorted 1 contributor ian bobbyholley bzbarsky dbaron ian mike zcorpan contributor oldest_to_newest 60656 0 contributor 2011-11-30 09:15:09 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html Multipage: http://www.whatwg.org/C#img-load Complete: http://www.whatwg.org/c#img-load Comment: Don't fire load until the image is fully decodable. If the image is corrupt or unsupported, the spec says to fire load *and* error, but browsers don't do that. Posted from: 85.227.157.105 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/535.8 (KHTML, like Gecko) Chrome/17.0.942.0 Safari/535.8 60660 1 zcorpan 2011-11-30 10:03:01 +0000 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. 63449 2 ian 2012-01-31 21:00:50 +0000 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? 63519 3 zcorpan 2012-02-01 08:01:45 +0000 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1318 The spec requires 'load' but Opera/Firefox/Chrome fire 'error' 70547 4 contributor 2012-07-18 16:05:59 +0000 This bug was cloned to create bug 18039 as part of operation convergence. 71562 5 ian 2012-07-27 02:13:31 +0000 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). 71565 6 bzbarsky 2012-07-27 02:26:11 +0000 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. 71566 7 bzbarsky 2012-07-27 02:28:18 +0000 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. 71593 8 bobbyholley 2012-07-27 07:42:07 +0000 (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. 73018 9 ian 2012-08-29 21:56:32 +0000 So, what do we want to do here? Fire 'load' for corrupt images, or fire both 'load' and 'error' for those images? 73446 10 ian 2012-09-07 20:10:12 +0000 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. 73449 11 dbaron 2012-09-07 21:52:06 +0000 (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)? 73816 12 ian 2012-09-13 23:48:29 +0000 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). 73852 13 zcorpan 2012-09-14 07:50:28 +0000 I guess drawImage() needs to block waiting for the image to be decoded, right? 73875 14 bobbyholley 2012-09-14 10:36:05 +0000 (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. 73949 15 ian 2012-09-15 02:09:59 +0000 This doesn't change drawImage() behaviour. It's needed to be able to do sync decode for a while. Original bug is now fixed. 73950 16 contributor 2012-09-15 02:10:04 +0000 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