fix(tabs): on a maximized window, the screen's top edge selects the tab - #826
Merged
Merged
Conversation
Tabs are 28px in a 36px title bar, and the 4px strip above each tab is window drag region. On a maximized window that strip is the screen's top edge, so flicking the mouse to the top and clicking moved the window instead of picking the tab (#823). When the window is maximized on Windows or Linux, each tab's wrapper now spans the full bar height and a click on it outside the tab selects that tab. Chrome on Windows does the same. The tab looks the same. Restored windows keep the strip as drag region, and macOS is left alone because its menu bar sits above a maximized window.
PathGao
added a commit
that referenced
this pull request
Sep 22, 2026
#826 stretched each tab's wrapper over the full bar height, so both the strip above the tab and the one below it picked the tab. Only the top strip is the screen edge #823 was about. The bottom strip is mid-screen, gained nothing from the change, and lost its use as a place to grab the maximized window. The wrapper now reaches from the screen edge down to the tab's bottom, and the strip below the tab is drag region again. Co-authored-by: PathGao <gaoyanbo@gaoyanbodeMacBook-Air.local>
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
1 participant
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.
Closes #823, reported by @SamHasler.
Tabs are 28px in the 36px title bar, centred, so a 4px strip sits above each tab. That strip is the tab list container itself, which carries
data-tauri-drag-region, so Tauri's drag script starts a window drag there. On a maximized window the strip is the screen's top edge, and a flick to the top grabs the window instead of the tab.When the window is maximized on Windows or Linux, each tab's wrapper now spans the full bar height, and a click on it outside the tab selects that tab. This matches Chrome on Windows. The tab looks the same.
TitleBartracks the maximized state withisMaximized()ononResizedand sets amaximizedclass. The drag proxy now measures the tab, not the taller wrapper.Left alone: restored windows keep the strip as drag region, so users can still drag the window from above a tab. macOS is untouched because a maximized window sits below the menu bar and its tabs never reach the screen edge.
No test added. This is CSS plus a click forward, and a source-text test would pin today's spelling rather than the behaviour.
npm test1034 pass,vitest445 pass,npm run check0 errors. Not run on Windows or Linux. I only have macOS, where the change is gated off.