summary |
shortlog |
log |
commit | commitdiff |
tree
raw |
patch |
inline | side by side (from parent 1:
6744387)
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.
sel_spread(term);
} else if ((bcooked == MBT_SELECT && a == MA_DRAG) ||
(bcooked == MBT_EXTEND && a != MA_RELEASE)) {
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 &&
if (term->selstate == ABOUT_TO && poseq(term->selanchor, selpoint))
return;
if (bcooked == MBT_EXTEND && a != MA_DRAG &&