Open Bug 966528 Opened 6 years ago Updated 2 years ago

Test for onaddstream events during setRemoteDescription processing


(Core :: WebRTC: Signaling, defect, P4)




Blocking Flags:


(Reporter: mt, Unassigned)


(Blocks 1 open bug)


The current set of mochitests in dom/media/tests/mochitests/template.js do not check that the onaddstream events have fired at the right time.  The spec requires that RTCPeerConnection raise this event prior to calling the callback to setRemoteDescription.
I think these two bugs are relevant here:

onaddstream currently fires when the media tracks are available as requested in 873888.
Bug 880366 is invalid; but the fact that 873888 was correctly fixed probably needs to be checked as part of this, yes.  Having the test include both audio and video tracks seems appropriate.
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #3)

Sorry, but that checkin is not related to this ticket at all.
Resolution: FIXED → ---
Should have been bug 967528, thanks.
I think even without a dedicated test case it is pretty obvious that the current implementation is broken. I opened Bugs 998546 and 998552 to get this fixed one way or the other.
Note that bug 873888 was needed because of how tracks get created in our MediaStreamGraph implementation (which is asynchronous).  To avoid calling onaddstream before the tracks are available, we delay it until they are.  I don't remember if the text about firing onaddstream ASAP was in the spec before we did this, but at the moment we're constrained by the underlying implementation.  Our only other option would be to also delay the success call from setRemoteDescription.

Not that the text does not *require* it happen before the success callback, merely "Onnaddstream happens as early as possible after the setRemoteDescription".  We are in fact firing it "as early as possible" in our current implementation.
Blocks: webrtc_spec
backlog: --- → webRTC+
Rank: 35
Priority: -- → P3
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
You need to log in before you can comment on or make changes to this bug.