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 584342 - Shift key gets stuck
Shift key gets stuck
Status: RESOLVED FIXED
Product: meld
Classification: Other
Component: general
1.3.x
Other All
: Normal normal
: ---
Assigned To: Kai Willadsen
Stephen Kennedy
: 595518 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-05-31 10:38 UTC by Alexander Shaduri
Modified: 2010-03-01 09:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Possible workaround (1.60 KB, patch)
2010-02-26 01:20 UTC, Kai Willadsen
none Details | Review

Description Alexander Shaduri 2009-05-31 10:38:20 UTC
Please describe the problem:
When I'm comparing files with meld, if I press the shift key, the merge arrows turn into X signs and stay that way. Whatever I press, the X signs won't go away.
I have no special keyboard settings (no sticky keys, etc...).

Steps to reproduce:
1. Launch meld with two files.
2. Press one of the shift keys.
3. The the arrow signs change to X signs and get stuck that way.


Actual results:


Expected results:


Does this happen every time?
yes

Other information:
openSUSE 11.1 x86_64, xorg-x11-7.4, python-2.6.0, gtk2-2.16.1, python-gtk-2.12.1.

Here's the keyboard section of my xorg.conf:
Section "InputDevice"
        Driver          "kbd"
        Identifier      "keyboard_0"
        Option          "Protocol"              "Standard"
        Option          "XkbModel"              "microsoftpro"
        Option          "XkbRules"              "xfree86"
EndSection
Comment 1 Alexander Shaduri 2009-05-31 10:39:14 UTC
Sorry, forgot to add - this happens with both meld 1.2.1 and 1.3.0.
Comment 2 Kai Willadsen 2009-06-01 01:53:52 UTC
I can't reproduce this with 1.2.1, 1.3.0 or head. Does CTRL show similar behaviour (with the arrows changing to the plus and two-way copy arrows instead)?
Comment 3 Alexander Shaduri 2009-06-01 16:07:27 UTC
CTRL works like it should - releasing it changes the two-way arrows back to initial arrows.

I tried changing XkbModel to pc104, logging in with another user, using kde instead of Window Maker which I normally use, none of these helped.
I actually had the same problem with my previous distribution, openSUSE 10.3 (x86).
Comment 4 Vincent Legoll 2009-07-17 22:49:14 UTC
I've fixed a similar bug:
http://bugzilla.gnome.org/show_bug.cgi?id=579643

can you reproduce in another environment ?
different distribution, or version of python, Xorg, etc...
anything that can tell us that this is not specific to
your exact configuration.
Comment 5 Alexander Shaduri 2009-07-18 09:23:50 UTC
I applied the patches from http://bugzilla.gnome.org/show_bug.cgi?id=579643 to 1.3.0, but they didn't fix the problem.
As for another environment - I did have the exact same issue in openSUSE 10.3 i586 (xorg-x11-7.2, python-2.5.1, gtk2-2.12.11, python-gtk-2.12.1).
However, I could _not_ reproduce this problem with openSUSE 11.1 i586 (KDE4) under VMware Workstation.
Comment 6 Vincent Legoll 2009-07-18 09:30:40 UTC
could you try with "evdev" as your xorg keyboard driver instead of "kbd"
or without any xorg.conf
Comment 7 Alexander Shaduri 2009-07-18 09:54:29 UTC
Changing to evdev didn't help, but I think I found the problem after trying out about 10 different configurations.

The problematic line is:
Option          "XkbOptions"    "grp:shift_toggle,grp_led:scroll"  # switch layouts using 2 shifts
Once I remove it, the problem goes away.

I know that the xorg.conf snippet above doesn't contain this line. In fact, I think I added this line later, after filing this bug report. However, a similar effect could have been caused by the same settings in window manager at runtime, I guess (I remember trying with KDE4 and Window Maker with gnome-settings-daemon). Sorry for the screwup...

