Introduce a C++ chain of operations in RTCPeerConnection
Created attachment 407604 [details] Patch
Created attachment 407605 [details] Patch
Created attachment 407612 [details] Patch
Comment on attachment 407612 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=407612&action=review > LayoutTests/imported/w3c/web-platform-tests/webrtc/RTCPeerConnection-setRemoteDescription-offer-expected.txt:2 > -Harness Error (FAIL), message = Unhandled rejection: Description type incompatible with current signaling state > +Harness Error (TIMEOUT), message = null Why do we timeout now? > LayoutTests/imported/w3c/web-platform-tests/webrtc/RTCRtpTransceiver.https-expected.txt:32 > +FAIL checkStopAfterCreateOffer assert_equals: expected "[{mid:null,stopped:true}]" but got "[{mid:\"0\",stopped:true}]" > +FAIL checkStopAfterSetLocalOffer assert_equals: expected "[{mid:null,stopped:true}]" but got "[{mid:\"0\",stopped:true}]" > +FAIL checkStopAfterSetRemoteOffer assert_equals: expected "[]" but got "[{isTrusted:true}]" > +FAIL checkStopAfterCreateAnswer assert_equals: expected "[{mid:null,stopped:true}]" but got "[{mid:\"0\",stopped:true}]" Looks like this only fails because we return `0` instead of `null`. Can we fix this? > LayoutTests/platform/mac/webrtc/captureCanvas-webrtc-software-encoder-expected.txt:4 > -PASS captureStream with webrtc - h264 baseline > -PASS captureStream with webrtc - h264 high profile > +FAIL captureStream with webrtc - h264 baseline promise_test: Unhandled rejection with value: "test2 failed" > +FAIL captureStream with webrtc - h264 high profile promise_test: Unhandled rejection with value: "test2 failed" Is this expected?
(In reply to Eric Carlson from comment #4) > Comment on attachment 407612 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=407612&action=review > > > LayoutTests/imported/w3c/web-platform-tests/webrtc/RTCPeerConnection-setRemoteDescription-offer-expected.txt:2 > > -Harness Error (FAIL), message = Unhandled rejection: Description type incompatible with current signaling state > > +Harness Error (TIMEOUT), message = null > > Why do we timeout now? We were already timing out but we are no longer hitting a rejected promise before the timeout. > > > LayoutTests/imported/w3c/web-platform-tests/webrtc/RTCRtpTransceiver.https-expected.txt:32 > > +FAIL checkStopAfterCreateOffer assert_equals: expected "[{mid:null,stopped:true}]" but got "[{mid:\"0\",stopped:true}]" > > +FAIL checkStopAfterSetLocalOffer assert_equals: expected "[{mid:null,stopped:true}]" but got "[{mid:\"0\",stopped:true}]" > > +FAIL checkStopAfterSetRemoteOffer assert_equals: expected "[]" but got "[{isTrusted:true}]" > > +FAIL checkStopAfterCreateAnswer assert_equals: expected "[{mid:null,stopped:true}]" but got "[{mid:\"0\",stopped:true}]" > > Looks like this only fails because we return `0` instead of `null`. Can we > fix this? Yep, will do in a follow-up. > > LayoutTests/platform/mac/webrtc/captureCanvas-webrtc-software-encoder-expected.txt:4 > > -PASS captureStream with webrtc - h264 baseline > > -PASS captureStream with webrtc - h264 high profile > > +FAIL captureStream with webrtc - h264 baseline promise_test: Unhandled rejection with value: "test2 failed" > > +FAIL captureStream with webrtc - h264 high profile promise_test: Unhandled rejection with value: "test2 failed" > > Is this expected? I will remove this change, this should have been uploaded.
Created attachment 407753 [details] Patch for landing
Committed r266468: <https://trac.webkit.org/changeset/266468> All reviewed patches have been landed. Closing bug and clearing flags on attachment 407753 [details].
<rdar://problem/68214334>