wl-copy hangs indefinitely when ran from .desktop file
#168
Labels
cant-grab-focus
Compositor disallows stealing focus but does not support wlr-data-control
Comments
|
Hi! I can not reproduce this, it works as expected here: "Text from wl-copy_debug.sh" appears in the clipboard. You could try to make your script more verbose. For instance, add some logging before and after invoking Then see if anything appears in the journal. If nothing at all does, it likely doesn't even get run. If only the PID does, that likely means wl-copy is hanging, and you should be able to attach to it with GDB and see what it hangs on (in case you're not familiar with using GDB: run it like |
|
Running from the .desktop file, I get no output. Two processes are launched:
Running from the terminal, I get no output. The command hangs indefinitely, but the text is copied immediately in the clipboard. One process is launched:
|
|
One of your messages seems to have disappeared, but here's the interesting bit:
This means it's a case of
cant-grab-focus
If that's the case, there should be a proper startup token in the env that Mutter wants us to use to get focus. I went ahead and filed #169 to implement support for that. |
|
I have deleted my previous message because I had not correctly copied the command you asked me to try. I had done this instead: |
|
I have pushed a couple of commits that should hopefully help with this. Could you please build the latest wl-clipboard from source (with all the optional dependencies present, otherwise it won't have any effect!) and try this again? |
|
Sadly this didn't help. Result of Result of The weird thing is that I initially thought it helped, as I tested it in a VM first. But my issue was not reproducible there. The bug is present of two different machines, one on Fedora 37, the other on Arch Linux with GNOME. I could not reproduce the bug in a VM in Fedora nor Arch. I tried to reproduce it on some spare bare metal machines (one on Arch with KDE Plasma, the other on Fedora 37), thinking it could have something to do with my VMs, but I could not reproduce the bug either. |
|
As an aside, I just tried downgrading Mutter to version 43.3 on Arch Linux (it was previously on version 43.4), and it did fix the issue (with |
This is just a backtrace of bash waiting for Could you please get me
This is very interesting! So it might be this Mutter commit: https://gitlab.gnome.org/GNOME/mutter/-/commit/dac79fdceddb56293be39c087c68a36cf8cd6f37 |
|
Looks like this is indeed a regression introduced by that Mutter commit, and https://gitlab.gnome.org/GNOME/mutter/-/issues/2690 and https://gitlab.gnome.org/GNOME/mutter/-/issues/2739 are the relevant Mutter issues to follow. |
bugaevc
added
the
cant-grab-focus
|
Result of
Same, but with
|
|
Interesting — so As a side note, posting backlinks to here on Mutter's issue tracker is unlikely to help, since Mutter developers (rightfully) aren't interested in keeping the popup surface hack working. In a way, we're living on borrowed time with this already: some time (maybe in a couple of years, maybe sooner), Mutter developers will flip the switch and stop giving new windows focus ever (unless proper activation tokens are used), so wl-clipboard will stop working on Mutter entirely. A proper way out of this situation would be for Mutter to accept that yes, people will always want to access their clipboard from command line (and that it is not the same as external clipboard managers), to implement a better clipboard protocol that does not require the stealing focus hack while ensuring that this protocol is only exposed to unsandboxed clients (so security & privacy are maintained). But Mutter developers have made it clear that they're not interested in doing that either. |
|
Here is the output of Two processes are started: First one gives this in Second one gives this: |
|
hey, I have an issue where for example when ran in a terminal, you can see I start ╭─araly@computer /home/araly ‹system›
╰─$ time wl-copy aoeu ↵ 130
^C
________________________________________________________
Executed in 4.12 secs fish external
usr time 1.14 millis 346.00 micros 791.00 micros
sys time 0.01 millis 13.00 micros 0.00 micros
╭─araly@computer /home/araly ‹system›
╰─$found the issue while using I use mutter version 44.1 if relevant. Is this the same issue ? or should I create a new issue instead ? |
|
Please create a new issue, and make sure to specify more details about your system & attach |
it looks like I can recreate my issue in a specific terminal (guake) but not in another one (kitty) so I have to assume there's something going on with X and wayland. so just discard my comments |
|
I just faced the same problem, i think. I stumbled upon pass is not working correctly. ddterm is a dropdown-shell extension for gnome. The same, when i run from ddterm here it hangs and Gnome Dash shows this and the command finishes. Then the same is on wl-paste, but in gnome-terminal here the command hangs, and a icon in gnome-dash appears. The same as with wl-copy clicking on it, the command finishes with And gnome-notifications say "wl-copy is ready" |
|
My experience is exactly the same as described by @xundeenergie: When started from terminal, If it helps: I'm using |
Yeah, I have the same problem. A GNOME notification appeared when I ran 'wl-copy' from the terminal, and it hung until I clicked on it. I'm also on Arch with Gnome 45.1 |
|
i'm encountering a similar issue when calling here is the here is the library i use to spawn the process: hope it helps |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
wl-clipboardversion: 2.1.0OS: Arch Linux & Fedora 37
DE: GNOME 43
Running
wl-copyfrom the command-line or through a script works flawlessly. Runningwl-copyfrom a.desktopfile hangs indefinitely.This bug started happening a few days ago. I think I had a Mutter update recently, so this may be related. I am certain it was working previously on the same systems since I use
wl-copyinside a homemade script I run regularly.Steps to reproduce:
/usr/share/applications/wl-copy_debug.desktop/usr/local/bin/wl-copy_debug.shwl-clipboardshows up injournalctleither./usr/local/bin/wl-copy_debug.shfrom the terminal. The text is copied as expected.echo 'Text from the CLI' | wl-copyfrom the terminal. The text is copied as expected.The bug is not reproducible in Debian 11 with GNOME 3.38.5 nor Arch Linux with KDE Plasma. This makes me suspect the issue is tied to a Mutter update.
Could this be a change in API? Or a bug in Mutter? In any case, I have no programming skills, and I am incapable of understanding the root cause. Please let me know if I can help in troubleshooting in any way.
The text was updated successfully, but these errors were encountered: