GNOME Bugzilla – Bug 683730
Unresponsive terminal on Shift, Click, Drag, release Shift, release Mouse
Last modified: 2014-04-06 18:15:39 UTC
Enable mouse mode, e.g. echo -n $'\e[?1000h' Hold down Shift, and highlight something by clicking and dragging the mouse. Release Shift first, and then release the mouse button. The terminal becomes unresposible (freezes) until a next major X Window event, such as focus leaving the terminal window.
Created attachment 223937 [details] [review] Proposed fix, hopefully has no side effects The problem is that _vte_terminal_maybe_end_selection() is not called when the release order is "unusual". Interestingly, this method is explicitly called on focus out. It's not a wise idea to check for Shift's state, or the mouse mode on release. Whatever values were used when clicking should still be used. I believe those are stored in vte->selecting and vte->selecting_after_threshold, on which _vte_terminal_maybe_end_selection() already branches to decide if proper action is required. So I think just removing the false conditions and always call this method solves the problem. I might be wrong though.
The idea has been to be able to change the selection mode while still dragging. Ie, you start selection, then remember that you wanted a block selection, you press ctrl and it works. Shift is a different situation though.
For that to work, you'd have to watch for Ctrl continuously, not just at release, because immediate visual feedback is required. That feature doesn't work now at all. My patch doesn't fix it and doesn't make it worse either.
Humm. I don't know who broke it. Used to work in GNOME2 days :).
The shift check has been there since http://git.gnome.org/browse/vte/commit/?id=af5726e0c546f9a4914dd80c03e11e1aadc034f2 (commit to fix bug 598124), but I don't see why it would be necessary here. Applying the patch doesn't seem to regress the bug, so I've applied the patch. Thanks! Fixed on 0-34 and next.