Bug 216006 – Introduce a C++ chain of operations in RTCPeerConnection

• Component: WebRTC
• Status: RESOLVED FIXED

[youenn fablet]

Introduce a C++ chain of operations in RTCPeerConnection

[youenn fablet]

Created attachment 407604 [details]
Patch

[youenn fablet]

Created attachment 407605 [details]
Patch

[youenn fablet]

Created attachment 407612 [details]
Patch

[Eric Carlson]

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?

[youenn fablet]

(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.

[youenn fablet]

Created attachment 407753 [details]
Patch for landing

[EWS]

Committed r266468: <https://trac.webkit.org/changeset/266468>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 407753 [details].

[Radar WebKit Bug Importer]

<rdar://problem/68214334>