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.

[A-Cloud-Ninja]

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 explain 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: fulfilling 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 always 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. 😉

[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. 😉

[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 and I can relate to several reason why pasting something nobody ever intended 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"

😉

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

[badosu]

I'd like to see something like this in too, I often edit real-time collaborative documents in which any changes are committed as soon as performed.

Often I have text in my selection that is pasted whenever I middle-click a link in said document (to open in a new tab), I could attempt to just try and remember to never middle-click but that's not feasible. I am able to avoid for a long time but once in a while it happens and when that happens it's really high impact.

I've used xbindkeys in the past to workaround this but haven't found a suitable solution on Wayland+Sway.

PS: I found a workaround on firefox setting middlemouse.paste: false in about:config but I think this still illustrates that is not unfeasible to have use cases for this change.

[estownya]

In my case, I am using an external Lenovo Trackpoint Keyboard where you can scroll with the pointing stick while holding down the middle button (very handy if you don't have a mouse). However, it triggers the paste already while clicking the middle button in contrast to the laptop keyboard where a middle click is triggered only after releasing the button without having touched the point stick. Of course, the fault comes from Lenovo's side, but it might be that it is not possible for them to do it differently on an external keyboard.

[ejno]

This wl-clipboard command may be a workaround: wl-paste --primary --watch wl-copy --primary --clear
It watches the primary clipboard for changes and then runs a command to clear it. I exec it on startup in the Sway config.

Technically, if you really mash the mouse buttons you may be able to copy and paste something before it is cleared, but it works very well for me in practice.

[mdirkse]

For what it's worth, I'd really like to be able to disable the middle click entirely. My touchpad is such that I hit the middle button all the time when I mean to hit the left button, and it's really annoying. The gsettings workaround doesn't work for me.

[kittyinc]

I would also like to be able to disable the middle click entirely, half of the time, my touchpad falsely registers left clicks as middle button.

My right hand is screwed up so "not using it" is not an option for me, I DON'T want to use it but the darn thing keeps registering left clicks as middle clicks.

I don't have this QoL problem with other WMs/DEs.

[fluix-dev]

I think you may be able to disable middle clicking with libinput through either the MiddleEmulation and/or ButtonMapping options describe in the man page.

[stvsu]

I think you may be able to disable middle clicking with libinput through either the MiddleEmulation and/or ButtonMapping options describe in the man page.

It's possible to disable using ButtonMapping (which was my solution when using X), but afaik sway doesn't expose that API.

[kittyinc]

I think you may be able to disable middle clicking with libinput through either the MiddleEmulation and/or ButtonMapping options describe in the man page.

I know it can be done in X (xinput), however, to my understanding all libinput stuff is now handled by the compositor now.

I've looked everywhere and I can't find a way to pass this configuration to Sway.

[tukusejssirs]

I personally want to disable pasting on middle-click only, because:

1. I prefer to use Ctrl+V;
2. I use a Lenovo keyboard with TrackPoint, which has three mouse buttons (left, middle and right) and the scrolling is done by pressing the middle button moving the TrackPoint.

As for my second point, when I press the middle button and then unpress it without moving the TrackPoint, it will trigger a paste paste event.

Potential solutions workarounds

1. gsettings

When I had installed GNOME besides Sway, I used gsettings set org.gnome.desktop.interface gtk-enable-primary-paste false and it worked, however, recently I reinstalled my system and I try to ditch GNOME (I haven’t used it for a very long time), therefore now I don’t want to use gsettings at all.

2. xbindkeys

It does not work for me.

3. Clearing primary clipboard

As @ejno suggested in his comment, we can add exec wl-paste --primary --watch wl-copy --primary --clear into our Sway config. This works quite well, but still I consider it a workaround, as no one can be sure it’ll always work.

4. Modify Sway source code downstream

As @fluix-dev suggested in his comment, we can remove the handle_request_set_primary_selection() function definition two other places where this function is being called (in wl_signal_add() and seat->request_set_primary_selection.notify). I haven’t tested this, but it seems to work. From my point of view, it would be good enouch to let us configure Sway to disable these from Sway config, although IMHO it does not actually remove primary selection protocol.

---

Does anybody know how to disable middle-click paste DM-agnosticly? Like globally in Wayland?

---

Update: Added points 3 and 4 above.

[kittyinc]

Does anybody know how to disable middle-click paste DM-agnosticly? Like globally in Wayland?

As far as I know and please correct me if I'm wrong, libinput is in charge of trackpad/mouse configuration.

For Xorg, this is done via xinput and 40-libinput.conf

But for Wayland this is configured directly by the DE, WM, Compositor etc; As far as I know, the only way to change it would be for Sway to provide a configuration option.

[tukusejssirs]

Thanks, @psheljorde! I hope @emersion will change his mind and let us disable this IMHO unnecessary shortcut, as we can paste using Ctrl+V or even Shift+Ins or one could create custom shortcut / key binding if they wish. And it provides bad UX for TrackPoint users for pasting while scrolling.

[emersion]

In #4511 (comment) I said I wouldn't be against a patch for this, given we properly figure out all of the implications.

[tukusejssirs]

Oh, sorry I missed that comment.

Anyway, I personally:

• don’t care if the middle click can be assigned to another action (I use keyboard shortcuts);
• want to disable middle-click paste once and for all (therefore I don’t need to be able to change to setting at runtime);
• want to use TrackPoint without accidently pasting the clipboard content, which happens to me way too often (at least 5-10 times a minute).

---

Update: This comment above reminded me that I also use middle-click in web browsers and I would really miss it. I am frustrated when I need to use Ctrl+left-click on MS Windows where middle-click does not open the link in a new tab (it does nothing). But that said I could sacrify this in order to disable middle-click pasting.

[emersion]

This has been implemented in #7312

[tukusejssirs]

Unfortunately, it does not work as intended/expected. Whenever I select any text and then press the middle button, the text is inserted.

I tested this with the latest version (1.9-dev-c32a5073). I have set primary_selection to disabled, restarted my computer (just to be sure). It worked for a while (a few minutes), then it stopped working. Ten I tried to restart my computer again just to see if the issue will be mitigated only to see it does not work at all (not even right after Sway start).

Note that until this feature was implemented, I used exec wl-paste --primary --watch wl-copy --primary --clear and it mostly worked (occasionally for a short period of time, a few seconds to couple of minutes, it failed to work, then it worked again). Therefore I still need to used tha wl-paste command, as the latest Sway version does not work as expected.

Note that it works in (all apps are running in Wayland, exceptions are noted):

• Alacritty;
• ElecronMail (ProtonMail Electron wrapper);
• Telegram;
• Discord (XWayland);
• Portmaster;
• Todoist (Xwayland);
• Mailspring (XWayland);
• Slack;

but does not work in:

• Sublime Text;
• Firefox Nightly.

---

Is there any way I can provide some logs or anything in order to fix this please? In Sway log (console output with --debug) does not say anything about the primary clipboard, except that it is loaded (and thus primary_selection is correctly disabled).

[emersion]

Could be due to wlr_xwayland unconditionally calling xwm_selection_init(&xwm->primary_selection, xwm, xwm->atoms[PRIMARY]).

[tukusejssirs]

More issues:

• when I reload Sway, it fails when primary_selection is enabled. I understand I cannot enable primary_selection when reloading Sway config, however, when it is already enabled, it should not fail. I understand that primary_selection.c (L15-L18) should handle this, but it does not work;
• even when I run exec wl-paste --primary --watch wl-copy --primary --clear with primary_selection disabled does not work.

The only thing that actually works is exec wl-paste --primary --watch wl-copy --primary --clear with primary_selection disabled (or not defined at all).

I tested this on sway-git@1.9-dev-88c17ece on Arch installed from AUR.

IMHO, this issue should be reopened, as #7312 does not fix this issue.

[jeremyjjbrown]

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.

Because you might have a token in your clipboard and you accidentally paste it will trying to left or right click.

[vimproved]

* when I reload Sway, it fails when `primary_selection` is enabled. I understand I cannot enable `primary_selection` when reloading Sway config, however, when it is already enabled, it should not fail. I understand that [`primary_selection.c` (L15-L18)](https://github.com/AidanGG/sway/blob/c32a507303e38c7bf0b8054108bec45ff67e92c2/sway/commands/primary_selection.c#L15-L18) should handle this, but it does not work;

I was becoming quite annoyed by this, so I decided to look into it. Seems like the default_config() function resets primary_selection to true, and is called whenever the config is reloaded. I've filed #7951 to fix this.