6 ms·

Worth pointing out that for the longest time, Firefox on Wayland was borking the clipboards regularly, forcing a restart of the whole stack (at least on Gnome).

by di4na 5y ago

Worth pointing out that for the longest time, Firefox on Wayland was borking the clipboards regularly, forcing a restart of the whole stack (at least on Gnome). That pushed a lot of people to use the X versin of firefox, even if on Wayland. It seems to be fixed for me now but eh... who knows

moritonal 5y ago
Which way around is that? Firefox would be unable to use it's Clipboard and require restarting, or Wayland would require restarting. If it's the later, would it not imply a shaky foundation if an app is able to brick the systems compositor with something as simple as clipboard access?
- jborean93 5y ago
  At least for me it would hang the app trying to retrieve the clipboard value that was set by Firefox. It would continue to hang until I either a) copied data from another app, or b) reloaded sway.
- boudin 5y ago
  In Wayland the data of the clipboard stays in the app where it was "added" to the clipboard and only transit between the application where it was copied to the app where it is pasted when pasted. I think the issue was at this transit stage on Firefox side. It didn't have any impact on the compositor, it would behave differently in the receiving app. Some would crash, some would freeze for a bit, some would be totally fine but would just fail to get the data to paste.
  - di4na 5y ago
    Yep exactly this
  - vidarh 5y ago
    > In Wayland the data of the clipboard stays in the app where it was "added" to the clipboard and only transit between the application where it was copied to the app where it is pasted when pasted. Back to the future... This was how the Amiga clipboard functionality worked (at that point it was because it saved memory), though you could push the data into separate clipboard storage if necessary (e.g. if an application was about to close while a clip was active, or because an application requested a paste).
    - TingPing 5y ago
      It's still a reasonable design, it even allows for passing around zero copy buffers, or streaming large data.
jborean93 5y ago
This was such a frustrating issue and was glad when it was finally fixed. My next bug bear is screen sharing on Wayland. I use a massive monitor and wlroots/sway (I have no idea where the functionality should lie) doesn’t really offer a nice way to share either a specific window or screen range. Chrome has a nice feature where you can share Chrome itself or a specific tab which somewhat mitigates this problem for me so it would be great if Firefox had the same ability. Ultimately it would be great if I could just share anything but the progress on https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/93 https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issue... is not quite there yet. I just wish I knew how the stack worked so I could potentially judge what the effort would be but I feel like it would he a massive rabbit hole which I just can’t afford.
- hansihe 5y ago
  This actually works somewhat today, but it's all a little hit and miss. For Wayland I believe the currently accepted way if doing screen sharing is through xdg-desktop-portal which has a backend for wlroots and a bunch of other common compositors. I have gotten this to work fairly decently with Firefox at least, but some things are a bit hacky. https://github.com/emersion/xdg-desktop-portal-wlr https://github.com/emersion/xdg-desktop-portal-wlr
  - jborean93 5y ago
    Thanks, I use this for sharing the screen but it only allows me to share a specific screen. It does not offer the ability to share a region [1] or specific window [2] on that screen. Supposedly this is due to API limitations in wlroots or some lower component. [1] https://github.com/emersion/xdg-desktop-portal-wlr/issues/154 https://github.com/emersion/xdg-desktop-portal-wlr/issues/15... [2] https://github.com/emersion/xdg-desktop-portal-wlr/issues/107 https://github.com/emersion/xdg-desktop-portal-wlr/issues/10...
- vbezhenar 5y ago
  I can share the entire screen using Discord/Chrome/Gnome 40/Fedora 34.
dont__panic 5y ago
Does Firefox default to Wayland these days on wayland-default distros? I seem to recall, using a Linux laptop for work just a year or so ago, that I had to set a couple of config variables manually that were really really easy to screw up. Ended up using the X version of FF for a while on Wayland until I figured out what was causing issues in my environment.
- Fronzie 5y ago
  Debian testing is currently still like that. MOZ_ENABLE_WAYLAND=1 needs to be set before firefox uses wayland.
