This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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)
What do other browsers do?
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?
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.
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.
Fire error event instead of load event when image sniffs as an image but is broken. https://github.com/ResponsiveImagesCG/picture-element/commit/22efd4478d7714ac12fd128ca2c455d0f91f42a4
> 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....
(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.)