After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 665193 - Disable middle-click paste by default
Disable middle-click paste by default
Status: RESOLVED OBSOLETE
Product: gnome-settings-daemon
Classification: Core
Component: mouse
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
wayland
: 536271 (view as bug list)
Depends on: 665243
Blocks: 705359
 
 
Reported: 2011-11-30 12:02 UTC by Bastien Nocera
Modified: 2019-03-20 10:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
xsettings: Disable middle-click paste by default (2.98 KB, patch)
2011-11-30 19:58 UTC, Bastien Nocera
reviewed Details | Review
xsettings: Disable middle-click paste by default (926 bytes, patch)
2013-08-02 14:51 UTC, Bastien Nocera
none Details | Review
xsettings: Disable middle-click paste by default (1.11 KB, patch)
2013-08-02 14:59 UTC, Bastien Nocera
committed Details | Review

Description Bastien Nocera 2011-11-30 12:02:09 UTC
Because, really...

https://twitter.com/#!/johandahlin/status/141848448973549569
Comment 1 Johan (not receiving bugmail) Dahlin 2011-11-30 12:11:00 UTC
The tweet is actually wrong, since it disables the middle mouse button altogether -- it makes sense to have a third mouse button for web browsers etc, just not pasting with it.

IMNSHO g-s-d should also disable the PRIMARY clipboard, CLIPBOARD should be enough for everybody, it's 2011 after all, other popular window systems do not have implicit clipboards.
Comment 2 Jeff Schroeder 2011-11-30 18:05:55 UTC
Breaking a default that has been in X forever is not desirable. In this case, it is a good default. Leave it alone. Bastien, please do not do this.
Comment 3 Bastien Nocera 2011-11-30 19:55:11 UTC
(In reply to comment #1)
> The tweet is actually wrong, since it disables the middle mouse button
> altogether -- it makes sense to have a third mouse button for web browsers etc,
> just not pasting with it.
> 
> IMNSHO g-s-d should also disable the PRIMARY clipboard, CLIPBOARD should be
> enough for everybody, it's 2011 after all, other popular window systems do not
> have implicit clipboards.

The code's wrong indeed. The correct way of doing things is in the GTK+ bug associated.

(In reply to comment #2)
> Breaking a default that has been in X forever is not desirable. In this case,
> it is a good default. Leave it alone. Bastien, please do not do this.

Disabling broken behaviour by default is a good thing. It would be a GTK+ specific XSetting, which would only be disabled by default based on your XSettings manager. If you use gnome-settings-daemon, then it would be disabled by default.

The people that paste their passwords to IRC will thank us.

Will have to wait until http://live.gnome.org/GnomeOS/Design/Whiteboards/Selections gets designed/implemented.
Comment 4 Bastien Nocera 2011-11-30 19:58:01 UTC
Created attachment 202481 [details] [review]
xsettings: Disable middle-click paste by default
Comment 5 Jean-François Fortin Tam 2011-11-30 20:59:37 UTC
Please, please, pretty please do not disable this feature by default in gnome-settings-daemon. I, among many others, use select-and-middleclick-paste dozens (sometimes hundreds) of times a day. It is harmless. It is useful. It is one of the core productivity-enhancing features of the Linux ecosystem that I find myself missing in every other OS, right alongside the "scroll any window, focused or not" feature.

By removing it, you gain nothing but angst from some of your most loyal users. Programmers use this. Writers use this. Designers use this. It is one of the killer features I show to new users (friends, family members, etc.). Just because some vocal minority ranted about it on Twitter does not make it right to penalize the 99% of people who are happy about it. And from the 3.x track record, I don't expect you'd add an option in the mouse settings to allow users to easily re-enable this.


> The people that paste their passwords to IRC will thank us.

Really. How likely is it that someone:
1) selects a block of text that is their password
2) middle-clicks into a *writable text entry widget* *in their IRC client*
3) presses Enter
4) all while *NOT* noticing anything
5) complains that this is the software's fault?!


