This was caused by Firefox adding new WPTs:
https://github.com/web-platform-tests/wpt/commit/3b627befed3cfdb16b26f648899f1f02743c6778

As for https://chromium-review.googlesource.com/c/chromium/src/+/1155249/4/third_party/WebKit/LayoutTests/virtual/webrtc-wpt-unified-plan/external/wpt/webrtc/RTCRtpTransceiver.https-expected.txt,

- "checkMute" failures are expected, our tracks are not muted by default as they should be.
- "stop() is not a function" failures are expected, we did not ship stop().
- "rollback" failures are expected, we have not shipped rollback support.

Need to take a look at:

offerToReceiveAudio/offerToReceiveVideo failures: should file a bug and fix.

FAIL checkAddTransceiverThenAddTrackPairs assert_equals: expected "[{sender:{track:{}}}]" but got "[{sender:{track:{}}},{}]"

I'm guessing checkAddTransceiverNoTrack failed because of the receiver's track not being muted bug.

No big surprises.

Actually a number of new PASS for Unified Plan, also (while Plan B fails all):

2018-07-30 webrtc pass 235 fail 411 pct 36
2018-07-30 webrtc-unified pass 343 fail 303 pct 53
2018-07-31 webrtc pass 235 fail 447 pct 34
2018-07-31 webrtc-unified pass 360 fail 322 pct 52

the offerToReceive stuff is nasty. It is the old question whether createOffer creates state...

var pc = new RTCPeerConnection({sdpSemantics: 'unified-plan'})
const offer = await pc.createOffer({offerToReceiveAudio: true})
pc.getTransceivers() has length 0 by then.

After calling SLD pc.getTransceivers() has length 1.

See https://github.com/w3c/webrtc-pc/issues/1383 for the discussion.

https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCRtpTransceiver.https.html#L104-L121

- this is potentially flaky as chrome implements (and sometimes goes to) completed.

the onstatechange version shouldn't be flaky as the state always passes through "connected" on the way to "completed". but it will be flaky if the state is already "completed" when iceConnected is called.

#2: Using orphis@ script? :)

#6: No, mine (which actually runs the wpt suite on my workstation).

Adding blockage on implementing "rollback".

Note: this test seems to timeout in my latest runs.