Mouse text selection issue with multiple windows

[zaps]

Overview

When at least 2 windows are open, text selection with mouse does not work properly.

Steps to Reproduce

1. Open Alacritty
2. Put some text on the screen
3. Open a new window via CreateNewWindow (I have it bound to Command-N)
4. Put some text in the new window
5. Select any section of text with the mouse

Expected Behavior

The text is selected by the mouse at the location of the cursor

Actual Behavior

The text 2 lines above the location of the cursor is selected

Workaround

Don't use multiple windows

Demo

System

OS: macOS Big Sur 11.6.3 (20G415) Version: alacritty 0.10.0 (8a26dee)

Logs

Crashes: n/a Font/Terminal size: alacritty -vv Keyboard and bindings: alacritty --print-events

[kchibisov]

I'd assume it works when it's not tabbed? I mean when you have multiple windows, but you don't tab them.

[zaps]

I'd assume it works when it's not tabbed? I mean when you have multiple windows, but you don't tab them.

Correct—multiple non-tabbed windows do not have the issue.

[chrisduerr]

Which macOS version is this?

[zaps]

Which macOS version is this?

Big Sur 11.6.3 (20G415) on an Intel Mac (2019)

[chrisduerr]

Just tested this and the top of the window is also cut-off. So it's indeed pretty broken.

[megabug]

I'd assume it works when it's not tabbed? I mean when you have multiple windows, but you don't tab them.

Correct—multiple non-tabbed windows do not have the issue.

It also seems to happen on fullscreen non-tabbed windows though, albeit with less of an offset to the selection.

[chrisduerr]

At least for tabbed windows a workaround seems to be to resize the window after creating a new tab. At least that worked for me.

[zaps]

At least for tabbed windows a workaround seems to be to resize the window after creating a new tab.

Can confirm—works for me too

[zaps]

Weirdly, on my M1 Mac (Monterey, 12.1), CreateNewWindow actually creates a new window, and not a new tab in the same window. Not sure if this is a different issue.

[chrisduerr]

Weirdly, on my M1 Mac (Monterey, 12.1), CreateNewWindow actually creates a new window, and not a new tab in the same window. Not sure if this is a different issue.

It depends on a macOS setting and the existence of decorations if a new tab or window will be opened.

[sshock]

Did some digging and the issue appears to be due to glutin / winit 1. not sending a WindowEvent::Resized sometimes when a new tabbed window is created (like if it's never been resized), and 2. even when it does send it it is often wrong and includes the size of the tabs area.

I don't know if you would want to adopt this, but here's the workaround I came up with:

diff --git a/alacritty/src/event.rs b/alacritty/src/event.rs
index 6a14097a..5d172540 100644
--- a/alacritty/src/event.rs
+++ b/alacritty/src/event.rs
@@ -1096,7 +1096,14 @@ impl input::Processor<EventProxy, ActionContext<'_, Notifier, EventProxy>> {
                 },
                 EventType::ConfigReload(_) | EventType::CreateWindow(_) => (),
             },
-            GlutinEvent::RedrawRequested(_) => *self.ctx.dirty = true,
+            GlutinEvent::RedrawRequested(_) => {
+                #[cfg(target_os = "macos")]
+                {
+                    let size = self.ctx.window().inner_size();
+                    self.ctx.display.pending_update.set_dimensions(size);
+                }
+                *self.ctx.dirty = true;
+            },
             GlutinEvent::WindowEvent { event, .. } => {
                 match event {
                     WindowEvent::CloseRequested => self.ctx.terminal.exit(),
@@ -1110,6 +1117,12 @@ impl input::Processor<EventProxy, ActionContext<'_, Notifier, EventProxy>> {
                         }

                         self.ctx.display.pending_update.set_dimensions(size);
+                        #[cfg(target_os = "macos")]
+                        {
+                            let actual_size = self.ctx.window().inner_size();
+                            self.ctx.display.pending_update.set_dimensions(actual_size);
+                        }
+
                         *self.ctx.dirty = true;
                     },
                     WindowEvent::KeyboardInput { input, is_synthetic: false, .. } => {

[kchibisov]

Sorry, seems like I forgot to link to upstream. I've described whats needs doing here https://github.com/rust-windowing/winit/issues/2191

[kchibisov]

So if you feel like fixing it, it's a matter of plumbing it in winit. Shouldn't be that hard if there's desire to fix it on macOS.

[sshock]

Thank @kchibisov. I'm new to rust and am unfamiliar with winit, but I may give it a try if no one beats me to it.

[chrisduerr]

If you need help, I'm sure there'll be some people around on the #alacritty or #winit IRC (winit is also a Matrix room) to answer potential question.

[sshock]

Fixed upstream: https://github.com/rust-windowing/winit/pull/2239

[chrisduerr]

Thanks for letting us know. Should be in Alacritty with the next winit version then.

[Programatic]

I would like to add, that this mouse text select issue occurs with me on my Arch Linux machine running Sway. I haven't spent time seeing if this is entirely related, but I will update after the next version comes out to see if this fixes it as well. Thanks for all the hard work y'all :)