After doing lots of creative approaches on bug 831789, I've hit a wall on trying to get those tests running - the canplaythrough event appears to be failing to fire on the media elements derived from remote Media Streams given from the onaddstream callback with that patch. In theory, I believe that patch should work - upon calling setRemoteDescription with a stream already added, we should get an onaddstream callback eventually with a valid stream that generates media flow. However, what I'm actually seeing appears to be the media stream I'm getting from onaddstream is "broken" - applying the stream to a media element and trying to play it shows that I'm not getting any canplaythrough events fired. If this ends up being a bug in the test that I'm not seeing, then feel free to close this bug as invalid and explain why.

Roc, this blocks some important test automation work for webrtc. Can you assess what's likely going on and how hard it would be to fix? Any logs Jason could get for you that would make this easier? Or help solving it?

Have you called play() on the element? Currently we won't call canPlayThrough() until playback actually starts.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #2) > Have you called play() on the element? Currently we won't call > canPlayThrough() until playback actually starts. Yup. https://mxr.mozilla.org/mozilla-central/source/dom/media/tests/mochitest/mediaStreamPlayback.js#137 Where the media element is generated through: https://mxr.mozilla.org/mozilla-central/source/dom/media/tests/mochitest/head.js#69 And the stream is generated from an onaddstream callback.

When I go to http://mozilla.github.io/webrtc-landing/pc_test.html and add a canplaythrough handler on pc2video, it does get fired. Got a reduced testcase for this?

Hmm...so interestingly enough, running this through the web works fine - I'm seeing canplaythrough fire respectively on each media element derived from a remote stream in this test case I just attached.

Given that Henrik just hit a very similar issue, I think this might be a test framework bug, not a bug in gecko. I'm going to close this and when Henrik or I figures out the event handler issue here, we'll open a new bug to track the work to resolve the event handling problem.

Talking with whimboo, now I'm rethinking this is a bug in mochitest after his investigation he conducted - it actually revealed an actual bug. He thinks we should hold off retrying anything until the media stream tracks landed, cause he thinks something could change here. But strangely enough, an end to end test is his investigation never revealed the bug. It only happened in mochitest. So I'm going to work on getting a reduced test case in the context of mochitest then.

(In reply to Jason Smith [:jsmith] from comment #8) > Talking with whimboo, now I'm rethinking this is a bug in mochitest after > his investigation he conducted - it actually revealed an actual bug. He > thinks we should hold off retrying anything until the media stream tracks > landed, cause he thinks something could change here. Meant to say - actual bug in core gecko, not mochitest or the framework.

At this point, I've exhausted all efforts to get a reduced test case outside of the patch in bug 831789 and potentially a slight reduction of it. But I'm generally noticing the canplaythrough & timeupdate events are running into trouble firing when being analyzed as part of the command framework. Eric - You mentioned you would be interested in helping debug this. Could you try running the mochitests with the patch in bug 831789 and seeing what the debugger is saying that might be causing the problem?

Per talking with Eric, this is confirmed to be invalid. Media flow only starts happening after the handshake is established, not midway.