wezterm icon indicating copy to clipboard operation
wezterm copied to clipboard

Clicking on unfocused wezterm reports a mouse drag to client software

Open scy opened this issue 2 years ago • 0 comments

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

Windows

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

wezterm 20220814-222723-f2ee48bd

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

If the application running in wezterm has mouse reporting enabled, clicking a previously unfocused wezterm causes not only a click to be reported to the application, but also a drag event on the single cell that has been clicked. This will, for example, cause tmux to start a selection on that cell and end it on the same cell, possibly overwriting the clipboard.

To Reproduce

  1. Open a plain bash, not running in tmux or anything.
  2. Enable mouse reporting and track the reported control sequences: echo -e '\e[?1002;1005h'; hexdump -C
  3. Unfocus the window.
  4. Click in the top left cell of the pane. (To make extra sure that I did not move the mouse by clicking, I clicked using a tap on the trackpad.)
  5. If necessary, hit Enter a few times to make hexdump print a new line of output.

You should see the following three events being reported, which I have decoded for convenience:

1b 5b 4d 20 21 21  Button 1 pressed at 1,1
1b 5b 4d 40 21 21  Mouse moved to 1,1 with Button 1 pressed
1b 5b 4d 23 21 21  Mouse button released at 1,1

If you repeat the steps above without unfocusing the window, only two events will be reported: press and release.

Configuration

There is nothing relevant in my config, but if you want to, you can see its contents at the time of writing at https://codeberg.org/scy/dotfiles/src/commit/eee2586d3c585b9455ae5f9294805f005200a272/.config/wezterm/wezterm.lua.

Setting swallow_mouse_click_on_window_focus = true is a workaround, but not a good one: Now the first click on an unfocused window will not be reported to clients at all, which is cumbersome. But of course now there are no “unfocused” clicks anymore, so the bug does not appear.

Expected Behavior

Report only a “button press” and a “button release” event, without a “drag” in between.

Logs

Debug Overlay
wezterm version: 20220814-222723-f2ee48bd
OpenGL version: Intel(R) HD Graphics 630 4.5.0 - Build 27.20.100.8682
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
23:10:00.540 WARN wezterm_term::terminalstate > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(1005))
23:10:00.544 WARN wezterm_term::terminalstate::performer > unhandled ControlCode StartOfHeading
23:10:00.544 WARN wezterm_term::terminalstate::performer > unhandled ControlCode StartOfText

Warning seem unrelated.

Anything else?

No response

scy avatar Aug 15 '22 21:08 scy