Re: [whatwg] img loading events - can load & error fire for the same image?

On 12 July 2013 20:12, Ian Hickson <ian@hixie.ch> wrote:
> On Fri, 5 Apr 2013, Jake Archibald wrote:
>>
>> Been reading the steps for image downloading -
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data
>> ...
>> Unless I'm reading it wrong, that suggests
>> http://jsbin.com/ifihex/1/edit should fire a "load" then an "error",
>> which doesn't feel right.
>>
>> I don't think the "Otherwise" step should fire "load", just "loadend".
>
> This has either been fixed already, or I don't understand the problem. Can
> you look at the spec again and see if it's ok now?

It still looks wrong to me.

Take http://jsbin.com/ifihex/1/edit - the image on this page receives
a valid & full HTTP request, but the received data isn't valid image
data (it's html).

Starting from http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data,
here's how I see the image loading according to the spec

(everything seems fine until step 14)

Step 1: img set to unavailable state
Step 2: not applicable, no current fetch happening
Step 3: not applicable, no current image data
Step 4: not applicable, images are enabled & supported
Step 5: selected source becomes "/"
Step 6: last selected source becomes "/"
Step 7: selected source becomes "http://jsbin.com/"
Step 8: key set to tuple
Step 9: not applicable, key not in list of available images, it's the
only image on the page
Step 10: await stable state
Step 11: not applicable, no further images are added
Step 12: not applicable, selected source is "http://jsbin.com/" not null
Step 13: fire loadstart on img
Step 14:
* delay document load event until image fetch completes
* fetching image
* set image to partially available
* I don't know if progress events are fired here or not, given the
invalid image data
* image fetched
* this is the point where I start to get lost, I'm not sure which
else-like statements (as in "On the other hand" and "Otherwise") are
linked to which if-like statements
* unable to determine image's width or height due to invalid data, so
we fall to the "Otherwise" section (the one with the \21AA before it)
* set img to broken state
* fire load
* fire loadend
* resource isn't multipart/x-mixed-replace, so skipping that bit
* "Otherwise, either the image data is corrupted in some fatal way"
what's this an "otherwise" to, should these steps be followed? If so…
* image dimensions cannot be determined, so set img element to the
broken state (it already is)
* fire error
* fire loadend (for a second time)

So the order of events is load, loadend, error, loadend. I guess I'm
reading it wrong but unsure where.

>> "load" is fired once the width & height can be determined, which
>> suggests that an un-decodable image, but with intact headers (which give
>> the width & height) will fire "load" but not "error".
>> I agree with this, as it means the browser can defer decoding to render
>> time, but do we need a way in JS to confirm an image is decodable?
>
> What's the use case? (Surely the server should check this on the server.)

Hah, yeah, that bit was a bit of an afterthought, maybe best for another thread.

The use-case would be image loading that happened without a server.
Eg, an in-browser Photoshop that operated without user interaction.
User selects file on their machine, it has correct headers so fires a
load event, but cannot be painted onto the canvas (or paints
incorrectly) due to corrupt data. The in-browser app is unable to
detect the image is corrupt without building a decoder/validator in
JS.

Jake.

Received on Monday, 22 July 2013 14:38:08 UTC