New issue
Advanced search Search tips

Issue 826972 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

[regression] RTCStatsReport doesn't contain candidate-pair and other types of entries

Reported by nazar.mo...@gmail.com, Mar 29 2018

Issue description

UserAgent: 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:
 
Labels: Needs-Bisect Needs-Triage-M67
Cc: susan.boorgula@chromium.org
Labels: Triaged-ET Needs-Feedback
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..
826972.png
181 KB View Download
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)
I've prepared reduced test case: https://jsfiddle.net/1oku7dbj/
Project Member

Comment 5 by sheriffbot@chromium.org, Mar 30 2018

Labels: -Needs-Feedback
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
Cc: vamshi.kommuri@chromium.org
Labels: -Type-Bug -Pri-2 -Needs-Bisect hasbisect-per-revision ReleaseBlock-Stable Target-67 FoundIn-67 M-66 FoundIn-66 Target-66 RegressedIn-66 OS-Mac OS-Windows Pri-1 Type-Bug-Regression
Owner: steveanton@chromium.org
Status: Assigned (was: Unconfirmed)
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!
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.
Status: Started (was: Assigned)
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! 
Project Member

Comment 10 by bugdroid1@chromium.org, 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

The fix has landed in the WebRTC M66 release branch: https://webrtc.googlesource.com/src/+/555c55889bc54bdba0a27215bb82d447c834c0c5
Project Member

Comment 12 by bugdroid1@chromium.org, 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

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. 
Status: Fixed (was: Started)
Labels: Merge-TBD
[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.
Labels: -Merge-TBD

Sign in to add a comment