1783818 - ChromeUtils.vsyncEnabled() never returning false at the end of browser tests on wayland

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Manuel Bucher [:manuel]]

All browser tests are failing for me on wayland, while they pass on xorg.

E.g. for these tests (random sample):

$ ./mach test browser/base/content/test/general/browser_double_close_tab.js
$ ./mach test netwerk/test/browser/browser_103_redirect.js
$ ./mach test netwerk/test/browser/browser_103_assets.js

The error message is this:

netwerk/test/browser/browser_103_user_load.js
  FAIL waiting for vsync to be disabled - timed out after 50 tries. - false == true - JS frame :: chrome://mochikit/content/browser-test.js :: ensureVsyncDisabled :: line 575
Stack trace:
chrome://mochikit/content/browser-test.js:ensureVsyncDisabled:575
  FAIL 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 - JS frame :: chrome://mochikit/content/browser-test.js :: ensureVsyncDisabled :: line 576
Stack trace:
chrome://mochikit/content/browser-test.js:ensureVsyncDisabled:576

The tests pass on wayland when turning off vsync during startup by changing this line in nsWindow.cpp:

diff --git a/widget/gtk/nsWindow.cpp b/widget/gtk/nsWindow.cpp
index bcbb681978d2c..f3be426d551c2 100644
--- a/widget/gtk/nsWindow.cpp
+++ b/widget/gtk/nsWindow.cpp
@@ -5912,7 +5912,7 @@ nsresult nsWindow::Create(nsIWidget* aParent, nsNativeWidget aNativeParent,
   // Initialize the window specific VsyncSource early in order to avoid races
   // with BrowserParent::UpdateVsyncParentVsyncDispatcher().
   // Only use for toplevel windows for now, see bug 1619246.
-  if (GdkIsWaylandDisplay() &&
+  if (false && GdkIsWaylandDisplay() &&
       StaticPrefs::widget_wayland_vsync_enabled_AtStartup() &&
       mWindowType == eWindowType_toplevel) {
     mWaylandVsyncSource = new WaylandVsyncSource();

System: Arch linux, Gnome 42.3, Wayland

Comment 1

[matc]

I see the same happening on fedora 36. But I noticed that the tests will run fine after switching to a workspace/screen without any other windows before they start.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

./mach mochitest browser/components/search/test/browser/browser_426329.js

browser/components/search/test/browser/browser_426329.js
FAIL waiting for vsync to be disabled - timed out after 50 tries. - false == true - JS frame :: chrome://mochikit/content/browser-test.js :: ensureVsyncDisabled :: line 592
Stack trace:
chrome://mochikit/content/browser-test.js:ensureVsyncDisabled:592
FAIL 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 - JS frame :: chrome://mochikit/content/browser-test.js :: ensureVsyncDisabled :: line 593
Stack trace:
chrome://mochikit/content/browser-test.js:ensureVsyncDisabled:593

Comment 4

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1783818 [Wayland] Don't fire Wayland vsync if VsyncSource is disabled r?emilio

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e7b4e0861109
[Wayland] Don't fire Wayland vsync if VsyncSource is disabled r=emilio

Comment 6

[Natalia Csoregi [:nataliaCs]]

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

Comment 7

[Florian Quèze [:florian]]

Thanks a lot for fixing this! Was this only happening during tests, or was vsync remaining enabled forever for wayland users? (if the latter, this fix might produce significant power savings!)

Comment 8

[Martin Stránský [:stransky] (ni? me)]

(In reply to Florian Quèze [:florian] from comment #7)

Thanks a lot for fixing this! Was this only happening during tests, or was vsync remaining enabled forever for wayland users? (if the latter, this fix might produce significant power savings!)

The Vsync was not running, it just removed the error messages.