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
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
This problem still apparent in f8, 2.6.23.1-49.fc8
This problem still apparent in f8, 2.6.23.1-137.fc8
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.
(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.
(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?
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.
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.
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
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.