Cannot start selecting text on inactive window

[cbirchinger]

What Operating System(s) are you seeing this problem on?

Linux X11

WezTerm version

20220110-083110-5d52902b

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

When a WezTerm window is inactive i cannot click and then drag to mark text. I have to first click to activate the window,
then release the mouse button and then click and drag to get Text marked.

Every GUI application including terminals allows me to click (to activate) into an inactive window and then drag the mouse to select text without needing to release the mouse button first. The same applies to double or triple clicking text for world or whole line selecting. Clicking URLs also require to click first to focus and then click again to open the URs, even though the underline when hovering over a link shows up suggesting a single click would open the URL right away.

At least on Linux X11 XFCE it is the standard to not fully swallow the initial focus click. Maybe people on MacOS are used to a different behavior.

The fix for Issue #1310 has probably caused this non-standard behavior on my systems. I know it sounds really minor, it but completely breaks my work flow., when i need to do an initial click that no other program ever required.

To avoid conflicts between different desktop behaviors like the issue reported in #1310 , maybe a true/false configuration option would be the best solution.

To Reproduce

Click into an inactive window, then drag the mouse to select text. Nothing gets selected until the mouse button is released and pressed again.

Configuration

No config that i have found is related to this behavior. "swallow_mouse_click_on_pane_focus" doesn't matter when activating the window itself.

Expected Behavior

Marking text should not required to have the mouse button released first and then clicked again

Logs

No response

Anything else?

No response

[rosshadden]

Yeah it's funny that the terminal doing what I would expect was filed as an issue. Obviously people have different expectations! Maybe this could be configurable?

[cbirchinger]

I've built the terminal with the function from before the #1310 fix and noticed that it didn't start marking where the initial click was but at some arbitrary position somewhere in the middle of the window. It immediately selected around 20 lines. I understand, that's not something anyone would want.

Of course the marking should start exactly where the mouse pointer is when you start clicking, even on a previously inactive window..

[bew]

I think #1310 was a real bug.
The next change about the behavior for inactive window was for #1437 (from me).
It covers click & scroll events, but not click-and-drag event.
I'm not sure what I'd like for this.. I guess having it passed through (for selection or program use) is viable for me.

Having it configurable would help.
Maybe something like:

return {
  inactive_window_mouse_bindings = {
    {
      event={Down={streak=1, button="Right"}},
      mods="NONE",
      action="FocusPane",
    },
    {
      event={Drag={streak=1, button="Right"}},
      mods="NONE",
      action=wezterm.action{Multiple={"FocusPane", "SendLastMouseEvent"}},
    },
  },
}

With new actions like FocusPane and SendLastMouseEvent.
(maybe too flexible..)

[cbirchinger]

Yes, #1310 was definitely a bug, because the text marking did not start where the pointer is but from some random position.

[ahollandECS]

Probably a subset of this issue, when pasting into a terminal which does not have focus using a binding on the mouse, it takes two clicks (one to focus the window, one to paste). I would expect it to happen on the first click.

[wez]

I think this is resolved now in main. I've added a separate option to control the window focus behavior. Please let me know how this works for you! It should show up in the nightly builds within an hour of posting this comment.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.