What's next? Disabling the ability to scroll unfocused windows just because some dude somewhere ranted that his browser scrolls in the background when his cat walks over his laptop?
Comment 6 Xavier Claessens 2011-11-30 21:09:44 UTC
next step is to disable the DELETE key in nautilus, because clearly this is way too dangerous, people could move files to the trash... oh wait...
Comment 7 misc 2011-11-30 21:19:37 UTC
Disabling something current users expect is discutable. OS X does this way for terminal, KDE does this way ( and all others desktop environement on all unix-like ), even putty work this way on windows. 
So people in some circonstances expect it, at least for terminal where cut and paste can be rather cumbersome to do if that requires to use the menu.

Not to mention that erronous paste by error requires to have a 3rd mouse button, which usually cannot be triggered by error on most laptops, and hardly on all mouses. 

A better solution for the password issue would be to either not place it in clipboard ( which is already done for those using gtk, IIRC ), or to fix the root cause of people doing cut and paste.
Comment 8 Bastien Nocera 2011-11-30 21:47:47 UTC
(In reply to comment #7)
> Disabling something current users expect is discutable. OS X does this way for
> terminal, KDE does this way ( and all others desktop environement on all
> unix-like ), even putty work this way on windows. 

If you read the related GTK+ code in the other bug, it's really up to individual widgets to act upon middle click. The problem is that GTK+'s default implementation doesn't give us any sort of choice. It even does middle-click paste on Windows...

The gnome-settings-daemon patch just toggles an XSetting. It's then up to individual widgets to act upon the setting. This means that widgets built for "legacy" applications (eg. vte's terminal widget) can of course choose to ignore the setting.

Furthermore, if you read the GTK+ code some more, you'll notice that it's up to each toolkit to implement what to do with the middle-click. GTK+ chose to follow X11 legacy behaviour, even on non-X11 platforms.

FWIW, the GTK+ middle-click behaviour is probably going to need more than just this behaviour switch. Subscribe yourself to the design page, and feel free to participate in the discussion when it actually happens. It's not happening right now, we're just dumping patches to Bugzilla.

> So people in some circonstances expect it, at least for terminal where cut and
> paste can be rather cumbersome to do if that requires to use the menu.
> 
> Not to mention that erronous paste by error requires to have a 3rd mouse
> button, which usually cannot be triggered by error on most laptops,

3-finger click will generate middle-click for some touchpads. That could be two-finger + edge of the palm for devices without a good palm detection.

>  and hardly
> on all mouses. 

Speaking from experience, you end up scrolling when you want to paste, and pasting when you want to scroll, depending on your brand of horrible hardware.

> A better solution for the password issue would be to either not place it in
> clipboard ( which is already done for those using gtk, IIRC ), or to fix the
> root cause of people doing cut and paste.

