Repository navigation
fix: give the tab bar a real window-drag region - #521
Merged
Merged
Conversation
The window has no native title bar (hiddenInset), so the tab bar IS the
header — but its no-drag opt-out sat on the flex-1 tab-list container,
which spans every pixel right of the traffic lights. Result: the empty
bar right of the "+" button (most of the row) was neither clickable nor
draggable, and the only drag zone was the traffic-light spacer. That
spacer's width arrives over IPC on ready-to-show/resize only, so after
any renderer reload it collapsed to 0 — leaving the window with zero
draggable header pixels ("I can't move the app", post-#517
investigation; the reverted overlay feature got blamed but this was
pre-existing).
Two changes:
- no-drag moves from the tab-list container to each interactive child
(tabs, + button), so all empty tab-bar space drags the window —
Chrome tab-strip semantics.
- main re-pushes the traffic-light inset on did-finish-load so a
renderer reload can't strand the spacer at 0.
Co-Authored-By: Claude Fable 5 <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.
Symptom
"The app has no header" — the window can't be moved by grabbing the top bar, or only via a tiny weird hitbox. Surfaced during the overlay incident, but this is pre-existing on main and unrelated to the reverted feature (#517): the running build was verified overlay-free and the symptom persisted.
Root cause (two compounding bugs)
TabBar.tsxput[-webkit-app-region:no-drag]on the flex-1 tab-list container, which spans everything right of the traffic lights. The empty strip right of the+button — most of the header on a typical 1–3-tab window — was completely dead: not interactive, not draggable.ready-to-show/resizeonly). After any renderer reload (Cmd+R, crash recovery) it stays0until a manual resize — zero draggable pixels total.Fix
no-dragmoves to the interactive children (each tab, the+button); the container inherits drag from the bar. Empty tab-bar space now drags the window, exactly like Chrome's tab strip.did-finish-load, so reloads can't strand the spacer at 0 (this also fixes tabs sliding under the traffic lights after Cmd+R).Verification
npm run build && npm start(preview runs fromout/— a staleout/was part of tonight's confusion) ornpm run dev, then drag the empty area of the tab bar.🤖 Generated with Claude Code