Chiming in briefly here - it appears (from my console messages) that BrowserStack is currently hitting this deprecation. BrowserStack sessions in M115 restart on ~5 second intervals with a console error pointing to this deprecation. Might be worth reaching out to them to talk about mitigations.
On Friday, February 24, 2023 at 2:28:21 PM UTC-8 Mike Taylor wrote: > LGTM3 > On 2/24/23 12:31 PM, Philip Jägenstedt wrote: > > LGTM2, even better! > > On Fri, Feb 24, 2023 at 5:04 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> SGTM! >> >> On Fri, Feb 24, 2023 at 4:40 PM Henrik Boström <h...@google.com> wrote: >> >>> Yes, I think throwing in M117, stable on Aug 30 would be even better. >>> >>> On Friday, February 24, 2023 at 4:32:21 PM UTC+1 Philip Jägenstedt wrote: >>> >>>> I think the overall timeline looks great, the final removal is almost a >>>> year from now, after the 2023 holiday season. >>>> >>>> However, I'd like to bikeshed "Throw an exception if the trial is not >>>> used in Stable in M119 (Release: October 31, 2023)". This is when the >>>> breakage will be apparent to most users/developers, anyone who isn't >>>> paying >>>> attention to deprecation warnings. Oct 31 doesn't give a whole lot of time >>>> to figure out how origin trials work and opt into that, so I would suggest >>>> M117, stable on Aug 30. That's as early as seems reasonable given summer >>>> vacations in the northern hemisphere. >>>> >>>> WDYT Henrik, would that work just as well for you? >>>> >>>> On Thu, Feb 23, 2023 at 1:17 PM Yoav Weiss <yoav...@chromium.org> >>>> wrote: >>>> >>>>> LGTM1 for that plan >>>>> >>>>> On Thu, Feb 23, 2023 at 12:48 PM Henrik Boström <hb...@chromium.org> >>>>> wrote: >>>>> >>>>>> In that case the proposal is: >>>>>> - Add deprecation warning in M113 (Release: May 2, 2023) with the >>>>>> possibility to opt-in to the Deprecation Trial. >>>>>> - Throw an exception if the trial is not used in Canary/Dev/Beta in >>>>>> M114. >>>>>> - Throw an exception if the trial is not used in Stable in M119 >>>>>> (Release: October 31, 2023). >>>>>> - Let M121 be the last version where the Trial is available (Release: >>>>>> January 9, 2024). In other words the first version where the trial and >>>>>> legacy getStats API is entirely removed is M122 (Release: February 6, >>>>>> 2024). >>>>>> >>>>>> On Thursday, February 23, 2023 at 11:38:48 AM UTC+1 Yoav Weiss wrote: >>>>>> >>>>>>> SGTM >>>>>>> >>>>>>> On Thu, Feb 23, 2023 at 11:34 AM Henrik Boström <hb...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thursday, February 23, 2023 at 11:03:44 AM UTC+1 Yoav Weiss >>>>>>>> wrote: >>>>>>>> >>>>>>>> On Mon, Feb 20, 2023 at 12:52 PM Henrik Boström <hb...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> OK, so deprecation warning in M113, throwing in Beta in M114 and >>>>>>>> throwing in Stable on M119. We can do that. >>>>>>>> >>>>>>>> >>>>>>>> Awesome! >>>>>>>> >>>>>>>> >>>>>>>> Under this less aggressive timeline, for how many more milestones >>>>>>>> would the Deprecation Trial span? >>>>>>>> >>>>>>>> >>>>>>>> How much would be needed for people to schedule the work to make >>>>>>>> the switch? >>>>>>>> >>>>>>>> >>>>>>>> If they notice the deprecation warning they would have enough time >>>>>>>> to migrate before the Deprecation Trial is even needed. If they don't, >>>>>>>> how >>>>>>>> about 3 months extra? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I do not have any more deprecations planned on my end and I think >>>>>>>> this is "standalone" enough (stats being rather specific) that in my >>>>>>>> opinion it should not be bundled together with anything else. >>>>>>>> >>>>>>>> >>>>>>>> OK, cool! >>>>>>>> >>>>>>>> >>>>>>>> On Friday, February 17, 2023 at 8:52:56 AM UTC+1 Yoav Weiss wrote: >>>>>>>> >>>>>>>> Hey Henrik! >>>>>>>> >>>>>>>> I think the general outline of the plan makes sense, but the >>>>>>>> timelines seem too aggressive. As we've recently seen in the track >>>>>>>> stats >>>>>>>> removal, there can be a time difference between the point a developer >>>>>>>> puts >>>>>>>> in the work to opt-in for a deprecation trial and the point in which >>>>>>>> this >>>>>>>> work reaches users. >>>>>>>> >>>>>>>> I think it would make sense to: >>>>>>>> * Add a deprecation warning in M113 and enable a Deprecation Trial. >>>>>>>> Set a tentative removal milestone for M119. >>>>>>>> * Start throwing an exception up to Beta in M114 to try and get >>>>>>>> people's attention >>>>>>>> * Broadly communicate this change is coming in multiple channels. >>>>>>>> DevRel folks may be able to help there. +Paul Kinlan and +Andre >>>>>>>> Bandarra for thoughts. >>>>>>>> * In parallel to the above, turn the usecounters into UKM >>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=14?q=usecounter%20ukm&ss=chromium>, >>>>>>>> >>>>>>>> and try to see where most usage lies. (and try to understand if it's >>>>>>>> coming >>>>>>>> from libraries with longer deployment lifecycles) >>>>>>>> * Flip the switch (and be ready to revert) in M119 >>>>>>>> >>>>>>>> I know this is a bit longer and more work than the plan you >>>>>>>> outlined, but given the few fire drills we had recently, it seems >>>>>>>> better to >>>>>>>> err on the cautious side. >>>>>>>> >>>>>>>> Also, do you know if more removals are planned on your side? It >>>>>>>> seems like it'd be better to "bundle" them so that library authors >>>>>>>> only >>>>>>>> have to "respin" their deployment once, rather than every few >>>>>>>> milestones. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Feb 16, 2023 at 3:10 PM Henrik Boström <hb...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> *This deprecation is not to be confused with the track stats >>>>>>>> deprecation >>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/NZVXsJQ7tV8>, >>>>>>>> which >>>>>>>> is deprecating a small subset of the modern API. This deprecation >>>>>>>> related >>>>>>>> to the removal of the legacy API, a different API with the same name.* >>>>>>>> >>>>>>>> *Contact emails* >>>>>>>> hb...@chromium.org, h...@chromium.org >>>>>>>> >>>>>>>> *Specification* >>>>>>>> The legacy getStats() API has no spec, no official documentation >>>>>>>> and no web platform tests. >>>>>>>> >>>>>>>> The modern (promise-based) version of getStats() does have a spec, >>>>>>>> but this is a different method returning different stats objects: >>>>>>>> https://w3c.github.io/webrtc-stats/ >>>>>>>> >>>>>>>> There are lots of similarities between the modern and legacy APIs, >>>>>>>> including several metrics that are the same, but the stats report >>>>>>>> structure >>>>>>>> is different and the legacy API contains several "goog"-prefixed >>>>>>>> metrics or >>>>>>>> metrics that behave differently from the modern API. >>>>>>>> >>>>>>>> In 2019, a document was created outlining the differences between >>>>>>>> the legacy and modern API >>>>>>>> <https://docs.google.com/document/d/1z-D4SngG36WPiMuRvWeTMN7mWQXrf1XKZwVl3Nf1BIE/edit?usp=sharing> >>>>>>>> which >>>>>>>> may still be a useful resource, but for latest information we refer to >>>>>>>> the >>>>>>>> modern API's spec <https://w3c.github.io/webrtc-stats/> and code >>>>>>>> search >>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/stats/rtcstats_objects.h> >>>>>>>> . >>>>>>>> >>>>>>>> *Summary* >>>>>>>> WebRTC is a set of JavaScript APIs (spec >>>>>>>> <https://w3c.github.io/webrtc-pc/>) enabling real-time >>>>>>>> communication, most notably realtime audio and video for Video >>>>>>>> Conferencing >>>>>>>> in the browser. getStats() is an API that allow apps to measure things >>>>>>>> like >>>>>>>> bitrate and media quality information about the session. >>>>>>>> >>>>>>>> The history is that spec and implementations evolved so quickly >>>>>>>> that the API was forked into two paths: the callback-based one that >>>>>>>> only >>>>>>>> exists in Chromium and has no spec and the promise-based one which has >>>>>>>> both >>>>>>>> a spec and pretty good cross-browser compatibility support >>>>>>>> <https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=experimental&label=master&aligned> >>>>>>>> . >>>>>>>> >>>>>>>> In Chromium, the legacy API has been on feature freeze for several >>>>>>>> years and the goal was always to deprecate and remove it, but due to >>>>>>>> high >>>>>>>> usage this was not a possibility. This story is finally changing: >>>>>>>> usage >>>>>>>> graphs >>>>>>>> <https://webrtchacks.github.io/chromestatus/?buckets=1058,1476,1402&start=2022-01-01&window=7> >>>>>>>> . >>>>>>>> >>>>>>>> [image: Screenshot 2023-02-16 at 13.43.40.png] >>>>>>>> >>>>>>>> According to chromestatus.com stats >>>>>>>> <https://chromestatus.com/metrics/feature/popularity>, >>>>>>>> - RTCPeerConnectionGetStatsLegacyNonCompliant is 0.0183% and >>>>>>>> - RTCPeerConnectionGetStats is 0.2177% of page loads. >>>>>>>> In other words, legacy is 8% as popular as modern. >>>>>>>> >>>>>>>> According to UMA stats, >>>>>>>> - RTCPeerConnectionGetStatsLegacyNonCompliant is 0.000177% and >>>>>>>> - RTCPeerConnectionGetStats is 0.00114% of page loads. >>>>>>>> In other words, legacy is 15% as popular as modern. >>>>>>>> >>>>>>>> I don't know why UMAs and chromestatus shows different orders of >>>>>>>> magnitude when it comes to usage, but we're roughly talking about the >>>>>>>> legacy API being 1/10th as popular as the modern API. I think it is >>>>>>>> time to >>>>>>>> add a deprecation warning to the legacy API. >>>>>>>> >>>>>>>> *Risks* >>>>>>>> Usage is still high and migrating from the legacy API to the modern >>>>>>>> API may require a significant amount of work from developers. >>>>>>>> >>>>>>>> To mitigate this, we should have a long deprecation timeline and >>>>>>>> allow developers to opt-in to a Deprecation Trial to get more time. >>>>>>>> >>>>>>>> *Proposal* >>>>>>>> Add a deprecation warning in M113 and the possibility to opt-in to >>>>>>>> a deprecation trial. >>>>>>>> Add use counts for how many of the legacy API uses do and do not >>>>>>>> use the deprecation trial and track this over time. >>>>>>>> >>>>>>>> In M114, start throwing an exception in Canary/Beta if attempting >>>>>>>> to use the legacy API outside the trial *but do not throw* in >>>>>>>> Stable yet. Give apps more time to sign up to the trial. >>>>>>>> >>>>>>>> In M115, gently roll out the throwing of the exception to Stable, >>>>>>>> i.e. from this milestone onwards apps are required to use the >>>>>>>> deprecation >>>>>>>> trial if they want to continue to use the legacy getStats() API. >>>>>>>> >>>>>>>> M115 is Stable on June 27. >>>>>>>> Set the Deprecation Trial end date to M120 / December 5, 2023. >>>>>>>> This gives apps paying attention to the deprecation warning ~9 >>>>>>>> months to migrate and apps only paying attention to exceptions on >>>>>>>> stable ~6 >>>>>>>> months to migrate. >>>>>>>> >>>>>>>> -- >>>>>>>> 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+unsubscr...@chromium.org. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink- >>>>>>>> dev/8edb3ad3-c383-4c18-9595-81fb0732fa10n%40chromium.org >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8edb3ad3-c383-4c18-9595-81fb0732fa10n%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>>> -- >>>>> 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. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXvoddJYizkHGzmavf6LLyqxY1VGLfZfW%3D%2BrmZBBHNq8Q%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXvoddJYizkHGzmavf6LLyqxY1VGLfZfW%3D%2BrmZBBHNq8Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- > 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+unsubscr...@chromium.org. > > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfRn4nBRmfmvgJ8DFnmEZaCN_fGxqkEGsYK9z2ndyL1fQ%40mail.gmail.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfRn4nBRmfmvgJ8DFnmEZaCN_fGxqkEGsYK9z2ndyL1fQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7da5a9a8-a1c6-4f87-be59-c5a4bb63e2b2n%40chromium.org.
