Bugzilla

I figured out the STRs. It's when replacing a disabled track with an enabled one. This should result in data sent, but bug 1423253 broke this in 68:
 1. Open https://jsfiddle.net/jib1/x03wspuq/
 2. (Allow permission if necessary)
 2. Check the `☐ scramble` box.

Expected results:
* Whitenoise appars in the second element

Actual results: 
* The second element remains black.

Regression range:

15:38.77 INFO: Narrowed inbound regression window from [deda4112, e5fc0c88] (3 builds) to [fc6f661f, e5fc0c88] (2 builds) (~1 steps left)
15:38.77 INFO: No more inbound revisions, bisection finished.
15:38.77 INFO: Last good revision: fc6f661f4113fa38c6e44663c404edc7e3ceadec
15:38.77 INFO: First bad revision: e5fc0c881af02fe17288ea08f3f5c3a85a5070e8
15:38.78 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fc6f661f4113fa38c6e44663c404edc7e3ceadec&tochange=e5fc0c881af02fe17288ea08f3f5c3a85a5070e8

Workarounds:
1. Either temporarily enable a track before replacing it:
```
const old = sender.track;
const tmp = old.enabled;
old.enabled = true;
await sender.replaceTrack(withTrack);
old.enabled = tmp;
```
2. Or twiddle the enabled state afterwards.
```
await sender.replaceTrack(withTrack);
if (sender.track.enabled) {
  sender.track.enabled = false;
  sender.track.enabled = true;
}
```

Note you don't need `setTimeout` to make the workaround work.

[Tracking Requested - why for this release]: Regression causing WebRTC video/audio to not play when relying on `replaceTrack()` to replace a disabled track with an enabled one. Simple workaround exists.

I figured out the STRs. It's when replacing a disabled track with an enabled one. This should result in data sent, but bug 1423253 broke this in 68:
 1. Open https://jsfiddle.net/jib1/x03wspuq/
 2. (Allow permission if necessary)
 2. Check the `☐ scramble` box.

Expected results:
* Whitenoise appars in the second element

Actual results: 
* The second element remains black.

Regression range:

15:38.77 INFO: Narrowed inbound regression window from [deda4112, e5fc0c88] (3 builds) to [fc6f661f, e5fc0c88] (2 builds) (~1 steps left)
15:38.77 INFO: No more inbound revisions, bisection finished.
15:38.77 INFO: Last good revision: fc6f661f4113fa38c6e44663c404edc7e3ceadec
15:38.77 INFO: First bad revision: e5fc0c881af02fe17288ea08f3f5c3a85a5070e8
15:38.78 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fc6f661f4113fa38c6e44663c404edc7e3ceadec&tochange=e5fc0c881af02fe17288ea08f3f5c3a85a5070e8

Workarounds:
1. Either temporarily enable a track before replacing it:
```js
const old = sender.track;
const tmp = old.enabled;
old.enabled = true;
await sender.replaceTrack(withTrack);
old.enabled = tmp;
```
2. Or twiddle the enabled state afterwards.
```js
await sender.replaceTrack(withTrack);
if (sender.track.enabled) {
  sender.track.enabled = false;
  sender.track.enabled = true;
}
```

Note you don't need `setTimeout` to make the workaround work.

[Tracking Requested - why for this release]: Regression causing WebRTC video/audio to not play when relying on `replaceTrack()` to replace a disabled track with an enabled one. Simple workaround exists.