Among the Firefox Wayland bugs, one of the top crash bugs is over a lost connection to a Wayland compositor. For dealing with it is to have a proxy between Firefox and the Wayland compositor to cache messages and prevent compositor message queue overflows.
Would be interesting if this is more on Firefox side, or on compositor side. I’ve been running Firefox in Wayland for about 9 months now, without any issues.
this is a wayland issue. Due to how wayland works, it cannot drop messages, this means if the messages stop being accepted (IE. the program becomes very slow and not very responsive) the application will wind up dying. EEVDF helped resolve a lot of these issues. but they arent gone yet.
a fairly easy replication cause is to start a large rust project compile since cargo will thread to oblivion if it gets the chance, then use the PC on wayland. Applications can frequently die, Firefox, MPV, Kate, gnome web, chromium, games, etc. it also doesn’t matter what compositor you use right now as gnome, kde sway all share the issue
EEVDF really does help stop a lot of these crashing though
You’re describing Wayland running into issues due to overall high system load, and not been given enough scheduler time to accept messages?
edit: This issue? gitlab.freedesktop.org/wayland/wayland/-/…/159 - didn’t find anything else matching the description, and personally have never seen that, both on my low specs notebook or my workstation, which probably counts as higher spec.
correct, this is the same issue, this generally really only happens with a sustained all core workload that will consistently leave you cpu at 100%, since if it’s not sustained, the kernel will allot some time to the programs, and the crash wont happen
I agree. The proxy solution they’re proposing seems like a band-aid on a fundamental design issue to me. It’s easier to just tack yet another library onto a big project than to refactor large amounts of code. This is exactly why a lot of software is getting more and more shit.
Also this is the kind of issues Wayland will be facing now that it’s starting to see widespread adoption, issues that arise from more and more complex situations created by interconnecting more apps with it in more ways.
How the devs handle this will be crucial and imo it can make or break the project in the long run. It’s one thing to successfully run a hobby project at a small scale, it’s another to shoulder the entire Linux desktop for the foreseeable future. That’s the bar that X had to meet; if Wayland intends to be the Linux desktop it has to step up. “Not our problem, deal with it outside Wayland” will not do.
while this is good on theory, when your CPU is being absolutely hammered, you need to re-adjust priorities to make a system responsive again, it’s actually not a simple thing to do without a context aware scheduler. Even though EEVDF is pretty good, it still struggles some times
Ah. For me it’s not the search bar only but also if I select text and press Ctrl+C/press context menu Copy as well.
Interestingly, if sites put something in the clipboard (eg. Mastodon toot Copy link button) it works anywhere else.
I had to force it to run in xwayland because in wayland it no longer remembers window positions, so with wayland it was opening all my windows in a big pile on the current desktop, instead of putting them in the positions and on the desktops they belong.
That sounds more like a compositor problem - typically a client should not have control over where windows are placed, and that X11 allowed that got heavily abused with negative impact on UI. Wayland fortunately fixed that, so it is now up to the compositor where to place windows. Those can send hints, but the compositor is free to ignore them.
In your situation your compositor should remember where to stick the windows.
And if I ever browse away from that page and forget to return to it before closing firefox…
This has a million caveats and isn’t even close to a solution for how I use firefox. Each desktop has their own windows and I want them to stay there because the tabs open are relevant to that desktop.
Add comment