This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28096 - <img> Fire the loadend event (and possible progress events) for multipart/x-mixed-replace image streams
Summary: <img> Fire the loadend event (and possible progress events) for multipart/x-m...
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other All
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: https://html.spec.whatwg.org/#the-img...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-24 22:24 UTC by contributor
Modified: 2019-03-29 21:35 UTC (History)
6 users (show)

See Also:
zcorpan: needinfo? (seth)


Attachments

Description contributor 2015-02-24 22:24:58 UTC
Specification: https://html.spec.whatwg.org/
Multipage: https://html.spec.whatwg.org/multipage/#the-img-element
Complete: https://html.spec.whatwg.org/#the-img-element
Referrer: http://r.search.yahoo.com/_ylt=A86.JyIq9exUHycAxjIlnIlQ;_ylu=X3oDMTEzdmt0MDRqBHNlYwNzcgRwb3MDNQRjb2xvA2dxMQR2dGlkA1lIUzAwMl8x/RV=2/RE=1424844203/RO=10/RU=https%3a%2f%2fhtml.spec.whatwg.org%2f/RK=0/RS=eJLcnDIrowPZ8lHfKOrZRssdJwQ-

Comment:
Why should we not fire the progress and loadend events for
multipart/x-mixed-replace image streams?

That would actually be extremely useful, particularly loadend. Since the spec
requires that we fire the load event as soon as the first part is available,
there is actually no way I'm aware of to detect the end of a finite
multipart/x-mixed-replace image stream. Firing 'loadend' would provide this
capability.

If there's no good argument against this change, I suggest that we strike that
note from the spec.

Posted from: 63.245.219.54
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0
Comment 1 Seth Fowler 2015-02-24 22:30:33 UTC
BTW, if the objection is mostly against the progress event (since firing it would after all result in an endless stream of events in some cases), I suppose we could live without it. But I am really keen on firing loadend, even for multipart streams.
Comment 2 Simon Pieters 2015-02-26 10:40:19 UTC
I think the reason is mostly to keep things as simple as possible for legacy features. Your proposal would also be inconsistent with how progress events usually work (fire progress while loading and load/loadend together at the end).

What is the use case? Is it not better to use a <video>?
Comment 3 Seth Fowler 2015-03-10 23:27:47 UTC
(Sorry for the slow response; had some fires to put out recently.)

