[Regression] Firefox 95 is laggy on GMA X4500 (EGL related?)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

Updated to Firefox 95.

Actual results:

After an update to Firefox 95 (I use the Flathub package with the Wayland socket and `MOZ_ENABLE_WAYLAND=1`) it became locked to 120 FPS according to testufo.com on my 144 Hz monitor. Also smooth scrolling looks very janky even when I change the monitor to 120 Hz to match Firefox.

I use Fedora 35 Silverblue with GNOME 41 on Wayland. The same happens in a new Firefox profile.

```
Application Basics
------------------

Name: Firefox
Version: 95.0
Build ID: 20211129150630
Distribution ID: mozilla-flatpak
Update Channel: release
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0
OS: Linux 5.15.6-200.fc35.x86_64 #1 SMP Wed Dec 1 13:41:10 UTC 2021
OS Theme: Adwaita / Adwaita
Multiprocess Windows: 1/1
Fission Windows: 1/1 Enabled by phased rollout
Remote Processes: 8
Enterprise Policies: Active
Google Location Service Key: Found
Google Safebrowsing Key: Found
Mozilla Location Service Key: Found
Safe Mode: false

Crash Reports for the Last 3 Days
---------------------------------

Firefox Features
----------------

Name: DoH Roll-Out
Version: 2.0.0
ID: <email address hidden>

Name: Firefox Screenshots
Version: 39.0.1
ID: <email address hidden>

Name: Form Autofill
Version: 1.0.1
ID: <email address hidden>

Name: Picture-In-Picture
Version: 1.0.0
ID: <email address hidden>

Name: Proxy Failover
Version: 1.0.2
ID: <email address hidden>

Name: Web Compatibility Interventions
Version: 28.0.0
ID: <email address hidden>

Name: WebCompat Reporter
Version: 1.4.2
ID: <email address hidden>

Remote Features
---------------

bug-1690367-rollout-moving-webrtc-networking-functionality-into-i-release-87-100: active
bug-1715474-rollout-yandex-sponsored-tile-rollout-release-89-100: active
bug-1732206-rollout-fission-release-rollout-release-94-95: active

Remote Processes
----------------

Type: Privileged About
Count: 1

Type: Extension
Count: 1

Type: Isolated Web Content
Count: 2

Type: Preallocated
Count: 3

Type: Socket
Count: 1

Add-ons
-------

Name: Russian spellchecking dictionary
Type: dictionary
Version: 0.4.5.1webext
Enabled: true
ID: <email address hidden>

Name: Add-ons Search Detection
Type: extension
Version: 2.0.0
Enabled: true
ID: <email address hidden>

Name: Amazon.com
Type: extension
Version: 1.3
Enabled: true
ID: <email address hidden>

Name: Bing
Type: extension
Version: 1.3
Enabled: true
ID: <email address hidden>

Name: DuckDuckGo
Type: extension
Version: 1.1
Enabled: true
ID: <email address hidden>

Name: Firefox Multi-Account Containers
Type: extension
Version: 8.0.2
Enabled: true
ID: @testpilot-containers

Name: FrankerFaceZ
Type: extension
Version: 4.0
Enabled: true
ID: <email address hidden>

Name: GNOME Shell integration
Type: extension
Version: 10.1
Enabled: true
ID: <email address hidden>

Name: Google
Type: extension
Version: 1.1
Enabled: true
ID: <email address hidden>

Name: HTTPS Everywhere
Type: extension
Version: 2021.7.13
Enabled: true
ID: <email address hidden>

Name: New Popup D...

The [Bugbug](https://github.com/mozilla/bugbug/) bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Created attachment 9254276
vsynctester with screen set to 144 Hz

Also vsynctester.com shows this mess of frame timings when the screen is set to 144 Hz. It works fine when the screen is set to 120 Hz. Maybe it'll help diagnosing where the issue lies.

Hm, this is strange - I'm not aware of any changes in that area. There was bug 1640779, but that shouldn't have any impact on Wayland.

If you have time, would it be possible for you to use `mozregression` to find the offending commit?

mozregression how-to is here:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool

```
13:07.87 INFO: Narrowed integration regression window from [334e3d59, 77e655ba] (3 builds) to [334e3d59, f632271e] (2 builds) (~1 steps left)
13:07.87 INFO: No more integration revisions, bisection finished.
13:07.87 INFO: Last good revision: 334e3d59d932dd2850dec7c582f32f49b504e450
13:07.87 INFO: First bad revision: f632271e9d62ad6b7e90acd52e77d3e02a66980e
13:07.87 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=334e3d59d932dd2850dec7c582f32f49b504e450&tochange=f632271e9d62ad6b7e90acd52e77d3e02a66980e
```

Thanks. Can you try latest nightly if it's fixed there?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

97.0a1 (2021-12-07): the first time I ran it it was locked to 60 FPS but subsequent runs it seems to behave as it should, no issue.

Thanks for testing. So it's fixed in latest nightly then.

Hm, shouldn't we check what fixed it? And potentially backport the fix?

A backport would be nice. It's a bit of a deal breaker here, I'm considering downgrading to 94 or something for the time being.

(In reply to Ivan Molodetskikh from comment #10)
> A backport would be nice. It's a bit of a deal breaker here, I'm considering downgrading to 94 or something for the time being.

Can you find the commit that fixes things with `mozregression`? :) (p.s.: sorry, don't have a 144Hz screen yet)

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

> Can you find the commit that fixes things with `mozregression`?

A bit of a problem here. First, `mozregression`, at least in `--find-fix` mode, seems to be converting release numbers to dates, which pulls the build for the next version (so `95` pulls `96.0a`)—not sure if that is intended.

Second, on the profile that `mozregression` runs even 2021-12-07 gives the 120 FPS lock. When creating a new profile from every instance run by `mozregression` and switching to it twice, neither `94` (`95.0a`), nor `95` (`96.0a`), nor 2021-12-07 exhibit the issue. Nevertheless, when testing tarballs for stable 95 and 2021-12-07 outside of `mozregression`, stable 95 exhibits the issue even when making a new profile, while 2021-12-07 is fine on a new profile as I mentioned above.

I'm also affected with this problem since I updated to Firefox 95 today.

I have a 180hz monitor and Firefox 94 properly rendered at 180 fps with buttery smooth perfection (with layout.frame_rate set to the default of -1), as tested on sites such as https://www.testufo.com/.

But now, after updating to 95, it is only rendering at 120 fps with terrible results at https://www.vsynctester.com
If I try to force 180 fps in layout.frame_rate it's even worse, as I get stutters.

What can I do to get the old behavior back until this is fixed?
I hope this gets a backport, taking into consideration it is a regression.

(In reply to Ivan Molodetskikh from comment #13)
> > Can you find the commit that fixes things with `mozregression`?
>
> A bit of a problem here. First, `mozregression`, at least in `--find-fix` mode, seems to be converting release numbers to dates, which pulls the build for the next version (so `95` pulls `96.0a`)—not sure if that is intended.

Hm, I guess you can simply use the `--good` and `--bad` parameters, no?

> Second, on the profile that `mozregression` runs even 2021-12-07 gives the 120 FPS lock. When creating a new profile from every instance run by `mozregression` and switching to it twice, neither `94` (`95.0a`), nor `95` (`96.0a`), nor 2021-12-07 exhibit the issue. Nevertheless, when testing tarballs for stable 95 and 2021-12-07 outside of `mozregression`, stable 95 exhibits the issue even when making a new profile, while 2021-12-07 is fine on a new profile as I mentioned above.

This is really odd. I also really don't understand where the 120Hz are supposed to come from.

Well, here's one difference I just noticed between 120 FPS locked and 144 FPS windows of the same `--bad 95` build: the 144 FPS one has fission windows 1 Enabled by experiment, while the 120 FPS locked one has 0 disabled.

Might be a false alarm. 2012-12-07 from the tarball does 144 FPS even with fission disabled.

--find-fix is just good and bad swapped.

(In reply to Ivan Molodetskikh from comment #5)
Which command did you exactly run to find this regression range?

I assume it would have to be
$ MOZ_ENABLE_WAYLAND=1 mozregression --good 94 --bad 95 -a https://www.vsynctester.com/
or
$ MOZ_ENABLE_WAYLAND=1 mozregression --good 94 --bad 95 --pref fission.autostart:false -a https://www.vsynctester.com/
or
$ MOZ_ENABLE_WAYLAND=1 mozregression --good 94 --bad 95 --pref fission.autostart:true -a https://www.vsynctester.com/

(In reply to Ivan Molodetskikh from comment #13)
> (so `95` pulls `96.0a`)—not sure if that is intended.

It's intended. 95 was complete with the first Nightly build of 96.

Do you have the proprietary Nvidia driver installed?

> Which command did you exactly run to find this regression range?

`MOZ_ENABLE_WAYLAND=1 mozregression --good 94 --bad 95`, then open testufo.com and planet.mozilla.org by hand to check FPS and scrolling.

> Do you have the proprietary Nvidia driver installed?

Yes, for the secondary NVIDIA GTX 970. My main GPU is AMD RX 580, that's where the displays are plugged in.

Happens to me on an AMD Radeon RX 6800 using the open-source drivers.

My profile has fission enabled.
Also tested on a clean new profile (where fission was disabled by default) and the problem still occurs.

Is scrolling in `about:support` equally stuttery like scrolling websites?

Also: does disabling Wayland help (Xwayland should now get the xrandr-based software sync, which should detect the 144Hz properly)?

> Is scrolling in `about:support` equally stuttery like scrolling websites?

Yeah, exactly the same.

> Also: does disabling Wayland help (Xwayland should now get the xrandr-based software sync, which should detect the 144Hz properly)?

Seems to work fine on the 95 tarball indeed.

(In reply to Robert Mader [:rmader] from comment #22)
> Is scrolling in `about:support` equally stuttery like scrolling websites?

Yes, the same.

Perhaps it was a bit premature to mark 97 as fixed, since as I wrote above, testing it through mozregression on its default profile does show the issue, just like 95 and 96.

Seeing this as well, except I'm locked to 60 FPS on a 144hz display under Wayland (Plasma 5.23.4). Switching over to Xwayland I get 144 FPS.

Firefox 94 was fine, only have the issue after upgrading to 95.

Also ran mozregression --good 94 --bad 95 and got the same regression window:

```
 4:01.33 INFO: Narrowed integration regression window from [334e3d59, 77e655ba] (3 builds) to [334e3d59, f632271e] (2 builds) (~1 steps left)
 4:01.33 INFO: No more integration revisions, bisection finished.
 4:01.33 INFO: Last good revision: 334e3d59d932dd2850dec7c582f32f49b504e450
 4:01.33 INFO: First bad revision: f632271e9d62ad6b7e90acd52e77d3e02a66980e
 4:01.33 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=334e3d59d932dd2850dec7c582f32f49b504e450&tochange=f632271e9d62ad6b7e90acd52e77d3e02a66980e
```

Why was the bug titled changed to mention specifically the AMD RX 580 and Gnome?

I'm also affected by this bug on KDE Plasma on Wayland on an AMD Radeon RX 6800 (I'm using the open-source drivers).

(In reply to Jon Voss from comment #27)
(In reply to nf.pereira from comment #29)

Does the slowdown still occur with https://nightly.mozilla.org?
Start it with env var, for example: `$ MOZ_ENABLE_WAYLAND=1 ~/Downloads/firefox/firefox`

Can the problem be fixed by setting gfx.webrender.allow-partial-present-buffer-age to false, gfx.webrender.max-partial-present-rects to 0 on about:config and restarting Nightly?

(In reply to Jon Voss from comment #27)
Which GPU do you have?

>Does the slowdown still occur with https://nightly.mozilla.org?
Start it with env var, for example: $ MOZ_ENABLE_WAYLAND=1 ~/Downloads/firefox/firefox

Still occurs with the latest nightly build.
I run Arch, so MOZ_ENABLE_WAYLAND=1 is set globally through an export in /etc/profile.d

From about:support:
```
Window Protocol wayland
Desktop Environment kde
Target Frame Rate 60
```
I notice it shows Target Frame Rate at 60 regardless of whether FF is actually running at 144 FPS (like under X)

>Can the problem be fixed by setting gfx.webrender.allow-partial-present-buffer-age to false, gfx.webrender.max-partial-present-rects to 0 on about:config and restarting Nightly?

Yes! Setting those two options in nightly resolves the issue.

>Which GPU do you have?

Radeon 6700XT - mesa 21.3.1

(In reply to Ivan Molodetskikh from comment #0)
(In reply to nf.pereira from comment #29)
Can you confirm that setting gfx.webrender.allow-partial-present-buffer-age to false, gfx.webrender.max-partial-present-rects to 0 on about:config and restarting Nightly fixes the problem permanently? Please test it for a few hours.

(Could be related: EGL/X11/Nvidia suffers from a partial present glitch+slowdown after suspend&resume: bug 1743051)

```
MOZ_ENABLE_WAYLAND=1 mozregression --launch 2021-12-14 --pref gfx.webrender.allow-partial-present-buffer-age:false gfx.webrender.max-partial-present-rects:0
```

still reproduces the issue for me. The prefs are indeed changed in `about:config` that way. I can't test on a tarball nightly properly because of the weird behavior that I mentioned above.

(In reply to Darkspirit from comment #30)
> Does the slowdown still occur with https://nightly.mozilla.org?
> Start it with env var, for example: `$ MOZ_ENABLE_WAYLAND=1 ~/Downloads/firefox/firefox`
>
> Can the problem be fixed by setting gfx.webrender.allow-partial-present-buffer-age to false, gfx.webrender.max-partial-present-rects to 0 on about:config and restarting Nightly?

While testing this I found something really strange about nightly:

When I start nightly with a brand new profile, at first run it only detects 120 fps (should be 180 on my system), but if I close nightly and reopen it, it now detects 180! This is without changing absolutely no setting at all.
I've reproduced this a second time by deleting the profile and recreating it.
What could be causing this? Shouldn't the first-run behavior be exactly the same as any other run?

Tested the same thing on FF stable with a new profile but the problem was still present after multiple FF startups.

When running at 180 fps it seems the issue is fixed in nightly, despite still getting some stutters here and there on TestUFO and VsyncTester. It's hard to say if it was smoother in FF 94 or not, but it seems like it was smoother before.

(In reply to Jon Voss from comment #31)
> Yes! Setting those two options in nightly resolves the issue.

Can you please test nightly again like I described above without changing any settings and see if you get the same behavior as me?
You probably fixed it by restarting nightly and not by changing the settings.

(In reply to nf.pereira from comment #34)
> (In reply to Darkspirit from comment #30)
> (In reply to Jon Voss from comment #31)
> > Yes! Setting those two options in nightly resolves the issue.
>
> Can you please test nightly again like I described above without changing any settings and see if you get the same behavior as me?
> You probably fixed it by restarting nightly and not by changing the settings.

Yep, I just tested again using a fresh profile without those two gfx.webrender settings set.
The first run of nightly runs at 60fps, subsequent runs at 144fps. It's odd that it takes a restart to pick it up, but at least it seems to be working?

I also notice some stutters here and there. 94 seemed to be smoother but that could be anecdotal.

Great, that confirms that gfx.webrender.allow-partial-present-buffer-age and gfx.webrender.max-partial-present-rects don't do anything to this bug.
Now we need to know what change fixed it and why it only works correctly on the 2nd run of the browser.

Also, it's necessary to check if the smoothness was downgraded from 94 onwards.
I will try to compare the smoothness of 94 VS nightly more thoroughly later on VsyncTester.

I think there's a bug in the window config or some timing bug or so.

Please launch nightly with env variable MOZ_LOG="Widget:5" - it should produce the log from window config. Please do it twice - one for the start with 60fps and then for 144fps. Try to keep the log as small as possible - just open a ff window (set https://testufo.com/ or something as homepage to see the sync rate) and close it.

Please attach the two logs here.
Thanks.

Created attachment 9255526
Log for first launch of nightly with MOZ_LOG="Widget:5"

Created attachment 9255527
Log for second launch of nightly with MOZ_LOG="Widget:5"

(In reply to Martin Stránský [:stransky] (ni? me) from comment #37)
> I think there's a bug in the window config or some timing bug or so.
>
> Please launch nightly with env variable MOZ_LOG="Widget:5" - it should produce the log from window config. Please do it twice - one for the start with 60fps and then for 144fps. Try to keep the log as small as possible - just open a ff window (set https://testufo.com/ or something as homepage to see the sync rate) and close it.
>
> Please attach the two logs here.
> Thanks.

Logs attached with the parameter set.

Please ty to run this try locally to see if 144Hz is picked for first time:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b689a5e389ea0a7048e0ded3119baa5f2b96ff20

When the build is done, select [B] by Linux x64 opt, go to 'Artifacts and Debugging Tools' below, download arget.tar.bz2 file. This is Firefox binary produced by this run, so unpack it and try it.

Thanks.

or run
$ MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch b689a5e389ea0a7048e0ded3119baa5f2b96ff20 -a https://testufo.com
once the build is ready

```
MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch b689a5e389ea0a7048e0ded3119baa5f2b96ff20 -a https://testufo.com
```

Gives me 60 FPS on the initial launch, then once I click the address bar and press Enter gives me 120 FPS on the reload. The scrolling is janky. Reloading with just F5 keeps 60 FPS.

Extracted that build and ran on a fresh profile:
./firefox -P nightly http://www.vsynctester.com

I got around 100-110fps on the initial launch. Reloading the page, opening a new tab, or clicking the address bar and pressing Enter to reload the page did not correct. Deleted the profile and tried again, same thing. Also tried about:support and some other pages on new tabs with no difference.

On subsequent launches it runs at 144fps.

We do a window reconfiguration when a new window is opened. If there's a bug in window init it may help to open a new window and it may use updated fps. But this bug is a complete mystery to me :)

A new window with Ctrl-N does 120 FPS on testufo while the original window stays at 60.

False alarm. Moving testufo.com tab to new window preserves its 60 FPS. My result just above was because after Ctrl-N I clicked on the address bar, typed testufo.com and pressed Enter, which as we've established converts it to 120 FPS.

Thanks. I'll create a try with Vsync log to find out what's going on.

There's a try with vsync logging:
https://treeherder.mozilla.org/jobs?repo=try&revision=177d76ba59e45537b8e3e16193bf1390feae17a6

Once it's build please run as:

MOZ_LOG="WidgetVsync:5" MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch 177d76ba59e45537b8e3e16193bf1390feae17a6 -a https://testufo.com

and attach the logs here. Please open only one window to get logs for first 60fps run and then for 120fps run.
Thanks.

> https://treeherder.mozilla.org/jobs?repo=try&revision=177d76ba59e45537b8e3e16193bf1390feae17a6

Seems like the Linux builds have failed?

Yes, pushed a new one:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=2b5fd357b92530986885557cda96240500ee45ab

MOZ_LOG="WidgetVsync:5" MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch 2b5fd357b92530986885557cda96240500ee45ab -a https://testufo.com

Thanks.

Okay, another try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=21e0b9dfd2a8e8ee7d29c81943738f54e8cf8bbf

MOZ_LOG="WidgetVsync:5" MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch 21e0b9dfd2a8e8ee7d29c81943738f54e8cf8bbf -a https://testufo.com

Thanks.

(In reply to Ivan Molodetskikh from comment #47)
> False alarm. Moving testufo.com tab to new window preserves its 60 FPS. My result just above was because after Ctrl-N I clicked on the address bar, typed testufo.com and pressed Enter, which as we've established converts it to 120 FPS.

Hm, this sounds like an issue with the currently Wayland-only per-window frame callback vsync source from bug 1645528. Moving a tab to another window should make it reconnect to the vsync source of that window, but maybe that doesn't happen if it was connected to the software-based 60Hz timer previously.

Created attachment 9255910
WidgetVsync:5 for 60 FPS first launch

Created attachment 9255911
WidgetVsync:5 for 60 FPS then click URL bar, press enter to get 120 FPS

To add to comment 53, we probably want to look into what happens in https://searchfox.org/mozilla-central/source/dom/ipc/VsyncParent.cpp#23-28 (will do so on the weekend if Martin doesn't get to it earlier).

Thanks for the logs. Ivan, can you reproduce a scenario when 120 FPS is picked up after second Firefox start?

Robert, as for the logs, it looks like fps is calculated properly BUT the sync is not propagated to correct window for rendering.

Ivan, please try to get vsync+widget code log by:

MOZ_LOG="Widget:5, WidgetVsync:5" MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch 21e0b9dfd2a8e8ee7d29c81943738f54e8cf8bbf -a https://testufo.com

Just open the window, keep it for 10 sec and close it.
Thanks.

Robert, how is Vsync source paired by nsWindow objects ? Does every nsWindow has it's own VSync or is the VSync object shared?

Created attachment 9255918
"Widget:5, WidgetVsync:5" 60 FPS

> Thanks for the logs. Ivan, can you reproduce a scenario when 120 FPS is picked up after second Firefox start?

Running `mozregression` multiple times always gives me the same behavior (60 FPS first). When I tested nightly builds a few days ago I got 144 FPS on the second start, but I don't think that was indicative of the problem being fixed.

I'll grab the nightly build and get some logs for the 2nd launch that has the correct frame rate.

Created attachment 9255921
"Widget:5, WidgetVsync:5" 144 FPS (2nd launch)

Log file attached for 2nd launch using the above build with WidgetVsync:5

Created attachment 9255922
CORRECTED "Widget:5, WidgetVsync:5" 144 FPS (2nd launch)

Realized I didn't have both Widget5 and WidgetVsync5 enabled. This log file has both.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #60)
> Robert, how is Vsync source paired by nsWindow objects ? Does every nsWindow has it's own VSync or is the VSync object shared?

IIRC on Wayland each `nsWindow` has one `VsyncParent` while on all other platforms there's only one global `VsyncParent`. Will look into it today!

For those running on Gnome, there's an additional issue which in some cases may play into this as well, see https://gitlab.gnome.org/GNOME/mutter/-/issues/1971

Created attachment 9256101
Bug 1744896 - Create WaylandVsyncSource on window creation, r=stransky

Can somebody try the following build with the patch from comment 67? https://treeherder.mozilla.org/jobs?repo=try&revision=a3d81ee59dbfca8aa5d247e9398e58059e2c4381

Edit: for me that build did pick up the right refresh rate on first run.

MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch a3d81ee59dbfca8aa5d247e9398e58059e2c4381 -a https://testufo.com

Seems like the issue is completely fixed with this!

Robert, how VsyncParent depends on WaylandVsyncSource ? Can we throw an error when VsyncParent is created without WaylandVsyncSource?

(In reply to Martin Stránský [:stransky] (ni? me) from comment #70)
> Robert, how VsyncParent depends on WaylandVsyncSource ? Can we throw an error when VsyncParent is created without WaylandVsyncSource?

Unfortunately `VsyncParent` lives in heavily shared code - will try to clean up the patch above and see if we can throw an error somehow (or just guarantee that `nsWindow::GetVsyncSource()` never returns `nullptr` when it shouldn't).

And where the connection happens?

(In reply to Martin Stránský [:stransky] (ni? me) from comment #72)
> And where the connection happens?

I'd have to dive into bug 1645528 again to remember all the details but IIRC once the content process creates a `BrowserChild`, a `BrowserParent` is created, which again, at least on Wayland, has a `VsyncParent` (the `BrowserChild` has a `VsyncChild`). That `VsyncParent` calls `GetVsyncSource()` on its Widget - in the case here the `nsWindow`.
Normally, if a tab gets moved to another window, the `VsyncSource` of the `VsyncParent` should get updated, but maybe that's not the case if the global software vsync source is selected.
In any case, what we see here is a race between a `VsyncParent` and the `WaylandVsyncSource` being created.

(In reply to Robert Mader [:rmader] from comment #68)
> Can somebody try the following build with the patch from comment 67? https://treeherder.mozilla.org/jobs?repo=try&revision=a3d81ee59dbfca8aa5d247e9398e58059e2c4381
>
> Edit: for me that build did pick up the right refresh rate on first run.

Yes! This fixes it for me.
It works on the first and subsequent runs. Moving the window between a 180hz monitor and a 60hz monitor is also detecting the FPS change perfectly.

Is a backport to 95 or 96 planned? Currently it's a pretty bad experience for anyone using Firefox on Wayland.

(In reply to nf.pereira from comment #74)
> Yes! This fixes it for me.

Great, thanks for confirming!

> Is a backport to 95 or 96 planned? Currently it's a pretty bad experience for anyone using Firefox on Wayland.

Assuming the patch lands soon: definitely 96. 95 depends on whether there will be a point release. In any case it should be easy to backport if distro maintainers want to.

Oh that's great! I was afraid it was only going to drop in 97.

*** Bug 1740255 has been marked as a duplicate of this bug. ***

(In reply to Robert Mader [:rmader] from comment #73)
> In any case, what we see here is a race between a `VsyncParent` and the `WaylandVsyncSource` being created.

So can we put an assertion there to make sure the things are correct? Because in this patch we just moved WaylandVsyncSource creation to a different place but the race can still happen.

Pushed by <email address hidden>:
https://hg.mozilla.org/integration/autoland/rev/81d5e47ce2e0
Create WaylandVsyncSource on window creation, r=stransky

(In reply to Martin Stránský [:stransky] (ni? me) from comment #78)
> (In reply to Robert Mader [:rmader] from comment #73)
> > In any case, what we see here is a race between a `VsyncParent` and the `WaylandVsyncSource` being created.
>
> So can we put an assertion there to make sure the things are correct? Because in this patch we just moved WaylandVsyncSource creation to a different place but the race can still happen.

I don't think the race can still happen - IIUC the `BrowserParent` is only created after `nsWindow::Create()` was called. If that's not the case, we'd need to rework much bigger parts of the code. Regarding the assertion: the only place where we know if we actually should get a `WaylandVsyncSource` is in `nsWindow` - can't check that in `BrowserParent` or `VsyncParent`.

Did we ever find out where the 120hz value was coming from? None of my screens is set to 120hz.

(In reply to nf.pereira from comment #81)
> Did we ever find out where the 120hz value was coming from? None of my screens is set to 120hz.

Uh, it might be 2*60Hz. In that case it should be still be reproducible with the patch landed and `widget.wayland.vsync.enabled:false`.

https://searchfox.org/mozilla-central/source/dom/ipc/VsyncParent.cpp#23-37 looks like it could mess up if called with `aVsyncSource == nullptr` multiple times - which AFAIK can only happen on Wayland (https://searchfox.org/mozilla-central/source/dom/ipc/BrowserParent.cpp#1436-1438).

So when triggering the race (i.e. without the patch from above and after trying a couple of times) I can manage to get Firefox into all kinds of odd vsync states. In a setup with one 60Hz and on 120Hz display, testufo.com (less heavy than vsynctester) sometimes gives 90FPS, sometimes ~108, sometimes 60 (on the 120Hz display).
Trying with a build with the patch applied (i.e. ~nightly from tomorrow), I reliably get the right refresh rates*. Also setting `widget.wayland.vsync.enabled:false` does not trigger the bug again, but instead gives me solid 60FPS.
So without digging deeper I assume what we see here something that can only happen in a mixed state where some components use `WaylandVsyncSource` and others `SoftwareVsyncSource`. And the patch should avoid that.
I also looked into `VsyncParent` again but couldn't find anything really wrong. Thus declaring this fixed once the patch lands.

*: note: this is with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2169 applied to not get wrong frame callbacks from Mutter.

https://hg.mozilla.org/mozilla-central/rev/81d5e47ce2e0

Comment on attachment 9256101
Bug 1744896 - Create WaylandVsyncSource on window creation, r=stransky

### Beta/Release Uplift Approval Request
* **User impact if declined**: Native Wayland backend users may get wrong refresh rates and stuttering, in some cases strongly affecting the user experience.
* **Is this code covered by automated tests?**: No
* **Has the fix been verified in Nightly?**: No
* **Needs manual test from QE?**: No
* **If yes, steps to reproduce**:
* **List of other uplifts needed**: None
* **Risk to taking this patch**: Low
* **Why is the change risky/not risky? (and alternatives if risky)**: The code change is quite simple and well understood.
A previous version of the patch has already been tested by affected users and the final one by me. Once the patch lands in nightly it should be confirmed again - opening the uplift request already to increase the chance it gets in before people are offline.
* **String changes made/needed**:

*** Bug 1745098 has been marked as a duplicate of this bug. ***

*** Bug 1741613 has been marked as a duplicate of this bug. ***

Comment on attachment 9256101
Bug 1744896 - Create WaylandVsyncSource on window creation, r=stransky

Approved for 96.0b9

https://hg.mozilla.org/releases/mozilla-beta/rev/620f6d66f586

Martin, given that it's still three weeks until FF96 will be available on Fedora and this probably affect quite a few users (even not necessary strongly enough to create more duplicate bugs), do you think you could spin up a new build there?

I assume there won't be an official 95 dot release anymore - and even if it will, I don't want to create more work for the sheriffs, given that this is Wayland only and thus unsupported.

I don't have any reports from Fedora so I may wait to 96.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #91)
> I don't have any reports from Fedora so I may wait to 96.

Just so you know: I'm on Fedora 35 and now that I have a high refresh rate monitor it is very easy for me to reproduce the issue with the current distro build. And heavy stuttering was also confirmed to happen on Fedora 35 in bug 1745098 comment 11. So I assume there must be some users out there for whom it makes quite a difference - while also not being critical :)

> I assume there won't be an official 95 dot release anymore - and even if it will, I don't want to create more work for the sheriffs, given that this is Wayland only and thus unsupported.

Hm, is there a beta channel for the Flathub Firefox? Otherwise I guess I'll stick to 94 until 96 is out.

Okay, I'll do Fedora respin then.

(In reply to Ivan Molodetskikh from comment #93)
> Hm, is there a beta channel for the Flathub Firefox? Otherwise I guess I'll stick to 94 until 96 is out.

Yes, fortunately there is: `flatpak remote-add flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo`

(In reply to Martin Stránský [:stransky] (ni? me) from comment #94)
> Okay, I'll do Fedora respin then.

Thank you!

(In reply to Martin Stránský [:stransky] (ni? me) from comment #94)
> Okay, I'll do Fedora respin then.

I'm also on Fedora 35. Have been working around it by setting layout.frame_rate to 144 - but it would be nice to have this patch applied in the distro build :)

(In reply to Jon Voss from comment #96)
> (In reply to Martin Stránský [:stransky] (ni? me) from comment #94)
> > Okay, I'll do Fedora respin then.
>
> I'm also on Fedora 35. Have been working around it by setting layout.frame_rate to 144 - but it would be nice to have this patch applied in the distro build :)

I have been doing the same. It's not perfect, as it's not proper Vsync and it stutters a lot, but it makes it bearable until 96 drops.
I'm more worried about the users that don't know how to fix it and will be stuck with incorrect frame-rate and terrible stutter during the 95 stable.