- di4na 5y ago
  On Fedora at least yes, they try to default on Wayland for everything by default now
tinus_hn 5y ago
Why does Wayland allow an app to break its clipboard that badly?

by di4na 5y ago

moritonal 5y ago

Which way around is that? Firefox would be unable to use it's Clipboard and require restarting, or Wayland would require restarting. If it's the later, would it not imply a shaky foundation if an app is able to brick the systems compositor with something as simple as clipboard access?

jborean93 5y ago
At least for me it would hang the app trying to retrieve the clipboard value that was set by Firefox. It would continue to hang until I either a) copied data from another app, or b) reloaded sway.
boudin 5y ago
In Wayland the data of the clipboard stays in the app where it was "added" to the clipboard and only transit between the application where it was copied to the app where it is pasted when pasted. I think the issue was at this transit stage on Firefox side. It didn't have any impact on the compositor, it would behave differently in the receiving app. Some would crash, some would freeze for a bit, some would be totally fine but would just fail to get the data to paste.
- di4na 5y ago
  Yep exactly this
- vidarh 5y ago
  > In Wayland the data of the clipboard stays in the app where it was "added" to the clipboard and only transit between the application where it was copied to the app where it is pasted when pasted. Back to the future... This was how the Amiga clipboard functionality worked (at that point it was because it saved memory), though you could push the data into separate clipboard storage if necessary (e.g. if an application was about to close while a clip was active, or because an application requested a paste).
  - TingPing 5y ago
    It's still a reasonable design, it even allows for passing around zero copy buffers, or streaming large data.

jborean93 5y ago

This was such a frustrating issue and was glad when it was finally fixed. My next bug bear is screen sharing on Wayland. I use a massive monitor and wlroots/sway (I have no idea where the functionality should lie) doesn’t really offer a nice way to share either a specific window or screen range. Chrome has a nice feature where you can share Chrome itself or a specific tab which somewhat mitigates this problem for me so it would be great if Firefox had the same ability. Ultimately it would be great if I could just share anything but the progress on https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/93 https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issue... is not quite there yet. I just wish I knew how the stack worked so I could potentially judge what the effort would be but I feel like it would he a massive rabbit hole which I just can’t afford.

hansihe 5y ago
This actually works somewhat today, but it's all a little hit and miss. For Wayland I believe the currently accepted way if doing screen sharing is through xdg-desktop-portal which has a backend for wlroots and a bunch of other common compositors. I have gotten this to work fairly decently with Firefox at least, but some things are a bit hacky. https://github.com/emersion/xdg-desktop-portal-wlr https://github.com/emersion/xdg-desktop-portal-wlr
- jborean93 5y ago
  Thanks, I use this for sharing the screen but it only allows me to share a specific screen. It does not offer the ability to share a region [1] or specific window [2] on that screen. Supposedly this is due to API limitations in wlroots or some lower component. [1] https://github.com/emersion/xdg-desktop-portal-wlr/issues/154 https://github.com/emersion/xdg-desktop-portal-wlr/issues/15... [2] https://github.com/emersion/xdg-desktop-portal-wlr/issues/107 https://github.com/emersion/xdg-desktop-portal-wlr/issues/10...
vbezhenar 5y ago
I can share the entire screen using Discord/Chrome/Gnome 40/Fedora 34.

dont__panic 5y ago

Does Firefox default to Wayland these days on wayland-default distros? I seem to recall, using a Linux laptop for work just a year or so ago, that I had to set a couple of config variables manually that were really really easy to screw up. Ended up using the X version of FF for a while on Wayland until I figured out what was causing issues in my environment.

Fronzie 5y ago
Debian testing is currently still like that. MOZ_ENABLE_WAYLAND=1 needs to be set before firefox uses wayland.
di4na 5y ago
On Fedora at least yes, they try to default on Wayland for everything by default now

tinus_hn 5y ago

Why does Wayland allow an app to break its clipboard that badly?