I was behind on m.d.platform, I'm afraid. tl;dr: This is Long, but in the end I support removal of createObjectURL(MediaStream) in 62.
For anyone who wants to see why, read below. It does make some important points to think about when considering removal, especially about how to gauge usage. >On 4/23/18 3:50 AM, Andrea Marchesini wrote: >> I introduced a deprecated message in bug 1334564, the 7th, February 2017. > >When we have this data, it's worth mentioning what telemetry shows for such >a deprecation message. > >I just checked and out of about 5.8 billion pageloads on Beta 60, about >160,000 used this method [1]. For Beta 59 those numbers are 7.6 billion >and 700,000 respectively [2]. > >So about .01% of pageloads are using this feature on beta 59; about .003% >on beta 60. So: I Really Really want to see createObjectURL(MediaStream) go away - I fought for srcObject, we got it into the spec, and I fought attempts to ignore it by Google. And I fought attempts to reinstate it. That said... >That does seem low enough that removal might be reasonable, as long as >there isn't some site like Hangouts which uses it, and is not usable in >Firefox yet but we would like to be usable... I think first-tier sites like Hangouts, appear.in, WebEx, talky.io, etc will be fine and likely are using srcObject already (or will quickly switch). Second-tier sites I suspect will have a fair number get hit by it, but likely they'll mostly correct it quickly. Some may well do the "use Chrome" bit. Some do that already (Slack, I'm looking at you!!) Small sites, demos, unusual uses, examples all over the web: they'll mostly stay broken. Of course no matter when we change a lot of them will break - almost by definition they're not being updated. (Some blog posts/demos might get updated or people will comment "change to srcObject".) So, I'm torn. I want to see it gone, and usage will never be 0. However... With lots of (not all) web features, disabling it doesn't kill the entire page/application. Perhaps something doesn't look right, or some subset of the page doesn't work. With WebRTC (and friends like WebAudio), if the connection the media elements fails, then the entire application is likely fubar. And until not that long ago, Chrome didn't even support srcObject, let alone promote it in all their demos, examples, etc. They added support for it in Chrome 52, less than 2 years ago. They did an IntentToDeprecate in January, with plans to deprecate in 65 or 66 and remove in 68 - 70 was suggested (because they're worried too many sites still rely on it). 66 only just shipped a few weeks ago. Their demo sites as of January still mostly used srcObject (they did a PR for HTML5 Rocks after deciding to deprecate). Deprecation in blink discussion: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/tWzutytXsqc Safari supported srcObject by late 2017 in Safari 11 (perhaps also in 10), and as of early this year had already removed createObjectURL(MediaStream). We announced deprecation almost 6 months before Chrome even supported srcObject, so when we announced deprecation isn't really the driving factor here. When comparing Chrome's usage for createObjectURL(MediaStream) and srcObject, it's clear that while srObject is getting used more in the last ~3 months (since the decision to deprecate??), and is used more than createObjectURL, usage of createObjectURL isn't decreasing - if anything it's slightly trending up. And ~1/4 of all uses are createObjectURL. https://www.chromestatus.com/metrics/feature/timeline/popularity/1606 https://www.chromestatus.com/metrics/feature/timeline/popularity/1603 This goes back to Boris's discussion of the usage in telemetry - unfortunately, that doesn't tell us how much the alternative/replacement for the deprecated feature is used. (For future telemetry on feature-disabling, this would be a good idea when it's feasible.) And of course we only have beta stats, not release (which chrome has). BTW, this is the 'real' bug in Chrome for removing it: https://bugs.chromium.org/p/chromium/issues/detail?id=800767&desc=2 The patch to the Deprecation file tells devs it'll be gone in 68. At 1.5-2 months per Chrome release, that means that in about 2.5 months it will be removed from Chrome, if they don't delay removal. They might. So, in the end, I absolutely support removing it, since if we remove in 62, it will get to release in about Sep 9th, which is likely *after* Chrome actually removes it (likely around late July or August). If Chrome delays to 70 as someone in the thread suggested (and I see as possible), that would be perhaps October-ish. Kill it with fire. :-) >-Boris > >[1] >https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-04-18&keys=__none__!__none__!__none__&max_channel_version=beta%252F60&measure=USE_COUNTER2_DEPRECATED_URLCreateObjectURL_MediaStream_PAGE&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2018-03-04&table=0&trim=1&use_submission_date=0 > >[2] >https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-03-01&keys=__none__!__none__!__none__&max_channel_version=beta%252F59&measure=USE_COUNTER2_DEPRECATED_URLCreateObjectURL_MediaStream_PAGE&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-11-13&table=0&trim=1&use_submission_date=0 -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
