Sorry, forgot to add - this happens with both meld 1.2.1 and 1.3.0.

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)?

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).

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.

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.

could you try with "evdev" as your xorg keyboard driver instead of "kbd"
or without any xorg.conf

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.

Thanks for the clarification, closing bug

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...

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 ?

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.

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.

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?

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. 

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).

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.

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.

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.

For me, the workaround seems to be right-clicking somewhere in the text so that the menu pops up. It resets the arrows state.

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.

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.

*** Bug 595518 has been marked as a duplicate of this bug. ***

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.

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.

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.

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.

(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!