Intent to Deprecate: MediaStream ended event and onended attribute

[Guido Urdaneta]

Primary eng (and PM) emails

Eng: gui...@chromium.org, h...@chromium.org,

PM: bl...@chromium.org

Summary

Deprecate MediaStream ended event

Motivation

The MediaStream ended event and attribute, and onended attribute are not part of the WebRTC spec since 2013. The ended attribute has been replaced with the active attribute and the ended event has been replaced with the active and inactive events. Blink no longer supports the ended attribute, but it still provides some support for the ended event and the corresponding onended attribute.

The support for the ended event in Blink is limited to firing the event the first time all the tracks associated with a MediaStream end. Note that this event does not actually mean that the MediaStream has “ended”, as this concept no longer exists. It is possible for a MediaStream whose tracks have ended (and has thus become inactive) to become active again if a new active MediaStreamTrack is added to the MediaStream. If the MediaStream becomes inactive again, no ended event is fired.

Our plan is to deprecate the ended event in M52 and remove it in M53.

Compatibility Risk

With regards to existing Web sites, the future removal of the MediaStream ended event and onended attribute represents a moderate compatibility risk, as the feature has been supported for several years.

However, the feature is not used much. The onended attribute is used by 0.0007% of pages in the stable channel (M50) according to our use counters. This does not include, however, uses of the ended event using the addEventListener method.

With regards to interoperability with other browser engines, this change will make Blink more compatible with Edge, WebKit and Firefox. Edge[1] and WebKit[2,3] do not support the ended event or attribute. Mozilla’s MDN documentation[4] lists the MediaStream ended attribute and event as deprecated features, and the WebIDL Firefox source code[5] suggests that the ended event or attribute are not supported.

[1] https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/apireference/interfaces/mediastream/

[2] https://trac.webkit.org/browser/trunk/Source/WebCore/Modules/mediastream/MediaStream.idl

[3] https://trac.webkit.org/browser/trunk/Source/WebCore/Modules/mediastream/MediaStream.cpp

[4] https://developer.mozilla.org/en/docs/Web/API/MediaStream

[5] http://mxr.mozilla.org/mozilla-central/source/dom/webidl/MediaStream.webidl

Alternative implementation suggestion for web developers

The functionality previously provided by the ended event and onended attribute is now provided by the inactive event and the oninactive attribute, which are fully supported by Blink.

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/526

OWP launch tracking bug

https://crbug.com/608795

Entry on the feature dashboard

https://www.chromestatus.com/feature/5730404371791872

Requesting approval to remove too?

No

[Chris Harrelson]

LGTM1 to deprecate in M52 and remove in M53 (even though you weren't requesting approval

to remove).

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dimitri Glazkov]

LGTM2

[Rick Byers]

As part of deprecation, I assume we'll get UseCounter coverage for the addEventListener case, right?

LGTM3 to remove in M53, assuming there are no big surprises from the above UseCounter.  The fact that none of the other engines have this indicates the risk should be very low.

[Guido Urdaneta]

Since we started to count usage with addEventListener, the UseCounter jumped to 0.0022% (0.0027% on Windows). 

Is this low enough for removing, or should we extend the deprecation period?

[Rick Byers]

Ugh, that's tougher to evaluate.  It probably depends how we expect those sites to break in practice.  If ~0.002% of page views were to start failing pretty catastrophically that would be terrible (even extending the deprecation period might not be enough, we might have to add the old API back to the spec indicating that the web really requires it).   But perhaps the breakage is actually much more subtle, or limited to one or two popular libraries/sites which can be updated?

Are you aware of any sites/apps using this?  Can you check a couple popular WebRTC apps/libraries to see if you can find examples?  Eg. if Google Hangouts is using it, then maybe getting that fixed would drop the count dramatically?  If after a little manual searching you don't find any popular sites that hit your use counter, I could try doing a run on the telemetry cluster to search the top 10k sites (though not sure how likely it is people are adding such a listener on page load of their main page).

Rick

[Guido Urdaneta]

Hangouts is using this event. 

An internal bug has been filed to migrate to the inactive event.

[Rick Byers]

Thanks!  Hopefully they will remove usage soon.  If not, we can discuss options.  In other cases we've said we won't let a single property (especially a Google property) hold us back from standards conformance (the real problem with web compat is the long tail, but that's harder to measure when there's one popular site using the API).

Rick

[Joe Medley]

The active/inactive events were removed form the spec in December. See the Change Log under 'Changes since December 8, 2015'.) They don't seem to have been replaced with anything, at least as far as this spec is concerned. 

Does anyone know if some other spec addresses this?

[Rick Byers]

Great catch Joe, thanks!  Here's the discussion/commit, +adam-be who drove that.

The advice is that script doesn't need these events because it's script that changes the state of the stream itself. Guido, do you feel that's practical advice based on typical usage?  Eg. I could imagine composition scenarios (one library controlling playback, another responding to it somehow) where this would be awkward.  Should we add a UseCounter to measure usage of them?

For now I think our guidance should encourage developers to not rely on events as the WG agreed, but point out that if necessary there are active/inactive events still supported by some browsers (which?).  If developers are already depending on them, or if there are legitimate scenarios that can't be solved without them, then I assume the WG will just want to add them back to the spec and work through the details of how to define them precisely.

Rick

[Guido Urdaneta]

+hta@

I think we should proceed with our plan to remove the ended event, and start tracking usage of the active/inactive events.

I agree with the idea of encouraging users not to rely on these events. WebKit[1] and Edge[2] support the active/inactive events and Firefox[3] was planning to add support, but I guess they are canceling that plan.

[1]: https://trac.webkit.org/browser/trunk/Source/WebCore/Modules/mediastream/MediaStream.idl

[2]: https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/apireference/interfaces/mediastream/

[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1208316

[Harald Alvestrand]

Discussion was that applications serious about watching for events would watch the tracks not the stream, and people who really want it can easily synthesize them from track events.

[Philip Jägenstedt]

Given that 3/4 browser engines supports the active/inactive events, would the WG consider putting them back in the spec? The complexity of supporting it doesn't seem very high, and there's already an active member on MediaStream, changes to which the events would track.

Guido tells me the fix Hangouts was to use the inactive event, so we can be sure without adding use counters that we'll see usage high enough to warrant caution, but without another change to Hangouts we couldn't tell how much usage is coming from elsewhere.

How fast can the WG revisit this? It would be rather bad if we remove the ended event with the existing deprecation message and then decide to remove the active/inactive events as well.

[Guido Urdaneta]

What do you think about removing the recommendation to migrate to the inactive event from the deprecation message and deferring the removal to M54?

[Harald Alvestrand]

Deferring the removal and changing the deprecation message seems good.

[Philip Jägenstedt]

Did anyone (Harald?) raise this issue with the WG? Removing the active/inactive events seems not so great.

Still, I don't think those issues need to be coupled, changing the deprecation message and delaying the removal SGTM.

[Philip Jägenstedt]

I've filed https://github.com/w3c/mediacapture-main/issues/370

[Philip Jägenstedt]

https://github.com/w3c/mediacapture-main/issues/370 was closed but it's not at all clear to me how this situation will be resolved. Harald, do you know the relevant people working on Edge, and can you inquire about their plans for the events? For now, I've added a use counter for the active attribute, since removing just the events seems a bit silly.

[Harald Alvestrand]

Erik closed as "no consensus to change further" (that is, no consensus to remove the active attribute). The active attribute is clearly defined in terms of the track states, and is rreadonly, so it's not a huge implementation burden.

You see Shijun's comments on the bug - he's the lead on the Edge implementation, so what he says is, by definition, the plan.