This service will be undergoing maintenance at 03:30 UTC, 2016-05-27. It is expected to last about 2 hours

Bug 327311

Summary: Pasting into gnome terminal with CTRL-SHIFT-V unreliable
Product: [Fedora] Fedora Reporter: David Campbell <david>
Component: gnome-terminalAssignee: Behdad Esfahbod <behdad>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8CC: mszpak, snecklifter
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-09 02:18:54 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description David Campbell 2007-10-11 02:56:42 EDT
Description of problem:

Pasting into gnome terminal with CTRL-SHIFT-V usually works, but sometimes,
gnome terminal gets into a strange state where pressing CTRL-SHIFT-V does not
paste even though choosing paste from the edit menu works fine.  Choosing a pull
down menu item that opens a window seems to get gnome terminal out of this state.

Version-Release number of selected component (if applicable):

Gnome terminal 2.18.1

How reproducible:

Intermittently, but it shows up most days for me.

Steps to Reproduce:
1. Copy some text from somwhere
2. Attempt to paste into gnome terminal with CTRL-SHIFT-V
 
Actual results:

Usually this works but sometimes for some unknown reason, gnome terminal treats
it as a CTRL-V and does it consistently, and it isn't my keyboard at fault.
If I choose Edit/Paste from the menu, the paste works just fine.

When this problem happens, I've found a work around that makes it go away.  If I
 choose something from the pull down menus, eg I use Edit/Profiles and then
click close.  Having done that, the problem is gone, and paste with CTRL-SHIFT-V
works again.

Expected results:

It should always work
Comment 1 David Campbell 2007-10-18 18:53:13 EDT
This happens with both the metacity and compiz window managers.

I captured this happening with xwininfo and xev.  Details below.

You can see from the below that left CTRL and left SHIFT are being pressed and
then a number of times I press the V key and it is interpreting it as CTRL-V,
not CTRL-SHIFT-V.

Immediately after the following events, I selected Edit/Paste from the menu and
the previously copied content immediately pasted in, indicating that the content
was ready to paste which was failing to paste with CTRL-SHIFT-V.

There is clearly something wrong here.

KeyPress event, serial 19, synthetic NO, window 0x4c00020,
    root 0x4d, subw 0x0, time 3041136251, (81,-10), root:(835,44),
    state 0x2, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

PropertyNotify event, serial 19, synthetic NO, window 0x4c00020,
    atom 0x123 (_NET_WM_USER_TIME), time 3041136252, state PropertyNewValue

KeyPress event, serial 19, synthetic NO, window 0x4c00020,
    root 0x4d, subw 0x0, time 3041137348, (81,-10), root:(835,44),
    state 0x3, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

PropertyNotify event, serial 19, synthetic NO, window 0x4c00020,
    atom 0x123 (_NET_WM_USER_TIME), time 3041137348, state PropertyNewValue

KeyPress event, serial 19, synthetic NO, window 0x4c00020,
    root 0x4d, subw 0x0, time 3041139160, (81,-10), root:(835,44),
    state 0x7, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (16) ""
    XmbLookupString gives 1 bytes: (16) ""
    XFilterEvent returns: False
^
PropertyNotify event, serial 19, synthetic NO, window 0x4c00020,
    atom 0x123 (_NET_WM_USER_TIME), time 3041139161, state PropertyNewValue

KeyRelease event, serial 19, synthetic NO, window 0x4c00020,
    root 0x4d, subw 0x0, time 3041139223, (81,-10), root:(835,44),
    state 0x7, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (16) ""
    XFilterEvent returns: False

KeyPress event, serial 19, synthetic NO, window 0x4c00020,
    root 0x4d, subw 0x0, time 3041142633, (81,-10), root:(835,44),
    state 0x7, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (16) ""
    XmbLookupString gives 1 bytes: (16) ""
    XFilterEvent returns: False
^V
PropertyNotify event, serial 19, synthetic NO, window 0x4c00020,
    atom 0x123 (_NET_WM_USER_TIME), time 3041142633, state PropertyNewValue

KeyRelease event, serial 19, synthetic NO, window 0x4c00020,
    root 0x4d, subw 0x0, time 3041142775, (81,-10), root:(835,44),
    state 0x7, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (16) ""
    XFilterEvent returns: False

KeyPress event, serial 19, synthetic NO, window 0x4c00020,
    root 0x4d, subw 0x0, time 3041149194, (81,-10), root:(835,44),
    state 0x7, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (16) ""
    XmbLookupString gives 1 bytes: (16) ""
    XFilterEvent returns: False
