I'm not sure why we ever had this in the first place, and it confuses
people on a nearly weekly basis, so let's get rid of it. The protocols
are enabled right after the corresponding gathering is done, so the only
real effect it has is to produce confusing log messages (first
"candidate not signaled because protocol not enabled", then "protocol
enabled, signaling candidate" right afterwards).
BUG=None
Review-Url: https://codereview.webrtc.org/3018483002
Cr-Commit-Position: refs/heads/master@{#19873}
Many of the tests follow a pattern of "wait for N candidates to be
gathered, then (without waiting) assert that gathering is complete". But
this only works if the "gathering complete" signal happens in the same
task as the last candidate being gathered, which isn't an API guarantee.
So the tests will be less fragile if they do the reverse: "wait for
gathering to be complete, then (without waiting) assert that N candidates
were gathered".
Also fixing some somewhat unrelated issues elsewhere. Like a test that
was supposed to be waiting for some period of time and ensuring no
additional candidates were gathered, but wasn't actually waiting at all.
BUG=None
Review-Url: https://codereview.webrtc.org/3018493002
Cr-Commit-Position: refs/heads/master@{#19872}
In order to eliminate the WebRTC Subtree mirror in Chromium,
WebRTC is moving the content of the src/webrtc directory up
to the src/ directory.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
TBR=tommi@webrtc.org
Bug: chromium:611808
Change-Id: Iac59c5b51b950f174119565bac87955a7994bc38
Reviewed-on: https://webrtc-review.googlesource.com/1560
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19845}
