[macOS, `INTEGRATED_BUTTONS`] Window is draggable while clicking to select a tab

[9999years]

Is your feature request related to a problem? Please describe. Wezterm lets you drag the titlebar to move the window (with config.window_decorations = "INTEGRATED_BUTTONS|RESIZE"). It also lets you click tabs to switch to them. Unfortunately, it lets you do both at the same time. As a result, I often notice Wezterm is a few pixels off the edge of my screen, because I accidentally dragged it while selecting a tab.

Describe the solution you'd like It should not be possible to drag the window by clicking on the tabs.

Describe alternatives you've considered This would also be solved if you needed to click quickly to switch to a tab (e.g. clicking and holding wouldn't select a tab, only clicking and quickly releasing). This would help disambiguate between clicking a tab and interacting with the window itself.

Additional context Related to dragging in the titlebar:

• #549

[9999years]

I added println!()s to wezterm-gui/src/termwindow/mod.rs and wezterm-gui/src/termwindow/mouseevent.rs, and none of the window dragging logic there is getting hit. I suspect there's something in macOS that handles window dragging automatically which has to be disabled for this to work correctly.

Here's the dragging code, as you can see it only activates when blank parts of the tab bar are clicked:

https://github.com/wezterm/wezterm/blob/6a493f88fab06a792308e0c704790390fd3c6232/wezterm-gui/src/termwindow/mouseevent.rs#L470-L492

[9999years]

Adding a mouseDownCanMoveWindow implementation returning NO to the WindowView implementation kind of works, except you can no longer drag the window at all when the window is maximized (not fullscreened). Here's a patch:

--- a/window/src/os/macos/window.rs
+++ b/window/src/os/macos/window.rs
@@ -3141,6 +3141,10 @@
         YES
     }
 
+    extern "C" fn mouse_down_can_move_window(this: &mut Object, _: Sel) -> BOOL {
+        NO
+    }
+
     fn get_this(this: &Object) -> Option<&mut Self> {
         unsafe {
             let myself: *mut c_void = *this.get_ivar(VIEW_CLS_NAME);
@@ -3432,6 +3436,10 @@
                 sel!(performDragOperation:),
                 Self::perform_drag_operation as extern "C" fn(&mut Object, Sel, id) -> BOOL,
             );
+            cls.add_method(
+                sel!(mouseDownCanMoveWindow),
+                Self::mouse_down_can_move_window as extern "C" fn(&mut Object, Sel) -> BOOL,
+            );
         }
 
         cls.register()

[kambala-decapitator]

FYI can't reproduce in the latest nightly on macOS 15.7.1 when trying to drag a tab, window is normal (not maximized). Dragging the tab region that has no tabs does drag the window, but that's ok and actually convenient.

[9999years]

@kambala-decapitator I can still reproduce with WezTerm-macos-20251014-193657-64f2907c on macOS Tahoe 26.0.1 (25A362), with ~/.config/wezterm/wezterm.lua set to:

return {
  window_decorations = "INTEGRATED_BUTTONS|RESIZE"
}

I'm curious what's different in your setup. I can drag the window from the tabs whether or not the window is maximized.

[kambala-decapitator]

I don't have window_decorations explicitly set. Isn't it a default value for a macos window? Or do those "integrated buttons" mean something special?

[9999years]

Yes, they mean something special! That's why they're mentioned in the first sentence of the report.

Without window_decorations set:

With config.window_decorations = "INTEGRATED_BUTTONS|RESIZE":

Many programs do something similar these days, putting tabs or other controls directly in the titlebar.

[kambala-decapitator]

sorry for the noise then :)

to me "integrated buttons" sounded like the default 3 window buttons are enabled (which is already the default)