Intermittent browser/base/content/test/webrtc/browser_device_controls_menus.js | waiting for vsync to be disabled - timed out after 50 tries.
Categories
(Firefox :: Site Permissions, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr128 | --- | unaffected |
| firefox-esr140 | --- | unaffected |
| firefox141 | --- | unaffected |
| firefox142 | --- | unaffected |
| firefox143 | --- | fix-optional |
People
(Reporter: jib, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(4 keywords, Whiteboard: [stockwell disabled])
Attachments
(4 files)
image.png
https://treeherder.mozilla.org/intermittent-failures/bugdetails?startday=2025-07-05&endday=2025-08-04&tree=all&failurehash=all&bug=1775940 spiked a day after bug 799415 landed. Coincidence?
Not a lot to go on here, as these tests have been subject to a lot of intermittents over the years tracked in bug 1775940 and bugs filed for related tests in the same toml, but wanted to file this data point.
According to the failure logs the test is trying to disable vsync and failing to do so.
From the logs: vsync remained enabled at the end of the test. Is there an animation still running? Consider talking to the performance team for tips to solve this. - false == true
|
||
Comment 1•1 year ago
|
||
Set release status flags based on info from the regressing bug 799415
:emz, since you are the author of the regressor, bug 799415, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
|
||
Updated•1 year ago
|
|
||
Comment 2•1 year ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #0)
According to the failure logs the test is trying to disable vsync and failing to do so.
All browser chrome mochitests way for vsync to be disabled (ie no visual update is pending anymore) before moving on to the next test. If vsync is still not disabled 5s after a test finished, a failure is reported.
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
|
||
Updated•10 months ago
|
|
|
||
Updated•10 months ago
|
|
|
||
Updated•10 months ago
|
|
|
||
Comment 13•10 months ago
|
||
|
||
Comment 14•10 months ago
|
||
|
|
||
Updated•10 months ago
|
|
||
Comment 15•10 months ago
|
||
| bugherder | ||
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
|
||
Comment 18•10 months ago
|
||
|
|
||
Comment 19•10 months ago
|
||
|
||
Comment 20•10 months ago
|
||
| bugherder | ||
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
|
||
Updated•8 months ago
|
|
||
Comment 24•8 months ago
|
||
We should check if the fix for Bug 2007284 also fixes this issue. I'll add re-enabling the tests as a separate patch to the stack.
| Comment hidden (Intermittent Failures Robot) |
|
|
||
Comment 26•4 months ago
|
||
The robot hasn't reported failures in a while. Let's close it and observe.
|
|
||
Updated•4 months ago
|
|
||
Updated•4 months ago
|
|
||
Comment 27•4 months ago
|
||
There are no failures, because the test is still disabled and doesn't run: https://searchfox.org/firefox-main/rev/be31b3948198286e39a9855e414823cb17b6e94c/browser/base/content/test/webrtc/browser.toml#38. We could enable the tests in this bug with Bug 2007284 fixed and observe the results?
|
|
||
Comment 28•4 months ago
|
||
Weird.. I remember re-enabling the test. Maybe I remember it wrong. Sorry I don't really have time to figure out what exact test config needs to be skipped. Happy to do the review if somebody wants to pick this up.
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
|
||
Comment 31•1 month ago
•
|
||
Note up front: the analysis below was produced by Claude (AI-assisted). The
commit archaeology was verified against current mozilla-central; the try
verification described at the end has not been run.
Picking up from comment 27 and comment 28. Two things that are not recorded in
this bug and explain both the silence and the confusion.
1. The blanket disable was collateral from a mechanical cleanup, not a decision
The test is currently skip-if = ["true"], i.e. disabled on every platform, with
the previous conditions left commented above it. That did not come from either
stockwell disable. It came from:
5ce09d7446f4 2025-11-22 Bug 1995583 - test manifest cleanup for idiomatic usage
That patch normalised processor -> arch, dropped retired platforms, and where
the surviving conditions happened to cover everything, collapsed them to "true".
So three weeks after the October stockwell disables (linux asan/tsan, then
windows), the test silently went from "disabled on those configs" to "disabled
everywhere". That is why orangefactor went quiet, and why the April close in
comment 26 looked justified.
2. The re-enable in comment 24 never landed
Comment 28 says "Weird.. I remember re-enabling the test." The bug 2007284
landing (022c942d4079) did touch browser/base/content/test/webrtc/browser.toml,
but only to add a skip-if for a brand new test,
browser_devices_get_user_media_camera_preview_abort.js. There is no
browser_device_controls_menus.js change in it. So the memory is of the plan in
comment 24 rather than a landed patch.
Meanwhile bug 2007284 is RESOLVED FIXED, landed 2026-01-07, shipped in 148. The
root cause has been gone for roughly seven months.
Proposed manifest change
["browser_device_controls_menus.js"]
skip-if = [
"debug", # bug 1369731
"os == 'mac' && os_version == '10.15' && arch == 'x86_64'", # platform migration
"os == 'mac' && os_version == '14.70' && arch == 'x86_64'", # Bug 1869787
"os == 'mac' && os_version == '15.30' && arch == 'aarch64'", # Bug 1707735
]
Dropped, as attributable to this bug and fixed by bug 2007284:
os == 'linux' && os_version == '24.04' && asan(Bug 1981050)os == 'linux' && os_version == '24.04' && tsan(Bug 1981050)os == 'win' && os_version == '11.26100' && arch == 'x86_64'(Bug 1981050)os == 'win' && os_version == '11.26100' && arch == 'x86'(Bug 1981050)os == 'linux' && os_version == '24.04' && arch == 'x86_64' && display == 'x11' && opt
— tagged Bug 1775940, which was duplicated into this bug in comment 3, so it is
the same failure
Also dropped os == 'mac' && os_version == '11.20' && arch == 'aarch64': that
platform now appears nowhere in the tree except this file's own commented block.
The other three mac versions are still referenced by 80-119 manifests each, so
they are kept.
Verification status
Manifest lints clean. Running the test locally on macOS gets 9 passing
assertions and then times out in test_bug_1669801 at the SHARE_WINDOW step —
that is window capture hanging in a headless macOS run, not this bug's "waiting
for vsync to be disabled" signature, and mac aarch64 is skipped in CI regardless.
So it is inconclusive for this bug, but it does show the test has not wholesale
bitrotted over the eight months it has been off.
What this actually needs is a try push with retriggers on the configs that were
failing, per the orangefactor tables in comments 4-21:
- windows11-x86/opt (no_variant)
- windows11-x86_64/opt (no_variant, msix, spi-nw)
- windows11-x86_64/asan
- linux2404-x86_64/asan (swr)
- linux2404-x86_64/tsan (swr)
|
|
||
Comment 32•1 month ago
|
||
The vsync timeouts this test was disabled for were caused by the webrtc preview
stream not being cleaned up when the preview was closed while still loading,
fixed in bug 2007284 (landed 2026-01-07, shipped in 148).
Restores the granular skip-if list. Bug 1995583's manifest cleanup had collapsed
the accumulated conditions to "true" three weeks after the stockwell disables,
which left the test disabled on every platform rather than only the failing
ones. That is why nothing has been reported against this bug since.
Dropped as attributable to this bug: linux 24.04 asan, linux 24.04 tsan, win11
x86_64 and win11 x86. Also dropped the linux x11 opt entry tagged bug 1775940,
which was duplicated into this bug. Dropped mac 11.20, which no longer appears
anywhere else in the tree.
Kept the unrelated pre-existing skips: debug (bug 1369731) and the three live
mac configurations.
Not verified on try. This needs retriggers on windows11-x86/opt,
windows11-x86_64 opt/asan/msix/spi-nw, and linux2404-x86_64 asan/tsan swr
before it can be considered proven.
|
|
||
Comment 33•29 days ago
|
||
Note up front: the analysis below was produced by Claude (AI-assisted). The code
paths described were read and verified in current mozilla-central; nothing here
has been confirmed against a live failure, since the test is still disabled.
Follow-up to the re-enable in D317298. Recording the mechanism now so there is a
head start if the failure comes back once the test runs again.
Why bug 2007284 plausibly explains it, and why this test in particular
The fix is present in
browser/components/webrtc/content/webrtc-preview/webrtc-preview.mjs: there is now
an AbortController, stopPreview() aborts it, and the late-resolving
getUserMedia() bails out when signal.aborted instead of assigning srcObject
on an element that has since been re-parented. Before that, the orphaned capture
stayed live and would start rendering again the next time any prompt unhid the
preview section, which makes it a cross-test-file leak rather than a
self-contained one.
browser_device_controls_menus.js hits that race about as directly as possible.
In browser/base/content/test/webrtc/head.js, shareDevices() calls
menuitem.doCommand() to start a window-capture preview and then clicks the
notification button immediately afterwards, i.e. the preview is dismissed while
still loading.
The specific thing that would keep vsync enabled
The preview's loading indicator is toolkit/themes/shared/icons/loading.svg, which
is animation: loadingRotate 1.8s linear infinite. Any path that leaves the
element in its loading state with the preview section visible will pin vsync
indefinitely. That matches the failure mode described in comment 2 better than
anything else we looked at.
Second candidate, lower likelihood: tab-sharing-icon-pulse in
browser/themes/shared/tabbrowser/tabs.css is 3s linear infinite on
[sharing]:not([selected]). It is the only other infinite animation in the
sharing UI, and would fire if a background tab kept the sharing attribute after
teardown.
Checked and ruled out: the indicator window has no animations, transitions or
rAF loops (webrtcIndicator.css/js); webrtc-preview.css has none; the device grace
period is a one-shot permission expiry and browser-test.js ignores timers of 10s
or more; and get_user_media.html never attaches a stream to a video element.
A related gap that the 2007284 fix did not cover
In browser/actors/WebRTCParent.sys.mjs, the notification eventCallback has a
branch commented "Clean-up video streams of screensharing and camera previews"
for the dismissed and removed topics. The body of that branch only sets
webRTC-preview-section's hidden to true and removes the menupopup command
listeners. It never calls stopPreview().
The stream does get stopped today, but only incidentally:
PopupNotifications.sys.mjs _clearPanel() removes the <popupnotification> from
the panel, which fires the custom element's disconnectedCallback(), which calls
stopPreview(). So preview teardown currently depends on an unrelated
component's re-parenting behaviour rather than on the code whose comment claims
to do it. That works, but it is fragile in a way that would fail silently. Adding
an explicit stopPreview() call in that branch seems worth doing regardless of
whether it is implicated here.
If the failure recurs
Two things worth knowing before digging in:
ChromeUtils.vsyncEnabled()is global, so the file that reports the failure is
not necessarily the file that leaked. A preview stream orphaned by an earlier
webrtc test in the same browser session would surface here. That would also
help explain the chunk- and platform-dependence in the orangefactor tables.- A cheap first check at test end is
document.getElementById("webRTC-preview").shadowRoot.querySelector("video").srcObject
— if that is non-null after the prompt is gone, the preview was orphaned.
|
||
Updated•5 days ago
|
|
|
||
Comment 34•2 days ago
|
||
|
||
Comment 35•2 days ago
|
||
| bugherder | ||
Description
•