Copying to clipboard while xfreerdp is running but unfocused hangs Sway

[oliversturm]

• Sway Version: 1.6-85291411 (Apr 23 2021, branch 'master')

• Debug Log:

...
00:24:46.745 [DEBUG] [wlr] [types/data_device/wlr_data_source.c:189] Offering additional MIME type after wl_data_device.set_selection
00:24:46.745 [DEBUG] [wlr] [xwayland/selection/incoming.c:486] XCB_XFIXES_SELECTION_NOTIFY (selection=276, owner=2097153)
00:24:46.746 [DEBUG] [wlr] [xwayland/selection/outgoing.c:375] XCB_SELECTION_REQUEST (time=0 owner=2097153, requestor=20971521 selection=276, target=278, property=438)
00:24:46.746 [DEBUG] [wlr] [xwayland/selection/outgoing.c:416] denying read access to selection 276 (CLIPBOARD): no xwayland surface focused
00:24:46.746 [DEBUG] [wlr] [xwayland/selection/outgoing.c:26] SendEvent destination=20971521 SelectionNot
ify(31) time=0 requestor=20971521 selection=276 target=278 property=0
00:24:46.746 [DEBUG] [wlr] [xwayland/selection/outgoing.c:375] XCB_SELECTION_REQUEST (time=0 owner=209715
3, requestor=20971521 selection=276, target=278, property=438)
00:24:46.746 [DEBUG] [wlr] [xwayland/selection/outgoing.c:416] denying read access to selection 276 (CLIP
BOARD): no xwayland surface focused
00:24:46.746 [DEBUG] [wlr] [xwayland/selection/outgoing.c:26] SendEvent destination=20971521 SelectionNot
ify(31) time=0 requestor=20971521 selection=276 target=278 property=0
00:24:46.746 [DEBUG] [wlr] [xwayland/selection/outgoing.c:375] XCB_SELECTION_REQUEST (time=0 owner=209715
3, requestor=20971521 selection=276, target=278, property=438)
...

• Description:

I had trouble before where Sway seemed to be non-responsive for a while - jerky mouse movement, slow reaction to keyboard, etc - and these problems seemed to occur most of the time when I had just copied something in Firefox. This time I was running Sway with -d and again I copied a URL in Firefox (running on Wayland). Suddenly the machine froze - worse than usual. After a while I managed to switch to a (VT) console and check the log file. By this time I had accumulated around 3.5GB of the same lines I pasted above - they repeated endlessly. I had just one Xwayland client running (xfreerdp) so I simply killed Xwayland and the problem went away immediately.

I should mention that xfreerdp was running on an invisible workspace when the problem occurred.

One additional note: it is possible that this issue is related to the specific formats Firefox adds for the clipboard content. I can't swear to it, but I think I have seen the problem almost exclusively when I copy from Firefox. I also use Vimium in Firefox, and I think the problem has never occurred when I use Vimium's "yank URL to clipboard" function instead of copying from the URL field in Firefox. I hope this information is useful to someone.

[emersion]

Are you using a clipboard manager?

Please attach a full debug log, and your config file.

[oliversturm]

I am not using a clipboard manager. Hey, I'm a stickler for process, but what good is 4.5GB of debug log going to do, or my config file?

[oliversturm]

Alright, I managed now... reproduced the problem - apparently it happens every time. Only the behavior is not exactly the same every time. In this case I did not notice the machine freezing the way it often does, but when I checked the log file, I saw that the same output was pouring in as before.

This is my config file

Here is the compressed logfile. It "only" has 220MB this time, uncompressed, but that still seemed rather large for pastebin.

These are the steps I took this time:

• Started Sway
• Opened a terminal
• Ran xfreerdp
• Moved it to an invisible workspace
• Ran Firefox
• Copied a URL in Firefox
• Checked the logfile - yep, endless clipboard errors scrolling through
• Exited Sway

[oliversturm]

Since I was on a roll with this <g>, I decided to check things out a bit more. I found that the issue seems to be specific to xfreerdp and its clipboard handling. I can work around this now I know what's going on - I'll leave it to others to decide whether the bug report still has merit or should be closed.

[Xyene]

Thanks for the details. As you've mentioned, this is an xfreerdp issue. It shouldn't be requesting clipboard contents when it's not focused. I wouldn't go so far as to say it's an xfreerdp bug since X11 does allow this, but Sway doesn't (and won't).

Locally, you could probably work around this by removing this block of code:

https://github.com/swaywm/wlroots/blob/master/xwayland/selection/outgoing.c#L413-L420

Some things worth checking:

• When the issue occurs and you switch to a different VT and kill xfreerdp, does the Sway session become usable again?
• What does ls /proc/$(pidof sway)/fd | wc -l show before, during, and after reproducing the issue? We shouldn't be leaking pipes.

[meklonets]

I can confirm this "xfreerdp+firfox+copy" issue.
Xwayland begins to eat processor for 100%.

[oliversturm]

Short update. I am not encountering this issue anymore now, and I believe it's because I started using wlfreerdp instead of xfreerdp. I had tried this previously, but wlfreerdp always exhibited strange behavior on Sway (grabbing keys so I couldn't switch workspaces anymore) - now I found that if I use Remmina as a frontend, I don't have these problems and I don't need to rely on Xwayland for xfreerdp. In case anybody is reading this thread on the search for a workaround, I hope this helps.

When the issue occurs and you switch to a different VT and kill xfreerdp, does the Sway session become usable again?

I have not tried this specifically, I killed the entire Xwayland session - which made Sway usable again.

I'll try to find some time to conduct a special test and answer your questions.

[meklonets]

Is there any plans to fix this issue? The is really annoying thing with Xwayland hanging the sway while working.
On other hand I would love to use wlfreerdp, but its much slower then xwayland.

[emersion]

Is there any plans to fix this issue?

Patches welcome.

[meklonets]

Unfortunately I have no any coding skills, but I love linux, swaywm and my job has valuable amount of time of administrating windows servers via rdp. And I understand and totally appreciate your work.
I'm extremely into swaywm but hard times with Xwayland hang the work process.
The issue indeed is about one year I guess.
I'm praying you or some skilled user fix this. :)

[Xyene]

Is there any plans to fix this issue?

This isn't really on our end to fix. (Well, it's unfortunate that a misbehaving client can hang Sway, and maybe we should throttle them, but that's a larger issue than the one at hand.)

We could allow unfocused Xwayland applications to read the Wayland clipboard, which would fix this. If this is blocking your work, you can do so locally just by deleting this code and recompiling.

I don't have strong feelings on whether we should actually do this. Certainly someone else did when they wrote that check in the first place.

Another alternative is to not notify the requestor that they're not going to receive clipboard contents and let them time out, by replacing this line with a return;. This is untested and I don't know if it wouldn't break xfreerdp in other ways.

Yet another alternative is to fix xfreerdp to not be so aggressive about retrying. It looks like if it sees a None response (which we send when we deny the access, as per what the spec implies), it immediately retries obtaining the selection:

https://github.com/swaywm/wlroots/blob/84dea55b20b60c229a5e31ccd37b58c96cba611a/xwayland/selection/outgoing.c#L23

https://github.com/FreeRDP/FreeRDP/blob/892cbe32610a965e7e0cdadc02c01e8b34b38c96/client/X11/xf_cliprdr.c#L954

https://github.com/FreeRDP/FreeRDP/blob/892cbe32610a965e7e0cdadc02c01e8b34b38c96/client/X11/xf_cliprdr.c#L1318-L1323