GNOME Bugzilla – Bug 584236
Gtk+ should not drop PRIMARY selection when visible selection is cleared
Last modified: 2018-05-02 14:43:55 UTC
This is spun off from bug 333514. The historical behavior of the X11 PRIMARY selection is that it is asserted when the user takes an action which directly results in a selection highlight (so for example when text is selected by click-and-drag, but *not* when text becomes selected via keyboard form traversal) but is *not* deasserted when the user takes an action which clears the selection highlight (e.g. single left click in the same text pane). Gtk+ deasserts PRIMARY when the visible selection is cleared, which is wrong, and contrary to the current revision of the freedesktop.org clipboard spec. I'm going to repeat the reproduction recipe from bug 333514: Run 'zenity --text-info --editable < /dev/null > /dev/null 2>&1 &' twice. The redirections are necessary to prevent zenity from freezing up trying to read from your terminal. Type some text in one zenity window. Select some of it with left mouse. Middle-click in the other zenity window. The selected text will be pasted. This is correct. Now single-click in the first zenity window. The visible selection will vanish. This is still correct. Now middle-click again in the other zenity window. Nothing will happen. This is WRONG WRONG WRONG. The text that you selected before should be pasted again.
I *might* have found the problem (in file gtktextbuffer.c) void gtk_text_buffer_place_cursor (GtkTextBuffer *buffer, const GtkTextIter *where) { gtk_text_buffer_select_range (buffer, where, where); } As you see it calls select_range, so it's like it is selecting (which causes primary to change). I'm not sure of what I'm saying because I can't understand where primary is changed.
these are the calls inside gtk_text_buffer_select_range () _gtk_text_btree_select_range (get_btree (buffer), &real_ins, &real_bound); gtk_text_buffer_mark_set (buffer, &real_ins, gtk_text_buffer_get_insert (buffer)); gtk_text_buffer_mark_set (buffer, &real_bound, gtk_text_buffer_get_selection_bound (buffer)); maybe one of these will clear primary...
Created attachment 135634 [details] [review] gtktextbuffer_primary_selection.patch This patch works, I don't know if it introduces something wrong. I will try to use it in my production laptop. Try it!
Does this patch cover _all_ the ways in which the visible selection highlight can be dropped? Because _none_ of them should deassert PRIMARY, for a complete fix.
Also, there seemed to be consensus in the older bugs that a selection that occurs due to traversal of form widgets should not affect PRIMARY (so that you can select something, traverse, middle-click, and have the earlier explicit selection overwrite the implicitly selected old text in the widget)
This patch covers this: - open some program with a GtkTextView (I only tested gedit) - select some text - move the cursor (either with the keyboard or click with the mouse without selecting other things) Now paste with middle click (not ctrl-v) will work, even if the selection is cleared. Should I test anything else?
Anyway the test in the bug description is passed with the patch. I don't think it introduces malfunctions, because the check is only if the start and end pointer are the same. So I can think of a situation like this, only when you deselect.
Created attachment 135655 [details] [review] gtktextbuffer_primary_selection_v2.patch This should be better, since instead of comparing directly the 2 pointer, it uses the dedicated function
The "v2" patch does not work. It has problems while unselecting, sorry. The first patch should work insted. Did you test it?
I've also tried with gtk_text_iter_equal. It works, but it's not possible to select the word with double click. It seems that the only working patch is the first I attached, even if it's marked as obsolete. is it possible to unmark it?
Sorry, none of the patches really work. I also realized that the trick was done by a clipboard manager software which I installed. I also realized that the function gtk_text_buffer_place_cursor is called only when moving the cursor using arrow keys. I will investigate again and let you know. But now I'm quite sure we need a gtk+ developer, because it's too difficult to understand which function is called when clicking with the mouse.
Created attachment 156281 [details] [review] Might be a good idea at a solution somehow I might have found another way to do this. It seems in every widget, there is a test when the selection changes that invokes the function gtk_whatever_get_selection_bounds(). This function return false if there is no selection. And in every case, when there is no selection, gtk_clipboard_clear() is called. I have yet to test the patch resulting from this, but I give it to you in the meantime. Things that need review: the doc says that the copy is implemented by copying the content of PRIMARY to CLIPBOARD. Naw that PRIMARY is no longer the morror of the selection, perhaps some code has to be changed here as well.
The problems described in Bug 333514 (especially this one and not the other ones) have been driving me nuts to a point of avoiding all GTK-based applications. Unfortunately, I am stuck with Evolution which suffers from this annoyance. The e-mail address auto-complete feature overwrites PRIMARY as the auto-complete selects the untyped portion of the e-mail address. I know it's been described and beaten to death (since 2006!) in other bugs but it took me quite a while before I got the correct wording (thanks Wikipedia). The description of the bug adequately describes the expected behavior. There is one thing which I want to make clear (as I am not sure it is after reading the multiple bug reports on this): Mouse selection -> copy to PRIMARY Button 3 -> Paste from PRIMARY Keyboard/[context] menu copy -> copy to CLIPBOARD Keyboard/[context] menu paste -> paste from CLIPBOARD All other selections NOT from the user's mouse (ie: keyboard, pop-up with pre-selected text, auto-complete with highlighted remaining text) should NOT replace the contents of PRIMARY as this is not a selection from the user. Again, I know this has been described in many ways but I've yet to see it put down this ...uhm, clearly (for me at least). This has been my expected behavior and what I have gotten used to in my past 10+ years experience with X11/Xorg and find GTK's applications inconsistency very frustrating in that respect. If I am barking up the wrong bug, to shuve me into the correct direction as copy/paste and even PRIMARY not spurs many other bugs. (And why is this bug unconfirmed and enhancement only?)
*** Bug 519343 has been marked as a duplicate of this bug. ***
Created attachment 243692 [details] Test program with a label, an entry and a text view There is also a button to modify the text of the label. The purpose is to test the behavior when (1) we select some text in the label, (2) the selection is cleared, (3) the text changes, (4) we paste the primary selection.
Created attachment 243693 [details] [review] GtkLabel: don't drop PRIMARY selection when visible selection is cleared We must remember the last selection positions, in case the selection is cleared.
Created attachment 243694 [details] [review] GtkLabel: clear PRIMARY selection when the text changes When the text changes, the previously selected text is generally not the same anymore.
Created attachment 243706 [details] [review] GtkEntry: don't drop PRIMARY selection when visible selection is cleared Same modifications as in GtkLabel.
The above patches add some fields to the private structure of GtkLabel and GtkEntry to remember the positions of the last selection bounds, and use these values to provide the text to be pasted. Now a problem arises: what to do when the text of the widget is modified? For the GtkLabel, it is simple, the primary selection is simply cleared. For the GtkEntry and GtkTextView, it is more complex. Here is what I propose: - if a text modification occurs inside the last selection's positions, the primary selection should be cleared. - if a text modification occurs after the last selection's end position, do nothing, because the last selection's positions are still valid. - if a text modification occurs before the last selection's start position, update the positions accordingly, so the primary selection still exists.
Created attachment 243849 [details] [review] GtkEntry: update PRIMARY selection when text changes If a text modification occurs inside the last selection's positions, the primary selection is cleared. If a text modification occurs after the last selection's end position, do nothing, because the last selection's positions are still valid. If a text modification occurs before the last selection's start position, update the positions accordingly, so the primary selection still exists.
Created attachment 244331 [details] [review] GtkTextView: don't drop PRIMARY selection when visible selection is cleared
Sebastian, you are investing a lot of effort into this. Just to be clear: I'm not in favour of changes to the primary handling.
(In reply to comment #22) > Sebastian, you are investing a lot of effort into this. > Just to be clear: I'm not in favour of changes to the primary handling. Please explain why you are not in favour of these changes. The current behavior is contrary to the fd.o clipboard specification, inconsistent with historical practice, and makes the primary selection less useful than it could be; any *one* of those is IMNSHO sufficient justification for changing it.
*** Bug 648670 has been marked as a duplicate of this bug. ***
So this bug should probably be closed as WONTFIX, since it was planned to remove the support of the primary selection in gtk (it was done and then reverted), and because the Wayland devs don't want to implement the primary selection. The reason is that people often err between ctrl+v and middle-click. The other reason is that the selection often changes between the moment we want to copy and paste, resulting in a waste of time: the user must re-copy the text with ctrl+c or find a trick to not loose the selection. And there are probably other reasons. In the end, it's easier to always use ctrl+c/ctrl+v, there is no possible mistakes. So I guess the plan is to leave the primary selection as-is in gtk so users are not grumpy, and when users will switch to Wayland, the primary selection is anyway not present there, so in the future, when most users have switched to Wayland, support for primary selection can be completely removed from gtk (e.g. for GTK+ 4).
(In reply to comment #25) > So this bug should probably be closed as WONTFIX, since it was planned to > remove the support of the primary selection in gtk (it was done and then > reverted), and because the Wayland devs don't want to implement the primary > selection. I am extremely disappointed to hear both of these things. Middle-click is wired into my fingers, and it frustrates me continually that this bug has still not been fixed. When it works, select+middle-click is a more efficient way of moving text around, because you can do it entirely with the mouse. It is *this very bug* that makes it *seem* like an unreliable and undesirable feature. The right course would be to *fix* this bug, making middle-click a good feature again. > The reason is that people often err between ctrl+v and middle-click. The other > reason is that the selection often changes between the moment we want to copy > and paste If this bug were fixed -- causing PRIMARY not to be dropped when the visible selection is lost, and causing any action that sets CLIPBOARD to set PRIMARY to the same value -- these problems would vanish! And possibly the Wayland developers would understand the value of the feature if it worked correctly ;-)
(In reply to comment #26) > If this bug were fixed -- causing PRIMARY not to be dropped when the visible > selection is lost, and causing any action that sets CLIPBOARD to set PRIMARY to > the same value -- these problems would vanish! One other problem when copy/pasting between two apps. When an app gains the focus, the text in an entry is often selected (it happens frequently with Firefox for example), so you loose your previously selected text from the other app.
(In reply to comment #27) > > One other problem when copy/pasting between two apps. When an app gains the > focus, the text in an entry is often selected (it happens frequently with > Firefox for example), so you loose your previously selected text from the other > app. That is also covered somewhere in this set of bugs (see bug 333514 for overview). Visible selections caused by focus changes should *not* assert PRIMARY.
(In reply to comment #28) > Visible selections caused by focus changes should *not* assert PRIMARY. Then what if a user wants to paste the text that was selected by focus change? The user must re-select the text by hand. Another solution is to not select text when an app gains the focus, but there are probably good reasons for doing that.
(In reply to comment #29) > (In reply to comment #28) > > Visible selections caused by focus changes should *not* assert PRIMARY. > > Then what if a user wants to paste the text that was selected by focus change? Then the user hits Ctrl-C, which sets *both* CLIPBOARD and PRIMARY.
> Ctrl-C sets *both* CLIPBOARD and PRIMARY. That is, it's supposed to. Please reread the original description of how this is supposed to behave, in bug 333514, and you should come to understand that this feature is actually quite carefully designed and ergonomic WHEN IT'S IMPLEMENTED CORRECTLY.
(In reply to comment #31) > > Ctrl-C sets *both* CLIPBOARD and PRIMARY. > > That is, it's supposed to. Please reread the original description of how this > is supposed to behave, in bug 333514, and you should come to understand that > this feature is actually quite carefully designed and ergonomic WHEN IT'S > IMPLEMENTED CORRECTLY. by reading the bug you linked, I think that you use "implemented correctly" as a shorthand for "implemented the way I want it or as I am used to" — which clashes with how other people want this "feature" to work, or how actual people use actual computers. this speaks volumes as to how this feature was "designed" (hint: it really wasn't) or how it's "ergonomic" (hint: it really isn't). personally, I think this stuff ought to be placed on the nearest rocket and launched towards the center of the Sun, and neither this bug nor bug 333514 have convinced me otherwise — whereas I still have to battle with various web browser (not using GTK) pasting random stuff because of PRIMARY/CLIPBOARD madness.
(In reply to comment #32) > (In reply to comment #31) > > > Ctrl-C sets *both* CLIPBOARD and PRIMARY. > > > > That is, it's supposed to. Please reread the original description of how this > > is supposed to behave, in bug 333514, and you should come to understand that > > this feature is actually quite carefully designed and ergonomic WHEN IT'S > > IMPLEMENTED CORRECTLY. > > by reading the bug you linked, I think that you use "implemented correctly" as > a shorthand for "implemented the way I want it or as I am used to" It's true that what I want is the behavior my fingers expect, but it doesn't follow that that means it's a bad design. If it were a bad design, I would never have gotten it so deeply embedded in my fingers that I would be prepared to argue for its continued existence 20 years later! I would probably be disgusted with it, just as you are. That's the thing that convinces me it's a *good* design, tbh - that *even knowing it's broken in Gtk+* I still continually try to use it. > personally, I think this stuff ought to be placed on the nearest rocket and > launched towards the center of the Sun, and neither this bug nor bug 333514 > have convinced me otherwise — whereas I still have to battle with various web > browser (not using GTK) pasting random stuff because of PRIMARY/CLIPBOARD > madness. I very strongly suspect that you, and others like you, hate this feature because you have never used a system where it works *correctly*. In a system where PRIMARY works correctly, you never discover yourself pasting "random stuff". Middle-click reliably produces the last thing you explicitly selected with the mouse, or the last thing you copied with the keyboard, whichever is newer, even if that selection highlight is no longer active. Conversely, keyboard paste reliably produces the last thing you copied with the keyboard. (If you never middle-click, how do you ever trip over PRIMARY at all? You should be able to blithely ignore its existence and use only CLIPBOARD. Do other toolkits have a bug where setting PRIMARY overwrites CLIPBOARD? That is also wrong.)
(In reply to comment #30) > > Then what if a user wants to paste the text that was selected by focus change? > > Then the user hits Ctrl-C, which sets *both* CLIPBOARD and PRIMARY. Ok, but users usually remember this rule: "middle click pastes the last selected text". Adding an exception with focus change doesn't help, and makes the feature more obscure to use. A user will first try to paste with middle click, will see that the pasted text is wrong, and will try again. The problem is "will try again". It shouldn't be the case, copy/paste rules should be really straightforward and should always work as expected.
(In reply to comment #34) > (In reply to comment #30) > > > Then what if a user wants to paste the text that was selected by focus change? > > > > Then the user hits Ctrl-C, which sets *both* CLIPBOARD and PRIMARY. > > Ok, but users usually remember this rule: "middle click pastes the last > selected text". Adding an exception with focus change doesn't help, and makes > the feature more obscure to use. The exception for focus changes is a bit of a quirk, but it really really is the behavior you want. Xt didn't have that exception, and would auto-select the text in most form fields whenever they gained focus *in any way* (IIRC -- it *has* been 20 years) so copying text into a form field was a pain. Since Gtk+ seems bound and determined to keep the (mis-)feature of allowing each window to have its own visible selection, also, it's very important that *those* do not confuse the issue of what's in PRIMARY. "The most recent thing I manually selected with the mouse or explicitly copied" is a consistent mental model that users can and will learn. "The most recent thing that got a visible selection highlight (if it's still visibly selected) (maybe)" is *not* a consistent mental model and that's why a lot of newer users are annoyed that this feature exists.
(In reply to comment #25) > So this bug should probably be closed as WONTFIX, since it was planned to > remove the support of the primary selection in gtk (it was done and then > reverted), and because the Wayland devs don't want to implement the primary > selection. I do hope that support for primary selection in GTK stays, at least as long as GTK supports backends that have primary selection (i.e, as long as X11 is supported). > So I guess the plan is to leave the primary selection as-is in gtk so users are > not grumpy, and when users will switch to Wayland, the primary selection is > anyway not present there, so in the future, when most users have switched to > Wayland, support for primary selection can be completely removed from gtk (e.g. > for GTK+ 4). Almost no distribution ships with Wayland by default yet. So the time when the world has forgotten about X11 might be quite a bit ahead ;-) It would be nice to have GTK follow the standard behaviour of copy-paste in the mean time. There are patches attached to this bug report that seems to fix this bug. Any reason not to review/apply them?
Lyude is implementing primary selection in Wayland, so we've lost that excuse. Meanwhile this bug has been breaking the Law of Least Astonishment for seven years. It has been patched (thanks Seb) for the past three years. It's time to apply the patches and fix this problem. Who'll be a hero and do it?
*** Bug 780872 has been marked as a duplicate of this bug. ***
*** Bug 333514 has been marked as a duplicate of this bug. ***
-- 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/gtk/issues/317.