- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 Feb 2019 17:58:09 +0000
- To: public-webrtc-logs@w3.org
> I suggest opening a separate issue to challenge the overall pattern. Sure, I understand that RTCPeerConnection has this behavior. Other APIs I know of usually resolve or reject promises whenever possible, except in some specific cases, like the page is navigating for instance or the task is still pending. In this particular case, there is no pending task, so the expectation is to either resolve or reject the promise. Although this particular RTCPeerConnection is surprising, this issue is a separate issue. > I believe we're consistent: Outstanding Pomises are left pending on `pc.close()`. [#150 (comment)](https://github.com/w3c/webrtc-pc/issues/150#issuecomment-152333247) RTCRtpSender is not consistently doing that. RTCRtpSender.setParameters and RTCRtpSender.getStats are not checking for stopped/closed before resolving/rejecting the promise. Note also that the PR further ties RTCRtpSender with RTCPeerConnection, which is not great. It does not align with the idea of being able to create objects like transceivers or data channels directly from an ice connection. What is the benefit of the PR vs. removing step 6.4.4.1, or replacing step 6.4.4.1 by rejecting the promise with InvalidStateError? -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2106#issuecomment-467112336 using your GitHub account
Received on Monday, 25 February 2019 17:58:11 UTC