Sway: Feature request: config option to disable primary-selection (clipboard) protocol

[jaimet]

Feature request: I'd love some config option that would completely disable the primary-selection protocol message proxying that sway does. I've just asked on IRC if anything like this already exists, and Kenny Levinson kindly informed me that this isn't configurable at the moment, hence this feature request.

If you need any more info, please let me know. TIA, J

PS I've just found https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection which says "Constraints for a Wayland primary selection: We should address the security concerns by making sure that the feature is off by default and has to be enabled by the user". I appreciate that it's a different DE, but the point is interesting nonetheless.

[emersion]

Why do you want to disable it?

[jaimet]

Because I don't like it (Richard Feynman's explanation may help)

[emersion]

Then don't use it

[jaimet]

Ha ha! Brilliant! Ok, I'll take that as a "This is not going to be implemented".

[emersion]

If you can give a sensible reason to allow users to disable it, then I'll reconsider. If the reason is just "I don't like it", then no.

[jaimet]

Ok, I'll try. (I'm not sure that I understand exactly what your criteria are for a "sensible reason", but I won't let that hold me back!)

Firstly, I often select stuff to make it stand out on the screen, and I don't want "the system" to store that selection because I think that's a security vulnerability. For example, "Hey, Joe, what do you think about this really sensitive word on this page, yeah, I'll select it so that you can see which sensitive word I'm talking about. Shit - now that I've selected it to show it to you, the system has recorded that sensitive word in primary, dammit! But I don't want that sensitive word hanging around in primary, so now I need to select something else and then verify that the second selection has replaced the sensitive word. Arghhhh."

Secondly (related to the first, but not the same), there's the higher "active threshold requirement" (I just made that up) of copying into the clipboard than there is to copy into primary. I don't want the "system" to remember things just because I selected them - I want to "have to" select and then do something before the system copies the selection.

Lastly, there's the idea of having 2 independent buffers (primary and clipboard) which is a blessing to some, but has been a curse to me. Depending on what I'm doing, this is somewhere slightly beyond my cognitive threshold, so sometimes I forget what is in each and I end up pasting the wrong one, at which point I have been known to search google for the 8-random-character-string that is my login-password. Great.

Does any of this sound suitable?

[emersion]

Firstly, I often select stuff to make it stand out on the screen, and I don't want "the system" to store that selection

This is not how it works. When you select something, nothing happens. When you middle-click, the data transfer begins.

Lastly, there's the idea of having 2 independent buffers (primary and clipboard) which is a blessing to some, but has been a curse to me

Addressed by not using the feature.

[jaimet]

This is not how it works. When you select something, nothing happens. When you middle-click, the data transfer begins.

Ok, now I'm even more confused. If I:

1) select some text
2) left-click somewhere else so that the text is no longer selected
3) middle-click

then the text (that is no longer selected) is pasted. But you said "When you select something, nothing happens". If, when you select something nothing happens, how does the system know what to paste?

[l3s2d]

@emersion I'd like this option as well. The main reason is that I use middle-click to scroll and end up pasting various things (sometimes sensitive) I have highlighted. I highlight text as I read or when I want to delete multiple lines.

@jaimet This post is about X11, but should answer your question about when the data transfer occurs. The underlying system doesn't copy the selection to a buffer, instead the application itself remembers what was highlighted. If you close the application the selected text won't be available to paste anymore.

[jaimet]

Hey, I've just discovered:

gsettings set org.gnome.desktop.interface gtk-enable-primary-paste false

This might help (me!)...

[jaimet]

@emersion wrote

Then don't use it

I've just re-read this, and I've realised that I don't understand what it means. When you say "Don't use it", do you mean "Don't select" or do you mean "Don't middle-click" (or perhaps something else)?

[emersion]

Don't middle-click.

[HolyStephano]

Sorry for the potential necro, but i'm also in favor of this. Currently using a laptop, and trying to setup gestures with libinput-gestures, but a swipe down with 3 fingers sometimes registers as a middle click, pasting my entire primary selection (which sometimes includes like 90% of my terminal because of a touch screen) into a terminal, IRC, etc. An option to disable this would both be relevant to an issue like mine, as well as allowing people that don't want it to turn it off.

[rwanyoike]

Also in favor of this. Using a touchpad, I sometimes mistakenly middle click when scrolling with two/three fingers. Same thing with a clickable scroll wheel - I sometimes mistakenly middle click when scrolling. Those middle clicks paste the clipboard, modifying textareas, or flooding the terminal, etc -- it can get frustrating. If there was a way to turn off the middle-click paste function in sway...

