From 30e63c1059ff306fc086570967b914294c72ae65 Mon Sep 17 00:00:00 2001 From: Simon Tatham Date: Thu, 3 Sep 2015 19:20:28 +0100 Subject: [PATCH] Ignore mouse events that didn't start with a click. 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 | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/terminal.c b/terminal.c index 590f456a..fabfce11 100644 --- a/terminal.c +++ b/terminal.c @@ -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 && -- 2.45.2