]> asedeno.scripts.mit.edu Git - PuTTY.git/commitdiff
Ignore mouse events that didn't start with a click.
authorSimon Tatham <anakin@pobox.com>
Thu, 3 Sep 2015 18:20:28 +0000 (19:20 +0100)
committerSimon Tatham <anakin@pobox.com>
Thu, 3 Sep 2015 18:35:06 +0000 (19:35 +0100)
On OS X GTK, when you click in a pterm that wasn't the active window,
the first click activates it but is swallowed by the windowing system
- but a subsequent tiny drag can still be taken as part of a selection
action, making it difficult to activate the window in order to paste
into it.

Fixed by ignoring mouse drags when the terminal.c mouse state was
NO_SELECTION; if we've seen one prior click then it should be
ABOUT_TO, or DRAGGING if we saw a double or triple click.

terminal.c

index 590f456a2b1110402af170a9b7fd8ca7dffd9b79..fabfce1144707d824537153c00ebe16f755b52a1 100644 (file)
@@ -6078,6 +6078,18 @@ void term_mouse(Terminal *term, Mouse_Button braw, Mouse_Button bcooked,
        sel_spread(term);
     } else if ((bcooked == MBT_SELECT && a == MA_DRAG) ||
               (bcooked == MBT_EXTEND && a != MA_RELEASE)) {
+        if (term->selstate == NO_SELECTION || term->selstate == SELECTED) {
+            /*
+             * This can happen if a front end has passed us a MA_DRAG
+             * without a prior MA_CLICK. OS X GTK does so, for
+             * example, if the initial button press was eaten by the
+             * WM when it activated the window in the first place. The
+             * nicest thing to do in this situation is to ignore
+             * further drags, and wait for the user to click in the
+             * window again properly if they want to select.
+             */
+            return;
+        }
        if (term->selstate == ABOUT_TO && poseq(term->selanchor, selpoint))
            return;
        if (bcooked == MBT_EXTEND && a != MA_DRAG &&