[regression] RTCStatsReport doesn't contain candidate-pair and other types of entries
Reported by
nazar.mo...@gmail.com,
Mar 29 2018
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Steps to reproduce the problem: 1. Call RTCPeerConnection.getStats() (on working instance of course) 2. Examine contents of resolved promise What is the expected behavior? In Chromium 65 stable, in Firefox (including Nightly) and even in Safari it works properly - returns a bunch of entries, including one with `type: candidate-pair`. What went wrong? Chromium Nightly 67.0.3380.0 only returns 2 items with `type: data-channel` and `type: peer-connection`. This breaks simple-peer library as it requires candidate pair to be present when connection is established. Did this work before? N/A Does this work in other browsers? Yes Chrome version: <Copy from: 'about:version'> Channel: canary OS Version: 67 Flash Version:
,
Mar 29 2018
nazar.mokrynskyi@ Thanks for the issue. Tested this issue on Ubuntu 14.04 and Windows 10 on the latest Canary 67.0.3382.0 by following the below steps. 1. Launched Chrome and navigated to appr.tc site and joined a session. 2. Opened Devtools -> Console and entered RTCPeerConnection.getStats() and could see the error 'Uncaught TypeError: RTCPeerConnection.getStats() is not a function'. Attached is the screen shot for reference. Request you to check and confirm if anything is missed from our end in triaging the issue. Also request you to provide the screen cast of the steps followed which will help in further triaging of the issue. Thanks..
,
Mar 29 2018
this can be reproduced using https://webrtc.github.io/samples/src/content/datachannel/basic/ After clicking start, paste this into the JS console: localConnection.getStats().then(s => console.log(s)) says 8 items in 65.0.3325.181 (good) says 2 items in 66.0.3359.66 (bad)
,
Mar 29 2018
I've prepared reduced test case: https://jsfiddle.net/1oku7dbj/
,
Mar 30 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 30 2018
Able to reproduce the issue on reported chrome version 67.0.3380.0 latest Beta 66.0.3359.66 and on the latest canary 67.0.3383.0 using Windows 10, Ubuntu 14.04 and Mac 10.13.1. Bisect Information: ===================== Last Good Build: 66.0.3350.0 First Bad Build: 66.0.3352.0 As 66.0.3351.0 version isn't available, providing Bisect info from the above mentioned chrome versions. You are probably looking for a change made after 537532 (known good), but no later than 537533 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/8f70ae5c0e31e2d9402978a97cdf63755a40b76f..ae686a1b06799d81a23e8b23677d27e71937038b Suspecting: https://webrtc.googlesource.com/src.git/+log/b95324531121..8b815cddcad8 @Steve Anton: Please help in assigning it to the right owner if this is not related to your change. Note: Adding RB-Stable as this seems to be a recent regression, Please remove if not applicable. Thanks!
,
Mar 30 2018
Thanks for the report. I have made a WebRTC change to fix this bug: https://webrtc-review.googlesource.com/c/src/+/65788 Tested by patching into the latest Chrome and running the reproduction case from above. I'll update the bug once the change has landed and merge it into M66.
,
Mar 30 2018
,
Apr 2 2018
Just a heads up, M66 Stable cut is on April 12th, 10 days away. This issue is marked as RB-Stable for 66. Please make sure to address this issue prior to stable cut. Thanks!
,
Apr 2 2018
The following revision refers to this bug: https://webrtc.googlesource.com/src.git/+/7eca09361d6d49df7bcb7bdbeba3e030ce73b5c0 commit 7eca09361d6d49df7bcb7bdbeba3e030ce73b5c0 Author: Steve Anton <steveanton@webrtc.org> Date: Mon Apr 02 18:45:27 2018 Ensure that data channel transport stats are included The RTCStatsCollector was only iterating through RtpTransceivers in order to find the active transports for which to generate stats. But for data channel only connections, there were no RtpTransceivers so no transports were being identified. This CL changes the stats collector to include the transport names of the SCTP and RTP data channel if active. Bug: chromium:826972 Change-Id: I762b253b3bbf0f0d7861bc281b8908decbb9b0d9 Reviewed-on: https://webrtc-review.googlesource.com/65788 Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org> Commit-Queue: Steve Anton <steveanton@webrtc.org> Cr-Commit-Position: refs/heads/master@{#22697} [modify] https://crrev.com/7eca09361d6d49df7bcb7bdbeba3e030ce73b5c0/pc/peerconnection_integrationtest.cc [modify] https://crrev.com/7eca09361d6d49df7bcb7bdbeba3e030ce73b5c0/pc/rtcstatscollector.cc [modify] https://crrev.com/7eca09361d6d49df7bcb7bdbeba3e030ce73b5c0/pc/rtcstatscollector.h
,
Apr 2 2018
The fix has landed in the WebRTC M66 release branch: https://webrtc.googlesource.com/src/+/555c55889bc54bdba0a27215bb82d447c834c0c5
,
Apr 3 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3dc070996730c2aab4a49fefba6669fd41a328a3 commit 3dc070996730c2aab4a49fefba6669fd41a328a3 Author: webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Date: Mon Apr 02 23:59:07 2018 Roll src/third_party/webrtc/ a859c1ac3..7eca09361 (1 commit) https://webrtc.googlesource.com/src.git/+log/a859c1ac3e12..7eca09361d6d $ git log a859c1ac3..7eca09361 --date=short --no-merges --format='%ad %ae %s' Created with: roll-dep src/third_party/webrtc BUG= chromium:826972 The AutoRoll server is located here: https://webrtc-chromium-roll.skia.org Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, please contact the current sheriff, who should be CC'd on the roll, and stop the roller if necessary. CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_archive_rel_ng;master.tryserver.chromium.mac:mac_chromium_archive_rel_ng;master.tryserver.chromium.win:win-msvc-dbg TBR=webrtc-chromium-sheriffs-robots@google.com Change-Id: Ib774178d6b9aa204e20bde42728730c640188818 Reviewed-on: https://chromium-review.googlesource.com/990933 Reviewed-by: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Commit-Queue: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#547572} [modify] https://crrev.com/3dc070996730c2aab4a49fefba6669fd41a328a3/DEPS
,
Apr 9 2018
Reminder: Please note that M66 Stable is only 7 days away. This bug has been marked as ReleaseBlock Stable for M66. So please take a look and appropriately address this bug.
,
Apr 9 2018
,
Apr 9 2018
[Auto-generated comment by a script] We noticed that this issue is targeted for M-66; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-66 label, otherwise remove Merge-TBD label. Thanks.
,
Apr 9 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by sindhu.chelamcherla@chromium.org
, Mar 29 2018