signalingstatechange event fires too soon.
Reported by
jbruar...@mozilla.com,
Jan 9
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Steps to reproduce the problem: 1. Open https://jsfiddle.net/jib1/2s0yonrf/ and share camera (twice). 2. Check the first Hold button only. What is the expected behavior? .---- | Hold ☑ |sendonly |sendonly `---- Hold ☐ recvonly recvonly What went wrong? .---- | Hold ☑ |sendrecv |sendonly `---- Hold ☐ sendrecv recvonly Did this work before? No Does this work in other browsers? No Firefox also fires the signalingstatechange event fires too soon, but not as soon as Chrome. [1] Firefox fires it AFTER transceivers are available, but before currentDirection is updated. Chrome fires it BEFORE transceivers are available, and before currentDirection is updated. [2] The spec [3] says to fire it after currentDirection has been updated. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1518672 [2] https://jsfiddle.net/jib1/5ugb7fmd/ [3] https://w3c.github.io/webrtc-pc/#set-description Chrome version: 71.0.3578.98 Channel: stable OS Version: OS X 10.13.6 Flash Version: Specifically, signalingstatechange fires before currentDirection is set when going to "stable", diminishing its usefulness for tracking negotiation results. Because of this—and because Firefox behavior differs enough—I doubt anyone is using it for anything significant; a good thing since hopefully it's not too late to fix it. The spec [3] says to fire this event in step 10, basically after all state has been updated (steps 10-16 solely fire events and resolve the call, whereas currentDirection is set in steps 7 or 8). Not a regression AFAICT.
,
Jan 9
,
Jan 10
Able to reproduce the issue on chrome reported version# 71.0.3578.98 and on latest chrome# 73.0.3666.0 using Mac 10.12.6, Windows-10 and Ubuntu 17.10 with URL and steps mentioned in comment# 0. As this issue is seen from M-69 builds, hence considering this as Non-Regression and marking it as Untriaged. Note: From M-60 to M-65 seen: "TypeError: pc.addTrack is not a function" on navigating to URL in Comment# 1 and from M-65 to M-68 seen: "TypeError: Cannot read property 'track' of undefined" Thanks!
,
Jan 10
,
Jan 10
,
Jan 10
The correct place to fire signalingstatechange would be here: https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/peerconnection/rtc_peer_connection.cc?q=rtc_peer_connection.cc&sq=package:chromium&dr=C&l=2726 Not here: https://cs.chromium.org/chromium/src/content/renderer/media/webrtc/rtc_peer_connection_handler.cc?type=cs&sq=package:chromium&g=0&l=672 And when we fire it, we should fire it synchronously as per-spec, we have some weird logic here: https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/peerconnection/rtc_peer_connection.cc?type=cs&sq=package:chromium&g=0&l=2884 |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by jbruar...@mozilla.com
, Jan 9Forgot to mention, the relevant code emitting the results in the STR is: pc.onsignalingstatechange = async () => { update(pc.getTransceivers()[0].currentDirection); await wait(200); update2(pc.getTransceivers()[0].currentDirection); }