Hacker News Reader

Comment by di4na | Hacker News Reader

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

View on HN

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/-/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.

My next bug bear is screen sharing on Wayland.

Exactly. Wayland is unusable for me on current Debian family distros because tools like Slack and Teams can't share screens properly and IME just about everyone now uses some tool like that for remote working. None of the other advantages matters much if I can't send essential communications without logging out and then starting a new X session first.

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

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/15... [2] https://github.com/emersion/xdg-desktop-portal-wlr/issues/10...

I can share the entire screen using Discord/Chrome/Gnome 40/Fedora 34.

Thanks, I can share the entire screen, I just want some way to share either a region of the screen or specific window. I have a hack that sets up a stream through the webcam but this is clunky and annoying to set up. Plus it means that the screen is shared as a webcam on messaging apps which doesn't always work too well (different people are highlighted as they talk). Sharing my entire screen isn't really that great as the resolution is 5120x1440 and it doesn't really display well for others.

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?

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.

> 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).

It's still a reasonable design, it even allows for passing around zero copy buffers, or streaming large data.

Yep exactly this

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.

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.

Debian testing is currently still like that. MOZ_ENABLE_WAYLAND=1 needs to be set before firefox uses wayland.

On Fedora at least yes, they try to default on Wayland for everything by default now

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

Reply on news.ycombinator.com