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 683730 - Unresponsive terminal on Shift, Click, Drag, release Shift, release Mouse
Unresponsive terminal on Shift, Click, Drag, release Shift, release Mouse
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.32.x
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
[fixed-next]
Depends on:
Blocks:
 
 
Reported: 2012-09-10 15:59 UTC by Egmont Koblinger
Modified: 2014-04-06 18:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed fix, hopefully has no side effects (796 bytes, patch)
2012-09-10 17:21 UTC, Egmont Koblinger
committed Details | Review

Description Egmont Koblinger 2012-09-10 15:59:36 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.
Comment 1 Egmont Koblinger 2012-09-10 17:21:43 UTC
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.
Comment 2 Behdad Esfahbod 2012-09-10 20:05:11 UTC
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.
Comment 3 Egmont Koblinger 2012-09-10 20:42:26 UTC
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.
Comment 4 Behdad Esfahbod 2012-09-10 21:00:51 UTC
Humm.  I don't know who broke it.  Used to work in GNOME2 days :).
Comment 5 Christian Persch 2012-10-12 20:07:32 UTC
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.