its pretty odd. Doesn't seem to happen without adapter and yet it is a native RTCTrackEvent. adapter hooks into the MediaStream ontrackadded which might cause this.

Tested on the reported version 62.0.3198.0 and on the latest M-63 63.0.3206.0. Attached are the observations from firefox, stable and canary 

@Reporter: Could you please confirm the expected behaviour

CCing hbos@ from  Issue 760107  for furthgr inputs.

Thanks!

Deleted: ActualFirefox.png 253 KB

	ActualFirefox.png 253 KB View Download

Deleted: Actualstable.png 235 KB

	Actualstable.png 235 KB View Download

Deleted: ActualCanary.png 207 KB

	ActualCanary.png 207 KB View Download

I haven't had time to take a look yet but are you sure this is wrong, looks like it fires once for an audio track and once for a video track? That is to be expected if the stream announced in the SDP contains both an audio and video track.

The SDP it looks like two SSRCs with the same stream and track IDs?

I need to take a closer look, I'm not an SDP guru yet.

https://bugs.chromium.org/p/chromium/issues/attachment?aid=300797&inline=1 shows it firing four times. Expected is two times.

Based on discussion with philipp:

C++ does fire "ontrack", but "ontrack" shouldn't exist without the flag according to the prototype.
Maybe C++ successfully fires "ontrack" if it has been overwritten (which adapter.js does) and it also gets fired by adapter.js code.

An hypothesis, yet to have been confirmed.

https://jsfiddle.net/46hx8h65/2/ shows that the track event listener is called (and this does not include adapter.js). Oddly, trying to do the same with pc.ontrack does not fire.

hbos@ you can use apprtc or pc1 to reproduce this behavior as seen in https://github.com/webrtc/apprtc/issues/481

ah... apprtc / pc1 even show that the RTCTrackEvent does not have a streams array. Good thing we caught that too!

I think I know what is going, I'll start now, hopefully I'll have a fix shortly.

Doing pc.addEventListener('track', callback); results in the callback being invoked when ontrack should fire, even though ontrack is behind experimental web platform flags and the flag is off (that's a bug!). Not only does it fire when it shouldn't, because the RTCTrackEvent is behind a flag the event that does fire have undefined track and streams members.

Repro case fiddle for both ontrack and addEventListener: https://jsfiddle.net/46hx8h65/4/

This fixes it: https://chromium-review.googlesource.com/c/chromium/src/+/663259

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/81fe9724b9aa939bea960363c3db0863cb11a822

commit 81fe9724b9aa939bea960363c3db0863cb11a822
Author: Henrik Boström <hbos@chromium.org>
Date: Tue Sep 12 17:25:42 2017

Don't fire ontrack if flag used by RTCTrackEvent is disabled.

It turned out that without making this event dispatching conditional on
the flag it would fire anyway.

It only fires if you listen to the event using addEventListener('track',
X), not if you use ontrack = X. When it fires and the flag is off it
looks like RTCTrackEvent members such as track and streams are undefined
because RTCTrackEvent is behind flag.

With this change you get the expected behavior with and without the flag
enabled.

Also fixes https://github.com/webrtc/apprtc/issues/481

Bug:  761612 
Change-Id: Ideaf636633821b0bd9718ef0d2a7a8e7e8b289c1
Reviewed-on: https://chromium-review.googlesource.com/663259
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Commit-Queue: Henrik Boström <hbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501325}
[modify] https://crrev.com/81fe9724b9aa939bea960363c3db0863cb11a822/third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp

Bam!

is an uplift to 62 needed?

Oh, right, let's see if we can merge it!

Tested these issue on Ubuntu 14.04 with chrome #63.0.3214.0 by disabling the "Experimental Web Platforms" flag.
Observed that in the console, there are 2 events are fired for audio and video.
Attaching the screencast for reference.

hbos@ could you please confirm that this is the expected behavior of this fix.

Thank You...

Deleted: 761612.mp4 2.4 MB

	761612.mp4 2.4 MB View Download

kkaluri@: Yes because http://jsfiddle.net/46hx8h65/ pulls in adapter-latest.js which shims track events.
If you remove <script src="https://webrtc.github.io/adapter/adapter-latest.js"></script> and press Run you will get no event fired.

See also https://jsfiddle.net/46hx8h65/4/.

I have confirmed with tip of tree both fiddles and with and without experimental web platform features. It gives the expected behavior.

WRT http://jsfiddle.net/46hx8h65/ before the fix the event was fired twice per track, now it is fired once per track but there are two tracks (one audio and one video), that's why you see two events logged. Thanks for the video it was useful :)

This bug requires manual review: M62 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+abdulsyed@ Hi, what do I need to do to get this merged into M62?
Its this CL: https://chromium-review.googlesource.com/c/chromium/src/+/663259

Approving merge for M62. Branch:3202

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/248d2df108293b5ef67383214fefc4609021efe9

commit 248d2df108293b5ef67383214fefc4609021efe9
Author: Henrik Boström <hbos@chromium.org>
Date: Mon Sep 18 12:24:00 2017

Don't fire ontrack if flag used by RTCTrackEvent is disabled.

It turned out that without making this event dispatching conditional on
the flag it would fire anyway.

It only fires if you listen to the event using addEventListener('track',
X), not if you use ontrack = X. When it fires and the flag is off it
looks like RTCTrackEvent members such as track and streams are undefined
because RTCTrackEvent is behind flag.

With this change you get the expected behavior with and without the flag
enabled.

Also fixes https://github.com/webrtc/apprtc/issues/481

TBR=hbos@chromium.org

(cherry picked from commit 81fe9724b9aa939bea960363c3db0863cb11a822)

Bug:  761612 
Change-Id: Ideaf636633821b0bd9718ef0d2a7a8e7e8b289c1
Reviewed-on: https://chromium-review.googlesource.com/663259
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Commit-Queue: Henrik Boström <hbos@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#501325}
Reviewed-on: https://chromium-review.googlesource.com/670730
Reviewed-by: Henrik Boström <hbos@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#281}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/248d2df108293b5ef67383214fefc4609021efe9/third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp

Verified this issue on Ubuntu 14.04 with chrome #62.0.3202.29 and observed that fix is working as expected.Hence adding TE-Verified labels

Attaching the screen-cast for reference.

Deleted: 761612-1.mp4 1.6 MB

	761612-1.mp4 1.6 MB View Download

Awesome