[emersion]

Have you tried input * middle_emulation disabled?

[rwanyoike]

Yes, I've tried that, both as a sway config:

$ cat ~/.config/sway/config | grep -C5 middle_emulation                                                                                         ~/SRC/gro CLEWS-10432-migrate-to-python-5 +
input * {
  xkb_options caps:escape

  drag disabled
  dwt enabled
  middle_emulation disabled
  natural_scroll enabled
  tap enabled
}

and even manually with swaymsg:

$ swaymsg input \* middle_emulation disabled

doesn't stop the middle clicks / pastes from happening (touchpad or mouse)

$ sway --version
sway version 1.4

```
$ swaymsg -t get_inputs
...
Input device: USB Optical Mouse
Type: Mouse
Identifier: 6127:24622:USB_Optical_Mouse
Product ID: 24622
Vendor ID: 6127
Libinput Send Events: enabled

Input device: SYNA2393:00 06CB:7A13 Touchpad
Type: Touchpad
Identifier: 1739:31251:SYNA2393:00_06CB:7A13_Touchpad
Product ID: 31251
Vendor ID: 1739
Libinput Send Events: enabled
...

[EXL]

Also in favor of this. Things should be configurable. I've messed up my typed text and source code on my laptop several times due to this feature.

BTW, middle mouse button insertion cannot be disabled in X.Org also and people are forced to use such terrible solutions to remove this interfering functionality: https://askubuntu.com/a/4644

Please reopen issue. That problem is exist and annoying.

[mschilli87]

I also would like to see that config option.
Could you maybe indicate if you are just not willing to put in the work to implement it, but a PR would be accepted, or if you are against having this feature in Sway? In other words: If it existed, would you open an issue to remove it?

[fluix-dev]

Write a patch and see what happens, if it doesn't get accepted keep it in a fork or submit it to another fork.

[mschilli87]

There is a huge difference between upstreaming a patch to add a new feature or maintaining a fork.
That's why I ask. To me so far it seems like there is no interest in this feature from the developers but several users would love to see it. There have been attempts to exlain the advantages of the feature but they have been pretty much discarded by a 'just live with it' kind of reply. If there is no interest, that's fine. I won't waste time on it and either live without the feature or look for a 'better' (read: fullfilling my needs - for free, without me doing anything for it - more) compositor. If I can't find any, that's my problem. Either I write my own or I accept I won't alwyas get what I want. The decision should come with the maintainer burden IMHO. And am not willing to take that. So the fact that I want the feature does not really matter. If the only thing stopping this feature is the implementation burden though, I (or some other user interested in this feature) should give it a shot instead of just complaining that we don't have it our way without contributing. :wink:

[fluix-dev]

There is a huge difference between upstreaming a patch to add a new feature or maintaining a fork.

Correct, the latter is much easier. Sway is a very comprehensive compositor and I bet that there's many features some people want config options for. That's great, but it also means that for a patch to get accepted is has to be part of an entire framework (similar to the security config for example) to get accepted, and then individual config options may be built off that.

Maintaining a fork (or even a single patch file) isn't that difficult, especially with a feature that's only found in 15 lines of code (grep -r "primary_selection"). Here's a super simple patch:

diff --git a/sway/input/seat.c b/sway/input/seat.c
index e16d747cf..96c928c0e 100644
--- a/sway/input/seat.c
+++ b/sway/input/seat.c
@@ -504,14 +504,6 @@ static void handle_request_set_selection(struct wl_listener *listener,
        wlr_seat_set_selection(seat->wlr_seat, event->source, event->serial);
 }

-static void handle_request_set_primary_selection(struct wl_listener *listener,
-               void *data) {
-       struct sway_seat *seat =
-               wl_container_of(listener, seat, request_set_primary_selection);
-       struct wlr_seat_request_set_primary_selection_event *event = data;
-       wlr_seat_set_primary_selection(seat->wlr_seat, event->source, event->serial);
-}
-
 static void collect_focus_iter(struct sway_node *node, void *data) {
        struct sway_seat *seat = data;
        struct sway_seat_node *seat_node = seat_node_from_node(seat, node);
@@ -584,11 +576,6 @@ struct sway_seat *seat_create(const char *seat_name) {
                &seat->request_set_selection);
        seat->request_set_selection.notify = handle_request_set_selection;

-       wl_signal_add(&seat->wlr_seat->events.request_set_primary_selection,
-               &seat->request_set_primary_selection);
-       seat->request_set_primary_selection.notify =
-               handle_request_set_primary_selection;
-
        wl_list_init(&seat->keyboard_groups);
        wl_list_init(&seat->keyboard_shortcuts_inhibitors);

Works, but not tested extensively.

[mschilli87]

@TheAvidDev: Thank you for your effort but without getting the feature upstream I am not interested.
I want to keep the same workflow at home and at work were I do not get root permissions. I can ask the IT team to install a package for my distribution, but I can't bother them applying custom patches.
This feature is also really more a nice-to-have. I just fail to comprehend the aversion against it.
The two possibilies I could come up with are a) too low priority to bother implementing (does not appear to be the case judging by you promt suggestion of a patch) or b) lack of interest due to the feature beeing considered too specific to justify the 'bloat' it would cause (still not sure if this was the reason to close and never re-consider this though various people argued in its favour).
But I am happy my inquiring resulted in a potential solution for others before I even commited to looking at the code. :wink:

[fluix-dev]

This feature is also really more a nice-to-have.

You said you are looking for a new compositor because this feature is missing?

I just fail to comprehend the aversion against it.

It's because, as you said, this feature is too specific. The better solution is to compile a list of all "configurable" options like this and setup some larger framework.

But I am happy my inquiring resulted in a potential solution for others before I even commited to looking at the code.

No problem, I'm happy others may find it useful.

[emersion]

I've yet to find an explanation of why users cannot just stop using middle-click. I don't find explanations like "Sway should be configurable" or "I hit it by accident" very compelling.

[Geo25rey]

@emersion Middle click in certain apps have functionality, such as in web browsers middle clicking a link opens the link in a new tab. This can lead to conflicts/race condition if also in a text field. Perhaps it would make more sense that copy and paste are commands that can be bound to any key combo with the default config having it bound to middle click.

[mschilli87]

@emersion:

I don't find explanations like [...] "I hit it by accident" very compelling.

Well, maybe you are simply better than everyone else and/or lack a certain degree of empathy:
It does happen to me and apparently others as well andI can relate to several reason why pasting something nobody ever inteded to even be copied could be undesired, even those that don't apply to myself.

One solution to please different people comes down to this:

"Sway should be configurable"

:wink:

PS: Please do not take this personal, I am simply trying to help you understand and I will value your contributions to free software making my life better regardless of if you agree or not. Personally, I am fine with the explanation @TheAvidDev gave.

[l3s2d]

I just want to reiterate my reason:

I use a laptop with a pointing stick. To scroll, I need to hold down the middle click button and move the pointing stick. If I hold/press middle click with the intention of scrolling but then I don't end up moving the pointing stick at all (maybe I changed my mind about scrolling) it will paste. This is happens a few times a day for me.

I don't have the option of not middle-clicking in this case.

[ellbur]

Hey, I've just discovered:

gsettings set org.gnome.desktop.interface gtk-enable-primary-paste false

This _might_ help (me!)...

This worked for me, thank you.

[yuxuanchen1997]

First of all, I am a new user to sway, thanks for working on this fantastic project. Regarding this request, I am also in favour of this.

I've yet to find an explanation of why users cannot just stop using middle-click. I don't find explanations like "Sway should be configurable" or "I hit it by accident" very compelling.

Just letting you know, there's a class of devices like the ThinkPad TrackPoint Keyboard that relies on clicking the middle-key to scroll. However, quite unfortunately, without this middle-click copy-paste behaviour disabled, copy/paste happens whenever the user tries to begin scrolling.

Meanwhile, the main reason I use a tiling window manager (and even more, Desktop Linux) is being able customize my GUI experience into my habit with which I can be less distracted and more productive. IMHO more options here isn't a terrible thing to have as long as there's sane default that works for most users. If any of us here comes up with a patch, would you please see merging that as an option?

Thank you so much again for working on this fantastic project.

[wmww]

gtk-enable-primary-paste false does not seem to effect Qt apps or Firefox. I have 3-finger middle click enabled on my touchpad which I use for opening things in new tabs, but it can accidentally activate while scrolling. Since I have never intentionally used primary selection and don't plan to, being able to disable it would be quite nice.

[emersion]

For some time I've been considering accepting a patch to disable primary selection altogether. However I'm concerned about a few limitations:

• We don't want to expose the primary selection global when disabled, to allow apps to use middle-click for another action
• Clients won't cope with the primary selection global disappearing
• Thus a primary selection config option can only be set in the config and will be ignored on reload

This isn't unheard of: for instance, the xwayland config options works like this too. This can confuse users though, leading to bug reports like "config option not taken into account on reload".