Skip to content

fix(macos): restore titlebar double-click with hidden tab strip - #1866

Closed
jxdones wants to merge 1 commit into
raphamorim:mainfrom
jxdones:fix/macos-titlebar-double-click
Closed

fix(macos): restore titlebar double-click with hidden tab strip#1866
jxdones wants to merge 1 commit into
raphamorim:mainfrom
jxdones:fix/macos-titlebar-double-click

Conversation

@jxdones

@jxdones jxdones commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Closes #1786.

Summary

  • Route clicks in the hidden single-tab chrome through the existing window drag and double-click handler.
  • Use the default cursor over the reserved macOS chrome area.
  • Preserve the existing behavior on Linux and Windows.

Testing

  • cargo fmt --all -- --check
  • cargo test -p rioterm (183 passed)

@raphamorim raphamorim left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed against the padding and input routing paths. The core is right: with hide-if-single on macOS, padding_top_from_config reserves ISLAND_HEIGHT whenever Tab navigation is enabled (the render-from-top early return is non-macOS only), so the band really is dead chrome and routing its clicks through on_chrome_press restores drag and double-click maximize with the same state machine the visible island uses. The cursor gate also matches the padding predicate exactly, and NativeTab/Plain modes are untouched since is_enabled() is Tab-only.

Two small requests inline, and one note: the UCRT64 CI failure is not yours. Our new PR smoke lane built the whole workspace in debug, and the cdylib targets blow the PE export-ordinal limit on windows-gnu. Fixed on main; a re-run should come back green.

}

#[cfg(target_os = "macos")]
if !is_right_click {

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right-clicks here fall through to the grid, which starts below the band, so the click acts on the first terminal row while the pointer is over chrome. The visible-island path consumes right-clicks in its chrome regions (the x_in_tabs < 0 and past-last-tab arms return true without an action). Consuming them here too would keep the hidden band consistent with the visible one:

#[cfg(target_os = "macos")]
{
    if !is_right_click {
        self.on_chrome_press(window, chrome_press);
    }
    return true;
}

let num_tabs = route.window.screen.ctx().len();
let nav = &route.window.screen.renderer.navigation;
if nav.island_visible(num_tabs) && y <= island_height_px {
let custom_chrome_visible = nav.island_visible(num_tabs)

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This predicate now exists in three places that must agree: here, the new branch in screen/mod.rs, and padding_top_from_config, which is the drift island_visible's own doc comment warns about. A helper on Navigation would pin them together, something like:

/// Whether the top band is reserved as window chrome this frame,
/// painted island or not. Must agree with padding_top_from_config.
pub fn chrome_band_reserved(&self, num_tabs: usize) -> bool {
    if cfg!(target_os = "macos") {
        self.is_enabled()
    } else {
        self.island_visible(num_tabs)
    }
}

Then this line and the screen branch both call it, and the cfg in screen/mod.rs collapses into the same expression.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Double-click on title bar doesn't expand window to fill screen

2 participants