Anyway, now we know what causes the problem.
Comment 8 Vincent Legoll 2009-07-18 10:19:30 UTC
Thanks for the clarification, closing bug
Comment 9 Alexander Shaduri 2009-07-18 12:11:50 UTC
Umm, are you sure that marking as INVALID is the right thing to do?
I'm not the only one who uses double-shift as the layout switcher.
I remember KDE having that setting in its keyboard layout preferences, and I'm sure GNOME has something comparable. There are users out there who will have the same problem with meld. I haven't encountered any other program having this issue in my 10 years of using X, except for maybe tightvnc, but it fixed the problem in 1.3.8 or 1.3.9 I think.
Maybe there is a workaround or something...
Comment 10 Vincent Legoll 2009-07-18 12:31:18 UTC
Sorry your workaround description led me to think it was a configuration error

What is this setting doing ?
Is this making a press/release of shift toggle its status instead of the deefault behavior ?
Comment 11 Alexander Shaduri 2009-07-18 12:52:28 UTC
Well, the only thing the line
Option          "XkbOptions"    "grp:shift_toggle,grp_led:scroll"
does is that when it assigns two shifts as layout switcher (and lights up the scroll-lock led).
That is, if I press (and release) both Shifts simultaneously, the keyboard layout is switched (from "us" to "ru", for example).
Sometimes people use ctrl-shift or alt-shift for that, whichever's more comfortable to them. I (and many others) don't use ctrl-shift or alt-shift because it's too easy to press by mistake (when using some shortcuts, for example).

There are no other perceived differences from the user standpoint when using the Shift key. That is, the Shift key continues to do what it does, and works well.
Comment 12 Stephen Kennedy 2009-07-20 20:21:11 UTC
If you'd like to investigate further, it would be helpful to put debugging
prints into filediff.on_key_press_event and filediff.on_key_release_event
That's where the shift/ctrl/alt modifier states are computed.
Comment 13 Alexander Shaduri 2009-07-20 20:46:30 UTC
I did some debugging and found out that while shift press generates Shift_L (0xFFE1), shift release generates ISO_Prev_Group (0xFE0A). (I inserted "print event.keyval" at the beginning of those handlers).
No idea how to fix this in meld though. Maybe there's some X mechanism for determining the actual key released, or maybe that if grp:shift_toggle is on an therefore ISO_Prev_Group is actually shift?
Comment 14 Stephen Kennedy 2009-07-20 21:03:23 UTC
OK, the keypress asymmetry looks like a bug lower in the stack. Frankly
don't know anything about that.

However, perhaps you can work around it by adding ISO_Prev_Group to the
keylookup map (around line 58) with the value MASK_SHIFT. 
Comment 15 Alexander Shaduri 2009-08-02 10:16:25 UTC
This seems to be a known problem, see the GIMP bug:
http://bugzilla.gnome.org/show_bug.cgi?id=457288 ,

and xorg bug:
https://bugs.freedesktop.org/show_bug.cgi?id=7430

It seems to affect all the usual modifiers (alt, ctrl, shift), depending on the user settings for switching layouts. It also seems to be much more widespread than I thought, since international users are bound to have one of those layout switching settings.

The workaround you're suggesting won't work in case of alt and ctrl. That is, any modifier release can generate ISO_Prev_Group depending on user settings. It's just that mine happens to Shift because I use shift_toggle (there are also alt_toggle and ctrl_toggle out there). You won't be able to tell which modifier was released exactly.

Since the xorg bug seems to be more than 3 years old, I doubt it will be fixed soon.
The only solution I see so far is to add some kind of key configuration dialog to meld, which will allow the users to remap the default keys to their own layout-modified version (recording the key events for both press and release).
Comment 16 Kai Willadsen 2009-08-28 03:48:31 UTC
A key configuration dialog seems unnecessary, as it would only be there as a workaround for the bug. If there's no sensible way to fix the issue in Meld (and I imagine that the Gimp hackers would have found one if it existed) I'm tempted to mark this as NOTGNOME. Stephen?

Incidentally, I'd guess that Inkscape would also have the same issue. If not, then we could look at what they're doing.
Comment 17 Gabriel Schulhof 2009-09-16 16:17:17 UTC
This is happening for me as well. Both the Ctrl key gets stuck, and the Shift key gets stuck. There is no way to un-stick either, rendering meld useless.

I don't have any layout switching going on. Here's the output from xev when I press/relase Shift and when I press/release Ctrl:

KeyPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x1a7, subw 0x0, time 8092035, (73,-13), root:(79,81),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x3c00001,
    root 0x1a7, subw 0x0, time 8092107, (73,-13), root:(79,81),
    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x1a7, subw 0x0, time 8093507, (73,-13), root:(79,81),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x3c00001,
    root 0x1a7, subw 0x0, time 8093523, (73,-13), root:(79,81),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Despite this rather vanilla setup, it fails.
Comment 18 Gabriel Schulhof 2009-09-16 16:26:18 UTC
OK, in 1.3.1 there seems to be a workaround. Alt+Tab switches focus, and, looking at the code, the self.keymask is set to 0 in a bunch of places, like on_focus_change, and find-next, and so on. So, a workaround is to never search for anything, and hit find-next, or Alt+Tab, Alt+Tab.
Comment 19 Alexander Shaduri 2009-09-16 16:41:28 UTC
For me, the workaround seems to be right-clicking somewhere in the text so that the menu pops up. It resets the arrows state.
Comment 20 Gabriel Schulhof 2009-09-16 16:43:41 UTC
Upon further investigation, it seems that on_key_release_event located in filediff.py is not happening for me. I added print self.keymask to on_key_press_event, and it printed it, however, it printed nothing when I added the same thing to on_key_release_event

Perhaps someone somewhere needs to call gtk.Widget.add_events(gdk.KEY_RELEASE_MASK) ... I don't know if this is the right syntax, but it looks like this is missing.
Comment 21 Kai Willadsen 2009-09-16 20:32:43 UTC
As far as I know, GtkTextViews already subscribe to key-release events, otherwise this wouldn't work for anyone. It seems possible that this is a focus-related problem - does one of the textviews have focus when doing your testing?

Either way, if you're getting a key-release event from X, then this is a different bug altogether. Please open up a new bug report, and include distribution details, etc.
Comment 22 lukeletters 2009-09-24 04:25:57 UTC
*** Bug 595518 has been marked as a duplicate of this bug. ***
Comment 23 Kai Willadsen 2010-02-26 01:20:48 UTC
Created attachment 154728 [details] [review]
Possible workaround

This patch is an awful, terrible workaround. Essentially, it just clears our record of whatever keys are being held down whenever it sees ISO_Prev_Group.

On the upside, this shouldn't affect anyone *not* using layout switching. For people on layout switching, it's pretty easy to come up with cases where this doesn't work... but it's still better than where we are now. This should be fixed upstream, and when it is Meld should just magically work.

I've only tested this patch without layout switching (since I don't use it), so it needs testing by people who experience this bug. Please test (and try to break it a bit too) and leave a comment.
Comment 24 Alexander Shaduri 2010-02-26 09:06:51 UTC
I applied the patch to meld-1.3.1, seems to work perfectly! Ctrl and shift indicators are correctly reverted when I depress the keys. I'm not sure what other tests I can perform to break it.
I use two shifts as a layout switcher.
Comment 25 Kai Willadsen 2010-03-01 06:45:39 UTC
Well the easiest way to break it should be (I haven't tested this):
 - hold down Shift (X shows for delete mode)
 - while holding down Shift, also hold down Ctrl (X still showing)
 - release Shift
at which point, it *should* show the plus sign with two arrows for inserting chunks, but with the patch on affected systems, I expect that it will show the arrows for replace mode.

This isn't critical... it's just that it's not a perfect solution.
Comment 26 Kai Willadsen 2010-03-01 08:32:41 UTC
Since the patch seems low-risk, I've pushed it to HEAD. The fix will be available in the next release. Thanks for the bug report, and for tracking down the root cause.

Even though the solution isn't perfect, I'm closing this bug. If xkb ever gets a fix, we can just remove the workaround.
Comment 27 Alexander Shaduri 2010-03-01 09:04:10 UTC
(In reply to comment #25)
> Well the easiest way to break it should be (I haven't tested this):
>  - hold down Shift (X shows for delete mode)
>  - while holding down Shift, also hold down Ctrl (X still showing)
>  - release Shift
> at which point, it *should* show the plus sign with two arrows for inserting
> chunks, but with the patch on affected systems, I expect that it will show the
> arrows for replace mode.

Yes, this is the behavior I'm seeing. However, it's certainly infinitely better than what we had before (and I'm not sure why anyone would press those keys simultaneously anyway).

Thanks a lot for resolving this!