^
PropertyNotify event, serial 19, synthetic NO, window 0x4c00020,
    atom 0x123 (_NET_WM_USER_TIME), time 3041149195, state PropertyNewValue

KeyRelease event, serial 19, synthetic NO, window 0x4c00020,
    root 0x4d, subw 0x0, time 3041149358, (81,-10), root:(835,44),
    state 0x7, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (16) ""
    XFilterEvent returns: False

KeyPress event, serial 19, synthetic NO, window 0x4c00020,
    root 0x4d, subw 0x0, time 3041150258, (81,-10), root:(835,44),
    state 0x7, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (16) ""
    XmbLookupString gives 1 bytes: (16) ""
    XFilterEvent returns: False
^V
PropertyNotify event, serial 19, synthetic NO, window 0x4c00020,
    atom 0x123 (_NET_WM_USER_TIME), time 3041150258, state PropertyNewValue

KeyRelease event, serial 19, synthetic NO, window 0x4c00020,
    root 0x4d, subw 0x0, time 3041150389, (81,-10), root:(835,44),
    state 0x7, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (16) ""
    XFilterEvent returns: False

KeyRelease event, serial 19, synthetic NO, window 0x4c00020,
    root 0x4d, subw 0x0, time 3041152140, (81,-10), root:(835,44),
    state 0x7, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 19, synthetic NO, window 0x4c00020,
    root 0x4d, subw 0x0, time 3041152167, (81,-10), root:(835,44),
    state 0x6, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Comment 2 David Campbell 2007-11-22 19:06:13 EST
This problem still apparent in f8, 2.6.23.1-49.fc8
Comment 3 David Campbell 2008-02-25 18:35:19 EST
This problem still apparent in f8, 2.6.23.1-137.fc8
Comment 4 Christopher Brown 2008-02-26 17:23:25 EST
Sadly David, the somewhat pedantic gnome-terminal often requires:

SHIFT+CTRL+v (Hold Shift, the Control, then V)

as opposed to:

CTRL+SHIFT+v

Note it does indicate this order in the shortcut hint when selecting the Edit
menu. Please could you test this as this has always worked fine for me here.
Comment 5 Behdad Esfahbod 2008-02-26 17:35:25 EST
(In reply to comment #4)
> Sadly David, the somewhat pedantic gnome-terminal often requires:
> 
> SHIFT+CTRL+v (Hold Shift, the Control, then V)
> 
> as opposed to:
> 
> CTRL+SHIFT+v
> 
> Note it does indicate this order in the shortcut hint when selecting the Edit
> menu. Please could you test this as this has always worked fine for me here.

That's not true.  Both work for me.  If what you are saying is indeed the case,
it's not a g-t bug.  Something like an X or GTK+ bug maybe.
Comment 6 Christopher Brown 2008-02-26 18:00:43 EST
(In reply to comment #5)

> That's not true.

It is for me.

> Both work for me.

Not for me they don't. As with David, they are unreliable.

> If what you are saying is indeed the case,
> it's not a g-t bug.  Something like an X or GTK+ bug maybe.

You are free to change component then. David, do you have a test case to
replicate this?
Comment 7 David Campbell 2008-02-26 18:31:34 EST
How can this be an X or GTK bug given that the xev capture I posted above
reports that the events are coming through?

Chris I normally use CTRL-SHIFT-v to past rather than SHIFT-CTRL-v.  It normally
works, but it breaks sometimes.  Next time it happens I'll try to see whether
SHIFT-CTRL-v works.

I find that the behaviour varies and I don't have a test case to reproduce. 
However I used CTRL-SHIFT-v all the time and this problem happens every day,
usually multiple times.  Once the problem happens it tends to stay UNTIL I
choose something (anything) from the gnome-terminal menus.  Then it goes away.

Perhaps try doing that on your system and see if CTRL-SHIFT-v starts working for
you.
Comment 8 Christopher Brown 2008-02-27 02:03:51 EST
Yes, I do exactly as you do and use Edit>Paste which works. I'm afraid its just
an mild annoyance that I have never gotten round to filing a bug about. Anyway,
I didn't see the correlation between using Edit>Paste and the paste function
beginning to work again however. As its sporadic its difficult to see how to
resolve it but I will pay a bit more attention next time it happens.

I know that it won't work in embedded emacs for example (start emacs from the
commands line using emacs -nw $file_to_edit) as emacs takes over key commands.
Comment 9 Bug Zapper 2008-11-26 02:57:10 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Bug Zapper 2009-01-09 02:18:54 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.