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 762446 - terminal automatically unselects text
terminal automatically unselects text
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
git master
Other Linux
: Normal major
: ---
Assigned To: VTE Maintainers
VTE Maintainers
: 763018 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-02-22 12:46 UTC by Dominique Leuenberger
Modified: 2016-03-03 08:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dominique Leuenberger 2016-02-22 12:46:43 UTC
gnome-terminal 3.19.90 gained a very confusing 'auto deseelect' of texts.

How to reproduce:
* open gnome terminal
* select text with the mouse (note: the selection stays visible)
* select another text area with the mouse (note: the selection auto clears)

even though the selection auto-clears, pressing ctrl-ins copies the 'right thing' into the buffer - making it at least 'work' as expected, but the visual representation is definitively confusing.
Comment 1 Christian Persch 2016-02-22 16:03:03 UTC
There's nothing new about this; selection is and always has been cleared when PRIMARY is lost.

Unless you've rearranged shortcuts in gnome-terminal, Ctrl+Shift+Insert pastes CLIPBOARD, not PRIMARY. Shift+Insert pastes PRIMARY.
Comment 2 Dominique Leuenberger 2016-02-22 16:08:27 UTC
i'm not talking about buffers, purely about visuals.

purely 'click and drag' the mouse to select some text (first time selection stays visible), do it again (selection is no longer marked)
Comment 3 Christian Persch 2016-02-22 16:29:47 UTC
Oh, I see. -> vte

Any chance you could git bisect this with the vte-2.91 test app?
Comment 4 Egmont Koblinger 2016-02-22 23:30:42 UTC
It could easily be the smooth scrolling, work-in-progress version of that patch had such problems, although I thought I had fixed them. Could be a subsequent cleanup patch. Probably there's a misunderstanding whether the start/end coordinate is relative to the history's beginning or to insert_delta.
Comment 5 Egmont Koblinger 2016-02-22 23:40:47 UTC
My previous guess is probably incorrect, since the bug also occurs if the terminal hasn't started scrolling yet.
Comment 6 Egmont Koblinger 2016-02-22 23:45:07 UTC
8891f5b94af911f5e6a31ac97b17b8b9e5cdd719 is the first bad commit
commit 8891f5b94af911f5e6a31ac97b17b8b9e5cdd719
Author: Christian Persch <chpe@gnome.org>
Date:   Sun Jan 31 15:08:45 2016 +0100

    widget: Move some methods to VteTerminalPrivate

:040000 040000 db25baf8e802cfac9cfec5f63a34c8018b2ec017 599d281b4e436b554f98544c54756ee54f18c2df M	src
Comment 7 Christian Persch 2016-02-25 17:48:20 UTC
Turns out to be behaviour differing with gtk_clipboard_set_with_data vs. set_with_owner when the previous data/owner is the same as last one. IMHO that's a gtk+ bug, but since that code exists like that since forever (2000), who knows why it does it this way...
Comment 8 Egmont Koblinger 2016-03-03 08:37:51 UTC
*** Bug 763018 has been marked as a duplicate of this bug. ***