As part of working on bug 1742842, I noticed that on try on Windows 7 the browser_device_controls_menus.js test tends to keep vsync enabled. It's intermittent without the profiler (3 failures out of 6 runs at https://treeherder.mozilla.org/jobs?repo=try&tier=1%2C2%2C3&revision=44e4adfeb7b1e03b8656568062adf7c71d98a050&test_paths=browser%2Fbase%2Fcontent%2Ftest%2Fwebrtc&searchStr=Windows7) , and becomes a perma-fail with the profiler enabled: https://treeherder.mozilla.org/jobs?repo=try&revision=600217f27e8509f7623f757543c8e51c19a383d0 (8 failures out of 8 runs)

Here is a profile of the behavior: https://share.firefox.dev/3bcBoCV
I'm not exactly sure what's going on there, but there's a lot of activity on the Renderer and Compositor threads, and there are many MediaTrackGraphStableStateRunnable runnables on the main thread, which makes it seem to me like a webrtc stream is still running.

There are SendFlushRendering calls on the main thread, from WM_PAINT events. During normal Firefox operation, WM_PAINT events are only sent when changing window focus, or maybe during resizing. So this regular firing of WM_PAINT events makes me think that some kind of screen sharing is still running.

jib, does this prioritization sound reasonable?

The test in question opens a new tab that does screen-capture and then ends (see 1, 2 and 3).

Are tests that open in new tabs expected to do anything more to clean themselves up? I'll try closing the stream.

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #4)

Are tests that open in new tabs expected to do anything more to clean themselves up?

I don't think so. It should be similar to the user closing a tab in the browser. The only exception would be if the test is keeping references to objects from the closed tab, preventing them from being garbage collected.

https://hg.mozilla.org/mozilla-central/rev/6768c91feeb2

Still failing on current mozilla-central: https://treeherder.mozilla.org/jobs?repo=try&tier=1%2C2%2C3&revision=b0c1c1ca40792de6cb3960f9c087fe4f1c2cb8f3

My local Windows 11 build reproduces: https://share.firefox.dev/3PalPLm

There are "timeupdate" DOM Events received by the html:video@2e04ba26100 id="webRTC-previewVideo" element every 260ms, so it seems the preview video is left playing at the end of the test.

Thanks, Florian.
Stopping the streams instead of playing through a video element when the prompt has been dismissed seems to resolve the failures.
https://treeherder.mozilla.org/jobs?repo=try&revision=80e19e54aa376135242c31809fa633df16ca7d8f&test_paths=browser%2Fbase%2Fcontent%2Ftest%2Fwebrtc

https://hg.mozilla.org/mozilla-central/rev/891e21499044#l1.17

See https://searchfox.org/mozilla-central/rev/ef0aa879e94534ffd067a3748d034540a9fc10b0/browser/actors/WebRTCParent.jsm#967-971

https://hg.mozilla.org/mozilla-central/rev/d4fa99ef8e6f

Set release status flags based on info from the regressing bug 1511416