<img>.decode() interop issue

[annevk]

The current specification always looks at the current request, but that isn't updated upon src attribute assignment. Instead it needs to look at the pending request (at least some of the time).

cc @vmpstr @zcorpan @domenic

[vmpstr]

To clarify, do you mean step 16 of https://html.spec.whatwg.org/multipage/images.html#updating-the-image-data is where we actually use a pending request if the current request is (for example) completely available?

I agree that we should be looking at the pending request in that case. I think one problem is that I think it's a bit awkward to say "wait until the pending request is completely available, then do decoding stuff" because once the pending request becomes completely available then it replaces the current request (via https://html.spec.whatwg.org/multipage/images.html#updating-the-image-data:upgrade-the-pending-request-to-the-current-request-4 I think). So we'd have to wait for the pending request to be upgraded to the current request, which I think always happens regardless of whether it becomes available or broken, and then proceed with the decoding steps.

[annevk]

The infrastructure around the img element could indeed use improvement, though I haven't looked into it deeply recently.

But yeah, the problem is that currently https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-decode only looks at the current request which might well be completely available (with the previous image) as the pending request only ends up replacing it once fetching is done. (And this means that the example at the top of step 2 does not return results for stars.jpg in a conforming browser.)