Intent to Ship: MediaStream constructor

62 views
Skip to first unread message

Philip Jägenstedt

unread,
Sep 23, 2016, 9:35:50 AM9/23/16
to blink-dev

Contact emails

foo...@chromium.org


Spec

https://w3c.github.io/mediacapture-main/#mediastream


Summary

Expose the MediaStream interface, which currently has [NoInterfaceObject] and a webkitMediaStream alias. Remove [NoInterfaceObject].


Link to “Intent to Implement” blink-dev discussion

None, webkitMediaStream was added to WebKit in 2012:

https://trac.webkit.org/changeset/111558


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Interoperability and Compatibility Risk

Edge and Firefox have the unprefixed constructor, and no prefixed variants. This was identified in Web features in 2 major browser, but not Chrome.


Given the state of Edge and Firefox, compat risk should be low, but it is always possible that having both prefixed and unprefixed would break when just having one of them would not.

It is not part of this intent to do anything with webkitMediaStream. It doesn't have a use counter, and a use counter would be ruined by code like new (window.webkitMediaStream || window.MediaStream)(). It needs tedious httparchive research, which I haven't done.

OWP launch tracking bug

https://crbug.com/649331


Entry on the feature dashboard

https://www.chromestatus.com/features/5912172546752512

Jochen Eisinger

unread,
Sep 23, 2016, 9:42:25 AM9/23/16
to Philip Jägenstedt, blink-dev
lgtm1

You'd hope that sites write window.MediaStream || window.webkitMediaStream, no?

Philip Jägenstedt

unread,
Sep 23, 2016, 10:25:20 AM9/23/16
to Jochen Eisinger, blink-dev
One would hope, but I'm pessimistic about use counters here and would have to look at httparchive anyway, to find usage that would actually break.

Even the useless window.offscreenBuffering which has [NotEnumerable], shows very high usage, which I don't think is real usage:

Chris Harrelson

unread,
Sep 23, 2016, 11:00:48 AM9/23/16
to Philip Jägenstedt, Jochen Eisinger, blink-dev
LGTM2

--
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+unsubscribe@chromium.org.

TAMURA, Kent

unread,
Sep 27, 2016, 3:02:27 AM9/27/16
to Chris Harrelson, Philip Jägenstedt, Jochen Eisinger, blink-dev
LGTM3

--
TAMURA Kent
Software Engineer, Google


Philip Jägenstedt

unread,
Dec 17, 2016, 4:06:38 PM12/17/16
to TAMURA, Kent, Chris Harrelson, Jochen Eisinger, blink-dev
This change broke some code assuming that unprefixed MediaStream implies Firefox:

As described in the bug, some httparchive searching revealed that the same pattern appears elsewhere. Given that Edge already has MediaStream I'm inclined to think that outreach is better than reverting, but we will see.

In the compat risk I alluded to how things went wrong for Edge when they tried to ship the unprefixed Fullscreen API, and this here is another way that sites can break when unprefixing APIs that have long been prefixed-only.

I think we still should attempt changes like this, however. For any prefixed API, there could be analogous code out there assuming that the presence of webkitMediaStream implies Chrome/Safari, which could break things for other engines if they wanted to implement the prefixed variants for compat+interop.

LGTM3


LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.




Harald Alvestrand

unread,
Dec 19, 2016, 2:42:12 AM12/19/16
to Philip Jägenstedt, TAMURA, Kent, Chris Harrelson, Jochen Eisinger, blink-dev
I don't think this risk can be avoided. And it will become worse over time, not better, if we delay unprefixing, since more people will make the wrong assumption.

As noted, these sites are already broken on Edge, and there's no way to get to an unprefixed state without breaking them.

LGTM3


LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.




--
TAMURA Kent
Software Engineer, Google


--
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+unsubscribe@chromium.org.

PhistucK

unread,
Dec 19, 2016, 3:17:09 AM12/19/16
to Harald Alvestrand, Philip Jägenstedt, TAMURA, Kent, Chris Harrelson, Jochen Eisinger, blink-dev
WebRTC generally has a good connection with WebRTC application developers - can you post some public service announcement in discuss-webrtc in order to make somehow sure more people are aware of this change and its implications?


PhistucK

Philip Jägenstedt

unread,
Jan 4, 2017, 9:53:21 AM1/4/17
to PhistucK, Harald Alvestrand, TAMURA, Kent, Chris Harrelson, Jochen Eisinger, blink-dev
Over a month has passed since the unprefixed MediaStream constructor reached stable with M55, so I've closed https://crbug.com/674608 as WontFix.

I'm afraid there isn't much of a lesson to learn for the future here either. The problematic code implicitly used the existence of MediaStream to detect Firefox, and digging in httparchive digging in advance probably wouldn't have found this, because there's no particular string or combination of strings to search for.

The number of prefixed-only APIs is (happily) decreasing, so hopefully we will run out of problems of this particular sort eventually.

LGTM3


LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.




--
TAMURA Kent
Software Engineer, Google


--
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.

--
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.

Reply all
Reply to author
Forward
0 new messages