Some wpt 2pass subtests incorrectly excluded from and some less2pass included in interop-2026
Categories
(Core :: WebRTC, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox150 | --- | fixed |
People
(Reporter: jib, Assigned: jib)
References
Details
Attachments
(7 files)
With wpt.fyi having updated, hindsight is improved, and I either found a couple subtests I missed (or some of these are intermittent?):
-
RTCPeerConnection-addIceCandidate.html?rest
- addIceCandidate after close should reject with InvalidStateError
- addIceCandidate should not recognize relayProtocol or url
-
RTCPeerConnection-getStats.https.html?rest
- getStats() with track not added to connection should reject with InvalidAccessError
- getStats() with track associated with both sender and receiver should reject with InvalidAccessError
- getStats() audio contains inbound-rtp stats
- getStats(track) should not work if multiple senders have the same track
- getStats succeeds on a closed peerconnection
-
RTCPeerConnection-iceGatheringState.html?rest
- renegotiation that closes all transports should result in ICE gathering state "new"
-
RTCRtpParameters-codec.html?rest
- <nothing>
The last one changed between when I first pasted the top list (see screenshot) to now as I'm typing in this description hours later.
This suggests that the results are moving. Might be intermittent results?
Or incorrect wpt.fyi filtering behavior... e.g. https://wpt.fyi/results/webrtc/RTCRtpParameters-codec.html%3Frest?label=master&product=firefox&product=chrome&product=safari&q=%3Frest%20count%3D2%28status%3Apass%29%20 shows me less2pass and 3pass...
| Assignee | ||
Comment 1•7 months ago
•
|
||
Also, conversely
count<2(status:pass) ?interop-2026 (addIceCandidate details):
- RTCPeerConnection-addIceCandidate.html?interop-2026
- addIceCandidate({"candidate":"","sdpMid":null,"sdpMLineIndex":null}) adds a=end-of-candidates to both m-sections
- addIceCandidate(undefined) adds a=end-of-candidates to both m-sections
- addIceCandidate(null) adds a=end-of-candidates to both m-sections
- addIceCandidate({}) adds a=end-of-candidates to both m-sections
- addIceCandidate({}) in stable should work, and add a=end-of-candidates to both m-sections
- addIceCandidate({usernameFragment: usernameFragment1, sdpMid: sdpMid1}) should work, and add a=end-of-candidates to the first m-section
- addIceCandidate({usernameFragment: usernameFragment2, sdpMLineIndex: 1}) should work, and add a=end-of-candidates to the first m-section
- addIceCandidate({usernameFragment: "no such ufrag"}) should not work
- Add with empty candidate string (end of candidates) should succeed
- Add candidate with invalid usernameFragment should reject with OperationError
- Add candidate with sdpMid belonging to different usernameFragment should reject with OperationError
| Assignee | ||
Comment 2•7 months ago
•
|
||
This is interesting: the count=2(status:pass) ?rest results from comment 0 are intermittent. I'm going to start documenting this. (see image below)
RTCDataChannel-GC.html?rest
- Control: detected remote PC being closed using a data channel
RTCRtpTransceiver.https.html?rest
- track with audio gets unmuted when packets flow.
| Assignee | ||
Comment 3•7 months ago
|
||
| Assignee | ||
Comment 4•7 months ago
|
||
- RTCPeerConnection-remote-track-properties.https.html?rest
- Remote audio track ID is different on different PCs
- Remote video track ID is different on different PCs
| Assignee | ||
Comment 5•7 months ago
|
||
| Assignee | ||
Comment 6•7 months ago
|
||
RTCRtpTransceiver-setCodecPreferences.html
- setCodecPreferences should accept audio codecs regardless of mimeType case
- setCodecPreferences should accept video codecs regardless of mimeType case
| Assignee | ||
Comment 7•7 months ago
|
||
Updated•7 months ago
|
| Assignee | ||
Comment 8•7 months ago
|
||
Another observation from ?rest is that these 9 100% passing ?rest tests did not need splitting:
RTCDataChannel-GC.html?rest 1 / 1 1 / 1 1 / 1
RTCDtlsTransport-state.html?rest 1 / 1 1 / 1 1 / 1
RTCDTMFSender-ontonechange.https.html?rest 11 / 11 11 / 11 11 / 11
RTCPeerConnection-constructor.html?rest 12 / 12 12 / 12 12 / 12
RTCRtpSender-replaceTrack.https.html?rest 9 / 9 9 / 9 9 / 9
RTCRtpTransceiver-stop.html?rest 7 / 7 7 / 7 7 / 7
RTCSctpTransport-maxChannels.html?rest 1 / 1 1 / 1 1 / 1
rtp-stats-lifetime.https.html?rest 8 / 8 8 / 8 8 / 8
toJSON.html?rest 1 / 1 1 / 1 1 / 1
| Assignee | ||
Comment 9•7 months ago
•
|
||
Leaving RTCSctpTransport-maxChannels.html?rest alone as I plan to add rollback subtests there for https://github.com/w3c/webrtc-pc/pull/3094.
| Assignee | ||
Comment 10•7 months ago
|
||
Comment 11•6 months ago
|
||
Comment 12•6 months ago
|
||
Comment 13•6 months ago
•
|
||
Backed out for causing wpt and TVw failures at webrtc/RTCRtpSender-replaceTrack.
Backout Link
Push with failures
Failure Log
Failure Log for TVw1
Failure Log for TVw2
Failure line TEST-UNEXPECTED-TIMEOUT | /webrtc/RTCRtpSender-replaceTrack.https.html | ReplaceTrack transmits the new track not the old track - Test timed out
Comment 14•6 months ago
|
||
Comment 16•6 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/02c6cc15d044
https://hg.mozilla.org/mozilla-central/rev/50d04a0ff89a
| Assignee | ||
Updated•6 months ago
|
Updated•6 months ago
|
Comment 17•5 months ago
|
||
Comment 18•5 months ago
|
||
| bugherder | ||
Description
•