26057 2014-06-11 11:36:23 +0000 <img> Fire error when image sniffs as an image but is broken 2015-09-16 12:44:21 +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 zcorpan bzbarsky ian johns mike zcorpan oldest_to_newest 107647 0 contributor 2014-06-11 11:36:23 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/edits.html Multipage: http://www.whatwg.org/C#img-load Complete: http://www.whatwg.org/c#img-load Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: <img> Fire error when image sniffs as an image but is broken [[ If the resource type and data corresponds to a supported image format, as described below ... If the download was successful and the user agent was able to determine the image's width and height ... Otherwise Set the img element to the broken state. If the resource is CORS-same-origin: fire a progress event named load at the img element. ... ]] Why does this fire 'load' rather than 'error'? Firefox 26 fires 'error' for this case AFAICT: http://w3c-test.org/submissions/996/html/semantics/embedded-content/the-img-el ement/update-the-image-data/set-src-idl-same-value-broken-not-cacheable.html Posted from: 2a00:801:e0:30:adfb:99b1:b970:b7ae by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36 OPR/22.0.1471.40 (Edition Next) 107678 1 ian 2014-06-11 19:37:55 +0000 What do other browsers do? 107692 2 zcorpan 2014-06-12 06:17:57 +0000 http://w3c-test.org/submissions/996/html/semantics/embedded-content/the-img-element/update-the-image-data/set-src-idl-same-value-broken-fail-sniffing-not-cacheable.html error event: IE9, IE10, Chrome 14 .. 27, Chrome canary, Safari 7, Firefox 7 .. nightly, load event: IE11, Chrome 28 .. 31 http://w3c-test.org/submissions/996/html/semantics/embedded-content/the-img-element/update-the-image-data/set-src-idl-same-value-broken-not-cacheable.html error event: IE9, IE10, Safari 7, Chrome 14 .. 27, Firefox 7 .. 26 load event: IE11, Chrome 28 .. canary, Firefox 27 .. nightly It seems to me that the traditional browser behavior is to fire error event for both cases. Then some browsers started to fire load instead for one or both cases, maybe because the spec was changed? 107693 3 zcorpan 2014-06-12 06:24:31 +0000 The spec's source has a comment right before this part of the spec: <!-- http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1222 --> This demo seems like it sets .src every 2 seconds and the image takes about 1s to load. The image isn't broken (at least it seems to load fine for me), so I'm not sure how it's relevant. If you tried setting .src before the first image had completed loading and assumed that it would abort the current load, I can see that it would be confusing since browsers do the parallel loading thing. 107736 4 ian 2014-06-12 16:47:16 +0000 I dunno. I guess do whatever most browsers do, unless it's crazy, in which case do whatever the sane browsers do, if there's a sane alternative that some browsers do. 107845 5 zcorpan 2014-06-16 10:47:11 +0000 Fire error event instead of load event when image sniffs as an image but is broken. https://github.com/ResponsiveImagesCG/picture-element/commit/22efd4478d7714ac12fd128ca2c455d0f91f42a4 107870 6 bzbarsky 2014-06-16 20:24:49 +0000 > http://w3c-test.org/submissions/996/html/semantics/embedded-content/the-img-element/update-the-image-data/set-src-idl-same-value-broken-not-cacheable.html What is this test actually testing? I get a load event on the initial load, and internally I'm getting a "size available" notification, which means the image was non-broken enough for the image decoder to have found the size metadata. Generally Gecko fires a load event for images which get that far, not an error event, so we show partially decoded images even if we ended up with an error partway through the decode.... 107920 7 zcorpan 2014-06-17 07:05:52 +0000 (In reply to Boris Zbarsky from comment #6) > > http://w3c-test.org/submissions/996/html/semantics/embedded-content/the-img-element/update-the-image-data/set-src-idl-same-value-broken-not-cacheable.html > > What is this test actually testing? I get a load event on the initial load, > and internally I'm getting a "size available" notification, which means the > image was non-broken enough for the image decoder to have found the size > metadata. Generally Gecko fires a load event for images which get that far, > not an error event, so we show partially decoded images even if we ended up > with an error partway through the decode.... The request-response for the image in this test is as follows, running in Firefox 26: GET /html/semantics/embedded-content/the-img-element/update-the-image-data/resources/stash-count-requests.py?id=18780ba7-f2ee-418c-b500-25fdec34bd81&cached=no&animated=no&delay=no&broken=yes&action=put HTTP/1.1 Host: web-platform.test:8000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Firefox/26.0 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://web-platform.test:8000/html/semantics/embedded-content/the-img-element/update-the-image-data/set-src-idl-same-value-broken-not-cacheable.html Connection: keep-alive HTTP/1.1 200 OK Content-Type: image/gif Cache-Control: no-store, no-cache, must-revalidate Expires: Tue, 19 Nov 1985 21:00:00 GMT Content-Length: 17 Server: BaseHTTP/0.3 Python/2.7.5 Date: Tue, 17 Jun 2014 06:57:38 GMT GIF89aBROKENIMAGE (The response is not delayed.) In http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3063 I use the same image as a data: URL, which fires an error event in Firefox Nightly, but I get a load event in the above test in Firefox Nightly. I don't know why that is. (The "fail-sniffing" test has NOTGIFBROKENIMAGE as response body.)