Fix active-pane border rendered too far below the pane's top - #4
Merged
Merged
Conversation
preferredTmuxWorkspacePaneWindowOverlayRect() validated the live ("exact")
pane rect against the chrome-trimmed layout estimate, which assumes every
pane's tab-strip chrome is topChromeHeight (28pt, ~2 terminal rows) tall.
Single-tab panes hide that tab strip, so their real content starts right at
the pane's top -- higher than the trimmed estimate -- which made the check
reject the accurate exact rect and fall back to the over-trimmed one,
rendering the active-pane border (and unread/flash rings) ~2 rows below the
pane's true top edge.
Add TmuxPaneOverlayGeometry.rawWindowOverlayRect(), an untrimmed variant of
windowOverlayRect(), and validate the exact rect against it instead.
MarvinZeising
added a commit
that referenced
this pull request
Aug 4, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 4, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 4, 2026
preferredTmuxWorkspacePaneWindowOverlayRect() validated the live ("exact")
pane rect against the chrome-trimmed layout estimate, which assumes every
pane's tab-strip chrome is topChromeHeight (28pt, ~2 terminal rows) tall.
Single-tab panes hide that tab strip, so their real content starts right at
the pane's top -- higher than the trimmed estimate -- which made the check
reject the accurate exact rect and fall back to the over-trimmed one,
rendering the active-pane border (and unread/flash rings) ~2 rows below the
pane's true top edge.
Add TmuxPaneOverlayGeometry.rawWindowOverlayRect(), an untrimmed variant of
windowOverlayRect(), and validate the exact rect against it instead.
MarvinZeising
added a commit
that referenced
this pull request
Aug 5, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 5, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 5, 2026
preferredTmuxWorkspacePaneWindowOverlayRect() validated the live ("exact")
pane rect against the chrome-trimmed layout estimate, which assumes every
pane's tab-strip chrome is topChromeHeight (28pt, ~2 terminal rows) tall.
Single-tab panes hide that tab strip, so their real content starts right at
the pane's top -- higher than the trimmed estimate -- which made the check
reject the accurate exact rect and fall back to the over-trimmed one,
rendering the active-pane border (and unread/flash rings) ~2 rows below the
pane's true top edge.
Add TmuxPaneOverlayGeometry.rawWindowOverlayRect(), an untrimmed variant of
windowOverlayRect(), and validate the exact rect against it instead.
MarvinZeising
added a commit
that referenced
this pull request
Aug 5, 2026
tmuxWorkspacePaneExactRect's panel-type switch only handled TerminalPanel and BrowserPanel; every other panel type (notably AgentSessionPanel) fell to the default nil case, so the exact-rect correction from #4 never applied and the active-pane border in a split still used the chrome-trimmed estimate, reproducing the same ~2-row offset #4 fixed for terminals. Expose hostedView on AgentSessionPanel (forwarding through AgentSessionWebRendererSession to the bound WKWebView), matching the existing hostedView/webView pattern on TerminalPanel/BrowserPanel, and add it to the switch.
MarvinZeising
added a commit
that referenced
this pull request
Aug 6, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 6, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 6, 2026
preferredTmuxWorkspacePaneWindowOverlayRect() validated the live ("exact")
pane rect against the chrome-trimmed layout estimate, which assumes every
pane's tab-strip chrome is topChromeHeight (28pt, ~2 terminal rows) tall.
Single-tab panes hide that tab strip, so their real content starts right at
the pane's top -- higher than the trimmed estimate -- which made the check
reject the accurate exact rect and fall back to the over-trimmed one,
rendering the active-pane border (and unread/flash rings) ~2 rows below the
pane's true top edge.
Add TmuxPaneOverlayGeometry.rawWindowOverlayRect(), an untrimmed variant of
windowOverlayRect(), and validate the exact rect against it instead.
MarvinZeising
added a commit
that referenced
this pull request
Aug 6, 2026
tmuxWorkspacePaneExactRect's panel-type switch only handled TerminalPanel and BrowserPanel; every other panel type (notably AgentSessionPanel) fell to the default nil case, so the exact-rect correction from #4 never applied and the active-pane border in a split still used the chrome-trimmed estimate, reproducing the same ~2-row offset #4 fixed for terminals. Expose hostedView on AgentSessionPanel (forwarding through AgentSessionWebRendererSession to the bound WKWebView), matching the existing hostedView/webView pattern on TerminalPanel/BrowserPanel, and add it to the switch.
MarvinZeising
added a commit
that referenced
this pull request
Aug 7, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 7, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 7, 2026
preferredTmuxWorkspacePaneWindowOverlayRect() validated the live ("exact")
pane rect against the chrome-trimmed layout estimate, which assumes every
pane's tab-strip chrome is topChromeHeight (28pt, ~2 terminal rows) tall.
Single-tab panes hide that tab strip, so their real content starts right at
the pane's top -- higher than the trimmed estimate -- which made the check
reject the accurate exact rect and fall back to the over-trimmed one,
rendering the active-pane border (and unread/flash rings) ~2 rows below the
pane's true top edge.
Add TmuxPaneOverlayGeometry.rawWindowOverlayRect(), an untrimmed variant of
windowOverlayRect(), and validate the exact rect against it instead.
MarvinZeising
added a commit
that referenced
this pull request
Aug 7, 2026
tmuxWorkspacePaneExactRect's panel-type switch only handled TerminalPanel and BrowserPanel; every other panel type (notably AgentSessionPanel) fell to the default nil case, so the exact-rect correction from #4 never applied and the active-pane border in a split still used the chrome-trimmed estimate, reproducing the same ~2-row offset #4 fixed for terminals. Expose hostedView on AgentSessionPanel (forwarding through AgentSessionWebRendererSession to the bound WKWebView), matching the existing hostedView/webView pattern on TerminalPanel/BrowserPanel, and add it to the switch.
MarvinZeising
added a commit
that referenced
this pull request
Aug 8, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 8, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 8, 2026
preferredTmuxWorkspacePaneWindowOverlayRect() validated the live ("exact")
pane rect against the chrome-trimmed layout estimate, which assumes every
pane's tab-strip chrome is topChromeHeight (28pt, ~2 terminal rows) tall.
Single-tab panes hide that tab strip, so their real content starts right at
the pane's top -- higher than the trimmed estimate -- which made the check
reject the accurate exact rect and fall back to the over-trimmed one,
rendering the active-pane border (and unread/flash rings) ~2 rows below the
pane's true top edge.
Add TmuxPaneOverlayGeometry.rawWindowOverlayRect(), an untrimmed variant of
windowOverlayRect(), and validate the exact rect against it instead.
MarvinZeising
added a commit
that referenced
this pull request
Aug 8, 2026
tmuxWorkspacePaneExactRect's panel-type switch only handled TerminalPanel and BrowserPanel; every other panel type (notably AgentSessionPanel) fell to the default nil case, so the exact-rect correction from #4 never applied and the active-pane border in a split still used the chrome-trimmed estimate, reproducing the same ~2-row offset #4 fixed for terminals. Expose hostedView on AgentSessionPanel (forwarding through AgentSessionWebRendererSession to the bound WKWebView), matching the existing hostedView/webView pattern on TerminalPanel/BrowserPanel, and add it to the switch.
MarvinZeising
added a commit
that referenced
this pull request
Aug 9, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 9, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 9, 2026
preferredTmuxWorkspacePaneWindowOverlayRect() validated the live ("exact")
pane rect against the chrome-trimmed layout estimate, which assumes every
pane's tab-strip chrome is topChromeHeight (28pt, ~2 terminal rows) tall.
Single-tab panes hide that tab strip, so their real content starts right at
the pane's top -- higher than the trimmed estimate -- which made the check
reject the accurate exact rect and fall back to the over-trimmed one,
rendering the active-pane border (and unread/flash rings) ~2 rows below the
pane's true top edge.
Add TmuxPaneOverlayGeometry.rawWindowOverlayRect(), an untrimmed variant of
windowOverlayRect(), and validate the exact rect against it instead.
MarvinZeising
added a commit
that referenced
this pull request
Aug 9, 2026
tmuxWorkspacePaneExactRect's panel-type switch only handled TerminalPanel and BrowserPanel; every other panel type (notably AgentSessionPanel) fell to the default nil case, so the exact-rect correction from #4 never applied and the active-pane border in a split still used the chrome-trimmed estimate, reproducing the same ~2-row offset #4 fixed for terminals. Expose hostedView on AgentSessionPanel (forwarding through AgentSessionWebRendererSession to the bound WKWebView), matching the existing hostedView/webView pattern on TerminalPanel/BrowserPanel, and add it to the switch.
MarvinZeising
added a commit
that referenced
this pull request
Aug 10, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 10, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 10, 2026
preferredTmuxWorkspacePaneWindowOverlayRect() validated the live ("exact")
pane rect against the chrome-trimmed layout estimate, which assumes every
pane's tab-strip chrome is topChromeHeight (28pt, ~2 terminal rows) tall.
Single-tab panes hide that tab strip, so their real content starts right at
the pane's top -- higher than the trimmed estimate -- which made the check
reject the accurate exact rect and fall back to the over-trimmed one,
rendering the active-pane border (and unread/flash rings) ~2 rows below the
pane's true top edge.
Add TmuxPaneOverlayGeometry.rawWindowOverlayRect(), an untrimmed variant of
windowOverlayRect(), and validate the exact rect against it instead.
MarvinZeising
added a commit
that referenced
this pull request
Aug 17, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 18, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 19, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 20, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 21, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 22, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 23, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 24, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 25, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 26, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 27, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 28, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 29, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 30, 2026
MarvinZeising
added a commit
that referenced
this pull request
Aug 31, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 1, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 2, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 3, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 4, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 5, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 6, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 7, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 8, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 9, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 10, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 11, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 12, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 13, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 14, 2026
MarvinZeising
added a commit
that referenced
this pull request
Sep 15, 2026
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.
Re-lands
40bcdc1e8a, which was committed straight ontomarvin-mainon Aug 1 but lost the same night:build-and-install.shused to rungit checkout -B marvin-main origin/marvin-mainon every rebuild, force-resetting the local branch tooriginand silently discarding this never-pushed commit. It only survived on an orphaned local scratch branch. Opening as a real PR this time so it can't be lost again.Single-tab panes hide their tab strip, so their real content starts higher than the chrome-trimmed layout estimate assumed -- which made the active-pane border (and unread/flash rings) render ~2 rows below the pane's true top edge.