Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix errors external/wpt/RTCPeerConnection-removeTrack.https.html. #11459

Merged
merged 1 commit into from Jun 12, 2018

Conversation

chromium-wpt-export-bot
Copy link
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented Jun 11, 2018

This is in preparation for RTCRtpTransceiver/Unified Plan support.

"Calling removeTrack with valid sender should set sender.track to null"
Asserting that direction changes from 'sendrecv' to 'recvonly', this
is explicit in the spec[1].

"Calling removeTrack with currentDirection blah should set direction to
blah"
The tests that meant to set up currentDirection to be 'sendrecv' or
'recvonly' before removeTrack() were incorrect. Tests updated to set
up currentDirection correctly. Also updated them to use async/await
because that's much nicer.

These all fail because we don't have transceivers yet, but when running
these changes in the RTCRtpTransceiver WIP CL[2], they all pass.

[1] See step 10 of
https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-removetrack
[2] https://chromium-review.googlesource.com/c/chromium/src/+/1025771/

Bug: 777617
Change-Id: Ie3c077d14ea30038a06a98ecbeea475ac824dd9c
Reviewed-on: https://chromium-review.googlesource.com/1095275
Reviewed-by: Guido Urdaneta guidou@chromium.org
Commit-Queue: Henrik Boström hbos@chromium.org
Cr-Commit-Position: refs/heads/master@{#566366}

Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already reviewed downstream.

This is in preparation for RTCRtpTransceiver/Unified Plan support.

"Calling removeTrack with valid sender should set sender.track to null"
  Asserting that direction changes from 'sendrecv' to 'recvonly', this
  is explicit in the spec[1].

"Calling removeTrack with currentDirection blah should set direction to
 blah"
  The tests that meant to set up currentDirection to be 'sendrecv' or
  'recvonly' before removeTrack() were incorrect. Tests updated to set
  up currentDirection correctly. Also updated them to use async/await
  because that's much nicer.

These all fail because we don't have transceivers yet, but when running
these changes in the RTCRtpTransceiver WIP CL[2], they all pass.

[1] See step 10 of
    https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-removetrack
[2] https://chromium-review.googlesource.com/c/chromium/src/+/1025771/

Bug: 777617
Change-Id: Ie3c077d14ea30038a06a98ecbeea475ac824dd9c
Reviewed-on: https://chromium-review.googlesource.com/1095275
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Commit-Queue: Henrik Boström <hbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566366}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants