Did you check if FF was actually running in wayland mode? Not trying to blame you, the current situation is pretty dire. The only reliable way of finding out if something is actually using wayland is running xeyes and seeing whether the eyes move above the target window.
In Firefox all you have to do is navigate to about:support and check verify that Window Protocol shows wayland.
Or running xlsclients
I started running into them pretty fast when I added a 4K monitor to my Ubuntu 22.04 system and enabled fractional scaling. All of my Wayland apps look fine, and all of my XWayland clients look awful, blurry and obviously scaled. Working one by one to switch them over to native Wayland has been a hassle for various random reasons, most notably:
* Slack: works from the icon in the taskbar, but when auto-started at login does so in X11 mode
* VS Code: works fine when run from Terminal, but when launched from taskbar icon shows up as a different "app" in the taskbar. Launching from the terminal starts in X11 mode
* Zoom: requires more setup in order to share screen. The Zoom UI for screen sharing doesn't work so it's not obvious how to stop sharing screen. It also freezes or crashes all the time for no discernable reason, including locking up when joining some meetings three times in a row and then succeeding on the fourth time.
So if you're not really leaning into what Wayland offers it works fine, but even just fractional scaling has been a four-month hassle to get things working as expected.
As you know, "native Wayland" means the app has been modified so that it can talk to the graphics hardware using the Wayland protocol.
Emacs is the hardest of my apps to persuade to talk Wayland protocol because Fedora's "emacs" package was compiled without the code that talks Wayland.
To persuade Chrome to talk Wayland protocol, I start it with specific command-line arguments, which used to cause bugs, but I haven't noticed any bugs for months.