Re: [mediacapture-main] Should we revisit and document getUserMedia() track order? (#1028)

As an exercise let me walk you through https://www.chromium.org/blink/launching-features/#behavior-changes:
* Can the change cause user-visible or functional breakage? **YES, changes the order of SDP m-lines**
  * Is it possible that existing code relies on the current behavior? **YES, see Safari/Freeswitch or Asterisk interop woes**
  * What would that coding pattern look like? How likely it is that this coding pattern is used in the wild? **see specification-shown example of**  `stream.getTracks().forEach(track => pc.addTrack(track, stream)`
* What are other browser engines doing? **VARIES**
  * Would this change align Chromium's behaviour with other vendors? **YES, matches Firefox. Safari orders by UUID**
  * Or would Chromium be the first to roll-out this behavior change? **NO**
* What is the usage of the feature being changed (typically measured with a UseCounter? **No use counter**
* How likely is breakage in sites that only support Chromium browsers? **some webrtc services do not support Firefox so might not have encountered the new behavior and are not expecting it**

Since we do not have a use-counter I'll make a guess:
* 99.8% of usage is going straight from GUM to addTrack
* 0.0063% of usage is stream.addTrack with a screensharing track and a microphone one. For extra fun 40% of those adds the mic to the screensharing stream, 60% the other way round. I bet this is where the new behavior would break.

Should we ask some Chromium API owners if they would sign this off as a "web-facing change"?
Even ignoring the risk (I am all for it, moar content!) is "most natural and logical behavior" sufficient motivation to justify the effort?

And keep in mind that this affects SDP... you know why Firefox continues to put version 99 into its SDP? Does not seem logical to me...

-- 
GitHub Notification of comment by fippo
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/1028#issuecomment-2667415499 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 19 February 2025 03:20:50 UTC