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.

  • 𝘋𝘪𝘳𝘬
    link
    fedilink
    586 months ago

    When you need a proxy between your application and your graphics server then something fundamental went wrong long before.

  • aard
    link
    fedilink
    356 months ago

    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.

    • @drwankingstein@lemmy.dbzer0.com
      link
      fedilink
      English
      22
      edit-2
      6 months ago

      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

      • @woelkchen@lemmy.world
        link
        fedilink
        86 months ago

        the program becomes very slow and not very responsive

        BeOS solved the issue of unresponsive GUIs in the 1990s. The GUI just must never run in the same thread as the logic.

        • @drwankingstein@lemmy.dbzer0.com
          link
          fedilink
          English
          56 months ago

          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

          • @woelkchen@lemmy.world
            link
            fedilink
            -16 months ago

            My PC with a 133MHz Pentium 1 processor was pretty responsive all the time back in the day. It’s definitely a solved problem.

      • aard
        link
        fedilink
        6
        edit-2
        6 months ago

        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? https://gitlab.freedesktop.org/wayland/wayland/-/issues/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.

        • @drwankingstein@lemmy.dbzer0.com
          link
          fedilink
          English
          46 months ago

          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

          • aard
            link
            fedilink
            46 months ago

            I guess that explains why I’m not seeing it - my workstation has 64 threads and more than enough memory, and on my notebook I’m scheduling load intensive stuff to not interfere with interactive device usage.

  • exu
    link
    fedilink
    English
    96 months ago

    Interesting, Firefox did crash more often for me on Wayland, but I hadn’t dug into it further yet.
    Let’s see if this reduces crashing again.

  • @Scrath@lemmy.dbzer0.com
    link
    fedilink
    7
    edit-2
    6 months ago

    Personally I didn’t have any problems with that yet fortunately.

    My bigger problem right now is a bug that prevents me from copying stuff from the url bar when middle-click pasting is disabled in the KDE settings…

    In X11 the bug doesn’t exist

    • @Exec
      link
      76 months ago

      My bigger problem right now is a bug that prevents me from copying stuff from the url bar when middle-click pasting is enabled in the KDE settings…

      What. For me it’s the opposite - I can’t copy stuff to other apps from Firefox if that setting is not enabled

      • @Scrath@lemmy.dbzer0.com
        link
        fedilink
        76 months ago

        Yeah sorry. I was half asleep while I wrote this. That is the problem I have as well.

        One workaround I found is to use the separate search bar (if you have it enabled) as a buffer.

        When I copy the URL I can paste it into the search bar but nowhere else. If I copy the search bar I can paste it everywhere just fine

        • @Exec
          link
          26 months ago

          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.

    • @1984@lemmy.today
      link
      fedilink
      1
      edit-2
      6 months ago

      Is this on Fedora? My girlfriend had lots of similar issues on Fedora that disappeared on pop os.

  • MentalEdge
    link
    fedilink
    36 months ago

    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.

    • aard
      link
      fedilink
      86 months ago

      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.

      • MentalEdge
        link
        fedilink
        4
        edit-2
        6 months ago

        Kwin. It works with xwayland, doesn’t with wayland, I’d love a solution, but I found nothing.

          • MentalEdge
            link
            fedilink
            16 months ago

            Doesn’t the window title change on firefox depending on tab or even web-page?

            • @zurohki@aussie.zone
              link
              fedilink
              English
              16 months ago

              Yeah, if you want certain pages in certain screens it would work, and then they’d stay there

              • MentalEdge
                link
                fedilink
                16 months ago

                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.

                Meanwhile forcing xwayland, just works.

  • AutoTL;DRB
    link
    fedilink
    English
    36 months ago

    This is the best summary I could come up with:


    Shipping as part of Firefox 121 is wayland-proxy as a C++ module to serve as a Wayland proxy load balancer.

    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.

    Martin Stransky with Red Hat wrote Wayland-Proxy as a C++ version of a prior proof-of-concept written in Rust.

    Wayland-Proxy can work either as a standalone application or a library called upon by Wayland apps.

    Those wishing to learn more about Wayland-Proxy and its Firefox use can see today’s post on Stransky’s blog.


    The original article contains 165 words, the summary contains 116 words. Saved 30%. I’m a bot and I’m open source!