It's just an example. In any case it's a behaviour unseen in other OSes, or even other windowing systems, and it's not taken away from you.
Comment 9 Jonathan MERCIER 2011-12-02 17:37:29 UTC
i found the feature copy/paste from middle click very useful and i am not the one.
copy / paste a password could happen with ctrl+v too ...
if you want enhance security about middle click for any strange reason at least do:
ctrl + middle click for paste
like you have done for ctrl + del
Comment 10 William Jon McCann 2012-05-04 19:30:36 UTC
*** Bug 536271 has been marked as a duplicate of this bug. ***
Comment 11 Yajo 2013-05-24 13:56:26 UTC
(In reply to comment #5)
> Just
> because some vocal minority ranted about it on Twitter does not make it right
> to penalize the 99% of people who are happy about it.

Where does that poll come from?

Anyway, coming from other OS, I find very comfortable and useful the ability to automatically scroll with middle-mouse click. Why not just give me (and *many* others like me) the option to make my computer work as I like it?

BTW, the only option I have found is just disabling that mouse button messing up with x.org config files. That's insane. I don't want to disable it, just be able to use it in a logical way (for me).

So, if this feature is not turned on by default, at least let us do it, please.
Comment 12 Bastien Nocera 2013-08-02 14:51:21 UTC
Created attachment 250712 [details] [review]
xsettings: Disable middle-click paste by default
Comment 13 Bastien Nocera 2013-08-02 14:59:20 UTC
Created attachment 250715 [details] [review]
xsettings: Disable middle-click paste by default

The middle-click will be used to start selections, and
provide text contextual menus (such as word definitions, sharing, etc.)

See:
https://wiki.gnome.org/GnomeOS/Design/Whiteboards/Selections
for design details.
Comment 14 Bastien Nocera 2013-08-02 15:00:14 UTC
See https://bugzilla.gnome.org/show_bug.cgi?id=705359 for the tweak-tool config.

Attachment 250715 [details] pushed as 696e04d - xsettings: Disable middle-click paste by default
Comment 15 Adam Williamson 2013-08-22 16:21:45 UTC
I don't see the word "middle", or any obvious synonym, anywhere in the linked design document. Where does it state what the middle button is going to do?
Comment 16 Simon Geard 2013-08-27 02:18:08 UTC
(Wanting to get in before the hordes who have just seen this on Phoronix)

Here's a question - why? There's a very big downside to changing something that's been a UNIX standard for decades, and is ingrained habit for a great many of your users. It's one of those muscle-memory things...

Your proposal seems to be that all of your existing users should update to a future Gnome version, find that their attempt to use the clipboard is now doing something completely different and confusing. They will then spend the rest of their day cursing your names as they hunt around on Google to work out how to undo this change.

So what's the upside? As Adam asks, the Selections page isn't very clear on quite what this has to do with "middle click", since it's all about touch screen interfaces. But from what I can see, this is exactly the same thing a "right click", but with prettier context menus? This needs a *lot* more selling, if you're going to go around breaking something as fundamental as copy-paste...
Comment 17 Adam Williamson 2013-08-27 10:21:29 UTC
This has already been reverted upstream for 3.10 at least.
Comment 18 Joe Doss 2013-08-27 14:55:46 UTC
Disabling middle-click paste by default is going to break the work flow of a huge part of your user base. Please, please, please do not go forward with this change without having a built in option to opt out of this change or better yet, why not just add in a option in the mouse section of to turn it off if you feel it is a problem? Why are you pushing this on as default when a very large part of your user base does not feel the same. Seriously, where do you guys get your usability data from to base these changes from? Twitter? Do you guys poll your user base frequently to understand why they use GNOME and how changes such as this will force them to leave? I know handfuls of GNOME users that rely on middle click paste for their daily workflows and none of them care about copying other desktops middle click behavior.

Please! I love GNOME! Even with your janky changes to GNOME 3. It has been a major part of my personal and professional desktop experience for over 10 years. Don't force this change on your user base.

(In reply to comment #3)
> The people that paste their passwords to IRC will thank us.

And the rest of your loyal user base will not be thanking you and they be switching away from GNOME to get a core aspect of their workflow back.
Comment 19 Tobias Mueller 2013-08-27 16:57:45 UTC
Hi.

(In reply to comment #18)
> Please, please, please do not go forward with this
> change without having a built in option to opt out of this change or better
> yet, why not just add in a option in the mouse section of to turn it off if
> you feel it is a problem?
Worry not. As mentioned in comment #14, tweak-tool will allow you to change this behaviour with a click of a button. So absolutely nothing will be different for you. So there will be this option you are talking about.



As for the rest of your comment, I'd prefer you sticking to facts and avoid inflammatory ramblings (i.e. "janky changes"). Thanks.
Comment 20 Joe Doss 2013-08-27 17:53:31 UTC
Hi Tobias,

(In reply to comment #19)
> Hi.
> 
> (In reply to comment #18)
> > Please, please, please do not go forward with this
> > change without having a built in option to opt out of this change or better
> > yet, why not just add in a option in the mouse section of to turn it off if
> > you feel it is a problem?
> Worry not. As mentioned in comment #14, tweak-tool will allow you to change
> this behaviour with a click of a button. So absolutely nothing will be
> different for you. So there will be this option you are talking about.

Awesome. Whew! Thanks! The sky is no longer falling. I wish that was more clear to start. Sorry for the confusion on my part.

My other questions are still not really answered. Why not just leave it as the default and add the option if there is a subset of people that don't like it? I just don't understand where you guys get your data in regards to making huge changes to the default behaviors of GNOME. Was it a user request? Was there a poll that shows this overwhelming demand to remove this functionality? Where is the data that supports facts that this as a positive and needed feature change? Based on this bug report its from one developer quoting a twitter post about how it is a wrong feature to have and then he says it is a "good thing" and people will thank you guys for the change. It doesn't add up and when people ask why you guys don't give any answers. 

> As for the rest of your comment, I'd prefer you sticking to facts and avoid
> inflammatory ramblings (i.e. "janky changes"). Thanks.

Sorry about that. I will keep that in mind next time. I just wish there was more communication between your user base surrounding these kinds of change as GNOME progresses. I understand you guys work hard to make GNOME great. Us users just need to be on the same page as you guys so we can help you do that. 

Apologies for coming across wrong with my initial response ITT. That wasn't my intention.
Comment 21 Andrew Clayton 2013-08-27 19:32:24 UTC
(In reply to comment #19)

> Worry not. As mentioned in comment #14, tweak-tool will allow you to change
> this behaviour with a click of a button. So absolutely nothing will be
> different for you. So there will be this option you are talking about.

In fact even better, as said in comment #17, the default has been put back to enable middle click paste.

See: https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=e204eddcdbfb9f8d722355fab1643330c7d10c25
Comment 22 Simon Geard 2013-08-27 21:08:41 UTC
Andrew, Tobias - 

I understand that the change of default has now been reverted, and that the behaviour was configurable. My concern is that this can happen at all - someone can deliberately break the behavior that existing users rely on, without any kind of announcement or discussion.

I don't want to turn this into one of the tedious rants you guys hear so much, but *please* think about the effect on your existing users when you decide to change behavior. There's a tendency to focus on how you think things should be, and often, not much thought about that pain caused in transitioning to that new way...
Comment 23 Tobias Mueller 2013-08-28 10:34:05 UTC
Hi :)

(In reply to comment #20)
> Awesome. Whew! Thanks! The sky is no longer falling. I wish that was more
> clear to start. Sorry for the confusion on my part.
> 
Yeah, well. I wonder who made you think the sky is falling ;-) It probably wasn't us, right?

> My other questions are still not really answered. Why not just leave it as the
> default and add the option if there is a subset of people that don't like it?
I don't fully know as I like the behaviour that is about to not become the default any longer. But I see the point of the change. And I think it makes sense once you see the technical background: There are at least three clipboards in X. And then there are cut buffers, again about three. And then you apparently have different protocols on top of all that. And indeed if I told my mom (or my dad, FWIW) that middle-click was there to paste, she would be very confused once she selects text, Ctrl+Cs it, then selects some different text (for whatever reason), and tries to middle-click-paste the Ctrl+Ced text.
So making things making more sense is a good thing. But again, for the brave of you, and like me, the old and loved behaviour is only a click away.


(In reply to comment #22)
> My concern is that this can happen at all - someone
> can deliberately break the behavior that existing users rely on, without any
> kind of announcement or discussion.
> 
I don't think you are appreciating the things that have been done with regards to announcing changes to GNOME. We had at least one comprehensive blog post up on planet GNOME. We will probably have more the closer we come to 3.10. We have the feature proposal period to discuss what's going to happen. We have people sitting on mailing lists, on IRC, and on forums to communicate. I'm not saying we're doing a perfect job. And I do see that there is room for improvement, i.e. we could expose discussions happening on mailing lists or on IRC more visibly. But I would like you to not think that there isn't *any* kind of announcement or discussion. And most of the time you are more than welcome to help out and make things better.

As for this very change, the need is low to announce it as there will be no change for 3.10. So blaming us for not announcing what is not going to happen feels odd ;-) I invite you to work on the communication for the release after that, to make sure we cover much more ground than we usually do.

I'd like to keep the discussion on this bug (or any bug, really) to a minimum. The appropriate places to actually discuss things are mailing-lists. In this very case, due to lack of a g-s-d list, I guess it is desktop-devel-list.
Comment 24 Joe Doss 2013-08-28 16:53:50 UTC
Hi Tobias,

(In reply to comment #23)
> Yeah, well. I wonder who made you think the sky is falling ;-) It probably
> wasn't us, right?

It came from me reading the bug report which is from you guys, so yes it was you. It was not clear on the reasons why it is getting changed and any discussion or back story on the reasons. Yes, its not getting changed for 3.10 but it could down the road and that concerned me and prompted me to post to get more information and have my voice be heard.

> I don't fully know as I like the behaviour that is about to not become the
> default any longer. But I see the point of the change. And I think it makes
> sense once you see the technical background: There are at least three
> clipboards in X. And then there are cut buffers, again about three. And then
> you apparently have different protocols on top of all that. And indeed if I
> told my mom (or my dad, FWIW) that middle-click was there to paste, she would
> be very confused once she selects text, Ctrl+Cs it, then selects some different
> text (for whatever reason), and tries to middle-click-paste the Ctrl+Ced text.
> So making things making more sense is a good thing. But again, for the brave of
> you, and like me, the old and loved behaviour is only a click away.

So the change is to be more like mainstream OSes and there are technical? OK fair enough. If that is how you understand the reasoning. Explaining it like that and giving technical reasons is better than a twitter link + saying trust me we know better and you will thank us later. I still don't agree with the change as a whole. I don't want GNOME to act like windows or OS X. I use it because of features middle click paste, but that is my personal preference as a long time GNOME user. Anyways, thanks for explaining it as you see it even if you 100% don't know the reasons behind it. I appreciate you taking the time to explain your stance on why it is getting changed.

> (In reply to comment #22)
> I don't think you are appreciating the things that have been done with regards
> to announcing changes to GNOME. We had at least one comprehensive blog post up
> on planet GNOME. We will probably have more the closer we come to 3.10. We have
> the feature proposal period to discuss what's going to happen. We have people
> sitting on mailing lists, on IRC, and on forums to communicate. I'm not saying
> we're doing a perfect job. And I do see that there is room for improvement,
> i.e. we could expose discussions happening on mailing lists or on IRC more
> visibly. But I would like you to not think that there isn't *any* kind of
> announcement or discussion. And most of the time you are more than welcome to
> help out and make things better.
> 
> As for this very change, the need is low to announce it as there will be no
> change for 3.10. So blaming us for not announcing what is not going to happen
> feels odd ;-) I invite you to work on the communication for the release after
> that, to make sure we cover much more ground than we usually do.
> 
> I'd like to keep the discussion on this bug (or any bug, really) to a minimum.
> The appropriate places to actually discuss things are mailing-lists. In this
> very case, due to lack of a g-s-d list, I guess it is desktop-devel-list.

I agree that the bug report is not a place to talk about these kinds of things and I also agree that you guys can do a lot better at connecting with your user base. OK, so are you going to open a thread on desktop-devel-list or should Simon or I attempt to do so and risk getting ignored/talked about behind our backs per the welcome email from desktop-devel-lists? =P

On 08/28/2013 07:59 AM, desktop-devel-list-request@gnome.org wrote:
> Welcome to the desktop-devel-list@gnome.org mailing list! This list is
> for general GNOME Desktop Development issues. Don't try and talk about
> anything else because we will just not listen and just laugh about you
> behind your back. You have been warned.

This is an example of a disconnect between you the GNOME developers and us the GNOME users, when it comes to talking about what is important to each one of us regarding the direction of GNOME down the road. There isn't a single spot which is the best method for having these conversations. Just as middle click paste is confusing for your mother/father, are they going to know how to sign up for a mailing list to talk about features within Gnome that work or do not work for them? If they manage to sign up for a mailing list are they going to feel welcome to post their concerns when they get a welcome message like this? You say there is discussion but in it's current form it's not very encouraging for users to participate in helping you make GNOME better. This causes the disconnect continue and the GNOME user base continues to shrink.

Anyways, I won't derail this bug any more. I signed up on desktop-devel-list so I can lurk for a while before posting and getting made fun of behind my back. Should be a good time. ;-)
Comment 25 Bastien Nocera 2013-09-04 19:02:53 UTC
Reopening as per comment 21, the code was reverted.
Comment 26 Ray Morris 2013-09-24 15:17:13 UTC
> if I told my mom (or my dad, FWIW)

Mom can use ctrl-c until she's ready to delve deeper, in the same way that a kid says "mama" before they learn "maternal".
It is generally error to make things easier for the first two months of use at the expense of making it harder for the next 20 years of use.
If this were not so, the user-to-user interface wouldn't be English, but baby talk, with a vocabulary of about 30 words.  We use tens of thousands of words to interface with each other because that it's extremely powerful, though complex - so complex that no one can ever finish learning English - there's always more to learn.
Comment 27 Dan Kegel 2013-09-24 16:14:04 UTC
I fear that disabling it by default is just the first step in making
it impossible for us to use middle click in the traditional manner.

I rely on this; it's harder to do ^C / ^V all the time.
Life is faster and better with middle click 'paste'.
Comment 28 Yajo 2013-09-24 18:38:47 UTC
tl;dr: Let users choose between auto-scroll, quick paste, or nothing.

Hello.

I think the point is not just taking away a feature. Many people use it and it's good. The point is that the "expected" behavior (well, for me) when I click the middle button is the automatic scrolling, in any app. It's annoying to try to do scrolling in gedit and have it paste a string of text that I don't know where it comes from, mostly if I'm coding.

Now that I know it, it's true that it is easier to paste that way, but I use auto-scroll in the apps that allow it (Firefox, LibreOffice...) because it's the only way to auto-scroll, while to copy-paste I have other ways (right button, ctrl-C/V).

IMHO just an option for that in the mouse config dialog would be enough to make everyone happy.
Comment 29 Pierre Ossman 2013-09-25 05:29:17 UTC
A major issue that I don't think has been mentioned is the inconsistency this change would introduce. Even if you manage to get it so that every GTK+ application automatically respects this setting, what about everything else? The behaviour of PRIMARY is a de facto standard and basically every toolkit and application implements it. It would be very confusing for users if suddenly GTK+ applications behaved differently from the other applications on the desktop.
Comment 30 Bastien Nocera 2015-11-04 13:40:09 UTC
We won't be changing the default for X11, and this is already "disabled" (there's no separate clipboard for the selection) in Wayland. In the future, we might make use of the middle button for other purposes, as mentioned in the design docs, but this seems to be further away, and wouldn't be implemented in gnome-settings-daemon). So closing.
Comment 31 Bastien Nocera 2015-11-17 15:19:03 UTC
Apparently, it's coming to Wayland, so we'll need a way to disable it on Wayland:
https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
Comment 32 Adam Jackson 2016-12-15 14:52:40 UTC
(In reply to Bastien Nocera from comment #31)
> Apparently, it's coming to Wayland, so we'll need a way to disable it on
> Wayland:
> https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection

The wayland session is now the default in Fedora 25. Since there's still no way to disable middle-click paste under wayland, this now means middle-click paste is enabled by default.
Comment 33 Bastien Nocera 2016-12-15 14:58:00 UTC
(In reply to Adam Jackson from comment #32)
> (In reply to Bastien Nocera from comment #31)
> > Apparently, it's coming to Wayland, so we'll need a way to disable it on
> > Wayland:
> > https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
> 
> The wayland session is now the default in Fedora 25. Since there's still no
> way to disable middle-click paste under wayland, this now means middle-click
> paste is enabled by default.

Already taken care of in bug 775844.
Comment 34 GNOME Infrastructure Team 2019-03-20 10:57:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/178.