fix(window): restore macOS titlebar drag by bumping gpui past #58947 revert#155
Open
whizz wants to merge 1 commit into
Open
fix(window): restore macOS titlebar drag by bumping gpui past #58947 revert#155whizz wants to merge 1 commit into
whizz wants to merge 1 commit into
Conversation
…revert
The main window could not be dragged by the title bar on macOS. Root
cause was the pinned gpui revision, not our title-bar code.
okena was locked to gpui 8432a26 (2026-06-11), which sits inside the
3-day window where Zed's PR #58947 ("Fix title bar clicks being delayed
on macOS") was live before being reverted in #59214 (2026-06-12). That
patch implements the undocumented `_opaqueRectForWindowMoveWhenInTitlebar`
SPI and, for full-size-content windows (we use `appears_transparent:
true` -> `NSFullSizeContentViewWindowMask`), returns the entire view as
opaque app content. AppKit then treats no part of the window as a
draggable titlebar, so `window.start_window_move()` is a no-op. Zed hit
the same bug ("broke dragging the settings UI window") and reverted it.
Bump gpui to fca2ccd4 (one day forward, past the revert). Moving the
lock forward is always safe for this bug since the bad patch only ever
existed in that window.
The newer `util` crate (pulled in transitively by gpui) calls
`smol::process::Child::adopt_raw_pid`, which only exists in Zed's
async-process fork. `[patch]` entries from a git dependency do not
propagate, so mirror Zed's async-process/async-task patches in the
workspace manifest (revs matched to the pinned gpui commit).
Verified: all okena crates incl. okena-app compile against the new gpui,
and titlebar drag-to-move works on macOS.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On macOS the main window cannot be moved by dragging the title bar (clicking + dragging the titlebar does nothing). Minimize/maximize and the Window menu still work.
Root cause
Not our title-bar code — it's the pinned gpui revision.
okena was locked to gpui
8432a26(2026-06-11), which sits inside the 3-day window where Zed's #58947 ("Fix title bar clicks being delayed on macOS") was live before being reverted in #59214 (2026-06-12).That patch implements the undocumented
_opaqueRectForWindowMoveWhenInTitlebarSPI on gpui's macOS Metal view. For full-size-content windows — which we are, viaappears_transparent: true→NSFullSizeContentViewWindowMask— it returns the entire view bounds as opaque app content. AppKit then treats no part of the window as a draggable titlebar, sowindow.start_window_move()becomes a no-op. Zed hit the exact same bug ("broke dragging the settings UI window") and reverted it the next business day.Fix
8432a26→fca2ccd4(one day forward, past the revert). Moving the lock forward is always safe for this bug since the bad patch only ever existed in that 3-day window.utilcrate (transitive via gpui) now callssmol::process::Child::adopt_raw_pid, which only exists in Zed'sasync-processfork.[patch]entries from a git dependency don't propagate, so mirror Zed'sasync-process/async-taskpatches in the workspace manifest (revs matched to the pinned gpui commit).No Rust source changed — only
Cargo.toml(+[patch.crates-io]) andCargo.lock.Verification
cargo check --workspace— all okena crates incl.okena-appcompile against the new gpui.Note for builders
Building gpui needs the Metal compiler. On a machine where
xcode-select -ppoints at CommandLineTools, the shader build fails; select full Xcode (sudo xcode-select -s /Applications/Xcode.app) and, on Xcode 26, install the Metal Toolchain component (xcodebuild -downloadComponent MetalToolchain).