1501554 - <img> should fire ProgressEvent for CORS-same-origin images

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect, P3)

Description

[esterTion]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:51.0) Gecko/20160105164030 Firefox/62.0

Steps to reproduce:

<img src="example.png">
<script>
img = document.querySelector('img');
img.addEventListener('progress', function (event) {
  console.log(event);
});
</script>


Actual results:

No event is triggered / logged


Expected results:

According to HTML spec[1], ProgressEvent should be fired for CORS-same-origin[2] images. 
I'm not sure if it is because this spec is new or something, none vendor has implemented the ProgressEvent on <img> element. 
Though loadstart / loadend works on Firefox 62, and only loadend works on Chrome 69

[1]: https://html.spec.whatwg.org/#event-progress
[2]: https://html.spec.whatwg.org/#cors-same-origin

Comment 1

[esterTion]

Also, MDN lists <img> under ProgressEvent, which is kind of misleading for now. 

https://developer.mozilla.org/en-US/docs/Web/API/ProgressEvent

Comment 2

[Andrew Overholt [:overholt]]

Christoph, do you know about this?

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

(In reply to esterTion from comment #0)
> According to HTML spec[1], ProgressEvent should be fired for
> CORS-same-origin[2] images. 
> I'm not sure if it is because this spec is new or something, none vendor has
> implemented the ProgressEvent on <img> element. 
> Though loadstart / loadend works on Firefox 62, and only loadend works on
> Chrome 69

I haven't investigated, but presumably this is not CORS related, but potentially (as the author indicates) Firefox does not support the progressEvent at all as of now. I don't know who might know the answer for sure, probably someone in the DOM team is better suited to answer. I'll ask Anne for now since he might be able to help out.

Comment 4

[Anne (:annevk)]

Yeah, pretty sure that's correct (progress events would only be supported for CORS images, but that information is already available in DOM as it's also needed for canvas and such). There's also https://github.com/whatwg/html/issues/1915 about this text not being as specific as it needs to be.

Comment 5

[Boris Zbarsky [:bzbarsky]]

This seems like a case of the HTML spec making up something without talking to any browsers, then not telling them about it.  Such things were done back in the day.

It's not clear to me whether this is desirable to implement, or even what it would mean given async decoding.

Comment 6

[Anne (:annevk)]

We have some of this, but I think we should remove it as per bug 1574487.