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 631195 - middle-button paste into a GtkTextView leaves the cursor in the wrong place
middle-button paste into a GtkTextView leaves the cursor in the wrong place
Status: RESOLVED DUPLICATE of bug 81880
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
2.20.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 673760 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-10-02 21:14 UTC by gnutter
Modified: 2013-04-06 16:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description gnutter 2010-10-02 21:14:12 UTC
In a  GtkTextView instance (eg gimp simple text edit window or bluefish editor window) , a middle button click to paste the primary selection does not move the text cursor , it remains at it's previous position. 

This is inconsistent with using clipboard insert (either by menu or cntl-v) and is seems incorrect in that it affects the text at the new postition but does not bring the cursor to the focus of the new activity. This is distracting.

I would expect the text cursor to move to the end of the newly inserted text as is the case with clipboard insertion. 

I can't think of a purposeful reason for this not happening , it just seems to be a defect. Please comment if there is a reason.


This leads to a secondary problem.  In order to bring the text cursor to the new focus of activity a second click (button1) is required. This is not only unnecessary but has the nefarious effect of clearing primary selection thus preventing a second paste operation of the same text. 

The X primary selection, copy/paste mechanism is highly ergonomic and this small defect preventing it from working is annoying. In a full blown editor like bluefish this is a significant hindrance to the work-flow.
Comment 1 Emmanuele Bassi (:ebassi) 2012-07-20 17:21:09 UTC
*** Bug 680327 has been marked as a duplicate of this bug. ***
Comment 2 gnutter 2012-07-20 18:27:30 UTC
Having checked this as a result of Emmanuele's incorrect dupe of Bug 680327 it seems it is in someway better , though not fixed. 

The actual subject of this bug remains the case : the text cursor does not move. This seems inappropriate when inserting text as per #1

However the more destructive corollary has been fixed. It is not possible to select a segment of text and use multiple X11 paste operations. 

That is a BIG help. Thanks to whoever fixed that one.
Comment 3 Sébastien Wilmet 2013-04-05 13:17:24 UTC
*** Bug 673760 has been marked as a duplicate of this bug. ***
Comment 4 Sébastien Wilmet 2013-04-06 16:22:26 UTC

*** This bug has been marked as a duplicate of bug 81880 ***