Bug 216006 - Introduce a C++ chain of operations in RTCPeerConnection
Summary: Introduce a C++ chain of operations in RTCPeerConnection
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebRTC (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: youenn fablet
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-08-31 08:46 PDT by youenn fablet
Modified: 2020-09-02 09:20 PDT (History)
17 users (show)

See Also:


Attachments
Patch (141.32 KB, patch)
2020-08-31 09:01 PDT, youenn fablet
no flags Details | Formatted Diff | Diff
Patch (141.36 KB, patch)
2020-08-31 09:24 PDT, youenn fablet
no flags Details | Formatted Diff | Diff
Patch (150.07 KB, patch)
2020-08-31 11:00 PDT, youenn fablet
no flags Details | Formatted Diff | Diff
Patch for landing (149.41 KB, patch)
2020-09-02 02:26 PDT, youenn fablet
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description youenn fablet 2020-08-31 08:46:08 PDT
Introduce a C++ chain of operations in RTCPeerConnection
Comment 1 youenn fablet 2020-08-31 09:01:41 PDT
Created attachment 407604 [details]
Patch
Comment 2 youenn fablet 2020-08-31 09:24:48 PDT
Created attachment 407605 [details]
Patch
Comment 3 youenn fablet 2020-08-31 11:00:29 PDT
Created attachment 407612 [details]
Patch
Comment 4 Eric Carlson 2020-09-01 11:17:11 PDT
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?
Comment 5 youenn fablet 2020-09-02 02:25:48 PDT
(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.
Comment 6 youenn fablet 2020-09-02 02:26:34 PDT
Created attachment 407753 [details]
Patch for landing
Comment 7 EWS 2020-09-02 09:19:57 PDT
Committed r266468: <https://trac.webkit.org/changeset/266468>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 407753 [details].
Comment 8 Radar WebKit Bug Importer 2020-09-02 09:20:18 PDT
<rdar://problem/68214334>