All browser tests are failing for my 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](https://searchfox.org/mozilla-central/rev/c0bed29d643393af6ebe77aa31455f283f169202/widget/gtk/nsWindow.cpp#5913): ``` 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
Bug 1783818 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
All browser tests are failing for my on wayland, while they pass on xorg. E.g. for these tests (random sample): ```console $ ./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](https://searchfox.org/mozilla-central/rev/c0bed29d643393af6ebe77aa31455f283f169202/widget/gtk/nsWindow.cpp#5913): ```diff 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
All browser tests are failing for me on wayland, while they pass on xorg. E.g. for these tests (random sample): ```console $ ./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](https://searchfox.org/mozilla-central/rev/c0bed29d643393af6ebe77aa31455f283f169202/widget/gtk/nsWindow.cpp#5913): ```diff 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