(In reply to Simon Pieters from comment #2)
> I think the reason is mostly to keep things as simple as possible for legacy
> features.

In Gecko, at least, I don't think there's any significant implementation complexity involved in my proposal. Things may be different in other browser engines.

From the point of view of content authors, I think my proposal is actually of *lower* complexity, as it means that:

(1) We always fire loadend for images.
(2) We always fire loadend *when the content finishes loading from the network*.

The interaction between multipart/x-mixed-replace and the load event is not intuitive, in my opinion, and I think we have an opportunity here to do better with loadend.

> Your proposal would also be inconsistent with how progress events
> usually work (fire progress while loading and load/loadend together at the
> end).

What I'm proposing *is* to fire loadend at the end. In the existing model, load is fired after the first part is available in the multipart case, not at the end. Whether that was a good idea is debatable, but we can't change that now. However, we can take this opportunity (before web compatibility makes change impossible) to make progress events map more cleanly to the underlying network transfer.

> What is the use case? Is it not better to use a <video>?

It's absolutely a million times better to use a <video>. However, if we are going to standardize multipart/x-mixed-replace for images at all, we should give content authors the tools to work with them effectively. And people do continue to use multipart images, especially for webcams.

Right now we have no event that content authors can use to tell when a multipart/x-mixed-replace image finishes loading. That's a completely reasonable thing to support, and I think we should use this opportunity to support it.

To give a concrete example of at least one use case, we run into this issue all the time when writing reftests involving multipart images for Gecko. New contributors think that they can write reftests that wait for a multipart image to completely load using the load event. This results in tests that intermittently fail, since that doesn't actually work - it only waits for the first part.

To write such tests correctly, we have to write them using Gecko-specific internal features - there's no way to correctly write such a test using the features exposed by the web platform. I'd like to change that; by firing loadend when the multipart image actually finishes loading, we can convert these tests to simpler reftests, which could potentially be shared with other browsers.
Comment 4 Simon Pieters 2015-03-11 11:00:10 UTC
(In reply to Seth Fowler from comment #3)
> In Gecko, at least, I don't think there's any significant implementation
> complexity involved in my proposal.

OK.

> Things may be different in other browser
> engines.
> 
> From the point of view of content authors, I think my proposal is actually
> of *lower* complexity, as it means that:
> 
> (1) We always fire loadend for images.
> (2) We always fire loadend *when the content finishes loading from the
> network*.
> 
> The interaction between multipart/x-mixed-replace and the load event is not
> intuitive, in my opinion, and I think we have an opportunity here to do
> better with loadend.
> 
> > Your proposal would also be inconsistent with how progress events
> > usually work (fire progress while loading and load/loadend together at the
> > end).
> 
> What I'm proposing *is* to fire loadend at the end.

My point is that the sequence of events would be

loadstart, progress, progress, load, progress, progress, loadend

whereas the usual sequence of events is

loadstart, progress, progress, progress, progress, load, loadend

> In the existing model,
> load is fired after the first part is available in the multipart case, not
> at the end. Whether that was a good idea is debatable, but we can't change
> that now. However, we can take this opportunity (before web compatibility
> makes change impossible) to make progress events map more cleanly to the
> underlying network transfer.

Sure.

> It's absolutely a million times better to use a <video>. However, if we are
> going to standardize multipart/x-mixed-replace for images at all, we should
> give content authors the tools to work with them effectively. And people do
> continue to use multipart images, especially for webcams.
> 
> Right now we have no event that content authors can use to tell when a
> multipart/x-mixed-replace image finishes loading. That's a completely
> reasonable thing to support, and I think we should use this opportunity to
> support it.
> 
> To give a concrete example of at least one use case, we run into this issue
> all the time when writing reftests involving multipart images for Gecko. New
> contributors think that they can write reftests that wait for a multipart
> image to completely load using the load event. This results in tests that
> intermittently fail, since that doesn't actually work - it only waits for
> the first part.
> 
> To write such tests correctly, we have to write them using Gecko-specific
> internal features - there's no way to correctly write such a test using the
> features exposed by the web platform. I'd like to change that; by firing
> loadend when the multipart image actually finishes loading, we can convert
> these tests to simpler reftests, which could potentially be shared with
> other browsers.

Thanks.

I'm not opposed to specifying this. Although it would be nice with a concrete non-test use case also.
Comment 5 Seth Fowler 2015-03-13 01:18:38 UTC
(In reply to Simon Pieters from comment #4)
> My point is that the sequence of events would be
> 
> loadstart, progress, progress, load, progress, progress, loadend

Yeah, I got that - sorry it didn't come across. My intention was to contrast the proposed behavior for loadend with the way the load event works now.

> I'm not opposed to specifying this. Although it would be nice with a
> concrete non-test use case also.

Heh, I agree that it'd be nice to have a non-test use case. Unfortunately since I spend my time hacking on Gecko, it's easiest for me to give an example that draws on that experience. It's often the case that something that makes life difficult for us when writing tests also bites content authors, though.
Comment 6 Seth Fowler 2015-03-17 21:55:40 UTC
OK, so I'm going to try to move forward on this by seeing if another browser engine is willing to implement this as well.

To summarize exactly what I'm proposing here, I think we should:

- Send the loadend event when the underlying network stream completes for multipart/x-mixed-replace images. This is different than the load event, which we send after the first part is complete. By making this change, we make it possible to detect when a finite-length multipart/x-mixed-replace image stream is complete, which is currently not possible with the web platform.

- Send progress events for multipart/x-mixed-replace images if others think they would be useful or prefer to send them for consistency. I have no objection to sending them, but I don't have a use case for these.

We're prepared to implement this in Gecko as soon as we receive confirmation that at least one other browser engine is open to implementing this.

I've reached out to the Blink folks.
Comment 7 Seth Fowler 2015-03-17 22:18:11 UTC
One possibly useful function for the progress event that just occurred to me would be to fire it after each part finishes loading. I can imagine that being useful. Probably firing it just because a chunk of bytes has been received from the network is less useful in the multipart/x-mixed-replace case.
Comment 8 Simon Pieters 2016-01-13 10:24:52 UTC
Seth, any interest from other vendors yet?

I stumbled on this comment https://code.google.com/p/chromium/issues/detail?id=7731#c29 which indicates the lack of events is annoying for people using multipart/x-mixed-replace.
Comment 9 Domenic Denicola 2019-03-29 21:35:58 UTC
With W3C Bugzilla closing, we're marking all feature requests as WONTFIX, or at least wontfix-in-this-bugtracker.

Please feel free to reopen on https://github.com/whatwg/html/issues if you still believe in the feature and want to discuss it further.