Repository navigation
[Bug]: Sidebar toggle overlaps macOS window controls after zooming in #12036
Description
Activity
Triage
Confirmed on current
main(6ee03240b) and on shipping0.0.42/ the reported0.0.41-nightly.20260916.1795. All three already contain #11906. This is a real macOS desktop layout bug, not a wash of #11906 / #1577 / #420. The two crops are two different buttons.Command+ zooms Chromium. Native traffic lights stay 14pt. After enough zoom the CSS viewport falls under
md(768px) and the left sidebar becomes the mobile Sheet, closed by default. That is the “sidebar hidden by default” precondition. Default window is 1100px (DEFAULT_MAIN_WINDOW_SIZE); about five+0.5zoom steps (1.2^2.5 ≈ 1.58→ ~698 CSS px) get there. AtminWidth840, one step is enough.Closed: the user clicks the fixed
SidebarControl. It sits atleft: var(--workspace-controls-left). On macOS that token is--desktop-window-controls-inset=90 / zoomFactorCSS px, i.e. a constant 90 native points. That is why the closed crop is clean — toggle to the right of red / yellow / green.Open: the Sheet portals at
z-50and covers that control. The button in the open crop isSidebarChromeHeader’smd:hiddenSidebarTrigger—relativein a header withpx-3(12 CSS px). Phone inset. It does not read--workspace-controls-left. At zoom 1.58 that is ~19 native points, on top of the red button (x: 16). The 1.75rem chrome scales with zoom and lands on red + yellow; green stays outside. That is the open crop.Cosmetic only. The screenshots do not prove click-through onto close / minimize; they do prove the outline occupies the native-control cluster.
What the code does
Two triggers, one layout token that only one of them uses.
Floating control (
AppSidebarLayout.tsx), always mounted, usesleft-[var(--workspace-controls-left)]. macOS desktop (not fullscreen) sets that to--desktop-window-controls-inset. Preload keeps the reserve in native points (the #11906 fix):90 / webFrame.getZoomFactor()CSS px, synced onDOMContentLoadedandresizeonly.zoomMainrecenters the native buttons on Y and leaves X at 16.useIsMobile()ismax-md. Under that,Sidebarrenders the left Sheet (z-50).openMobiledefaults tofalse.The open-state button is in
SidebarChrome.tsx(md:hiddenSidebarTriggerinsideSidebarHeaderwithpx-3). Brand usesml-[var(--workspace-titlebar-content-left)]onmd+only, so it never runs here. Headerpx-3is the only left inset the open-state toggle gets.#11906 fixed (1) brand cap-height, (2) traffic-light Y on zoom / fullscreen, (3) the floating control’s X reserve. Its validation was “collapse/reopen at reduced zoom,” not Command+ until the Sheet path. The
md:hiddentrigger was not part of that change. Still true onmain.Related, not duplicates
Issue / PR Why it does not close this Merged #11906 Same chrome, opposite zoom / opposite control. Shipped in this nightly. Closed-state crop is the post-#11906 floating button. Open-state crop is the Sheet header trigger #11906 never inset. Closed #1577 / merged #3497 0.0.15: header text under traffic lights after resize/zoom collapsed the sidebar. Not this open-Sheet overlap. Closed #420 / merged #586 Collapsed-sidebar clearance and brand alignment on md+. Desktop header, not themd:hiddentrigger.Merged #4019 Fullscreen spacing. This report is windowed. Closed #11686 Compact-rail vs traffic lights. Different mode. Open #8893 Diff-toolbar tooltip vs native controls. Collision padding, not this button. No open or merged PR insets
SidebarChromeHeader’smd:hiddentrigger, or liftsSidebarControlabove the Sheet.Suggested fix
Keep this as a small layout bugfix on the zoom-to-Sheet header path. Do not invent a second 90px constant.
- Give the
md:hiddentrigger the same left edge as the floating control.--workspace-controls-leftis already 90 native points on macOS, default0.75remelsewhere, and unset in fullscreen. Cancel the headerpx-3with something likeml-[calc(var(--workspace-controls-left)-0.75rem)]whenisElectron. On Windows/Linux the calc is ~0. On macOS the open-state icon lines up with the closed-state one. Settings and legacy share this header. - Do not hide the in-header trigger and only raise
SidebarControltoz-60unless you also hide the duplicate. The Sheet is meant to own the open-state control on the mobile path. Insetting that control is the smaller change. Mobile web (isElectron === false) stays atpx-3. - Optional hardening: call the preload inset sync on zoom, not only
resize/DOMContentLoaded, so the token cannot go stale if Chromium skips a resize. Not the open-state bug; the closed crop is already correct. - Tests: render
SidebarChromeHeaderunder the mobile sidebar state with--workspace-controls-left: 90pxandisElectronand assert the trigger gets the extra margin. WithisElectron={false}, assert no extraml-. - Visual close: Command+ until the sidebar hides, open it, confirm the outline sits to the right of green, same as the closed crop. Repeat at default zoom, after Cmd+0, and in fullscreen (no extra inset).
Workaround
Cmd+0(or View → Actual Size) so CSS width stays ≥ 768px. The desktop sidebar returns and this header trigger staysmd:hidden. No in-app toggle for “keep desktop sidebar while zoomed.”Classification: bug · accepted · cosmetic (macOS desktop; zoom-to-
max-mdSheet header trigger ignores traffic-light inset)
Labels: addbug,accepted,via-triage
Discord tags:macOS,ui- Give the
adding to this.
Related, the tooltips also overlap:
Before submitting
Summary
After repeatedly zooming in with Command + until the main sidebar is hidden by default in T3 Code on macOS, the “Toggle main sidebar” control appears in a floating rounded outline beneath the red and yellow window controls when the main sidebar is open. In the supplied closed-sidebar screenshot, the toggle is positioned separately to the right of the red, yellow, and green controls. The open-sidebar state causes the sidebar toggle and native window controls to visually overlap.
Steps to reproduce
The zoom prerequisite is user-reported and the two resulting sidebar states are supported by screenshots. These steps have not been independently replayed. The exact zoom percentage, number of Command + presses, window dimensions, and reproduction frequency are not recorded; the observable setup criterion is that zooming causes the sidebar to be hidden by default.
Expected behavior
The main sidebar toggle remains visibly distinct from the macOS close, minimize, and zoom controls in both sidebar states, including after zooming enough to hide the sidebar by default. Its icon, surrounding outline, and interactive area should not occupy the native window-control area.
Actual behavior
With the sidebar open, the toggle icon and its rounded outline occupy the same top-left region as the red and yellow window controls. The controls are drawn over the toggle, making it look detached from its normal position. With the sidebar closed, the toggle is separately positioned to the right of all three window controls.
Area
apps/desktop — T3 Code desktop window chrome and the main sidebar toggle on macOS.
Runtime or environment
0.0.41-nightly.20260916.1795, read from the installed application metadata while preparing this report.Evidence
The following crops are taken from the two user-supplied screenshots at their original pixel scale. They preserve the relevant controls while excluding project identifiers, conversation titles, and conversation text. No identifying metadata is intentionally retained.
Sidebar closed: toggle positioned separately to the right of the window controls.
Sidebar open: toggle and rounded outline overlap the red and yellow window controls.
Impact
Cosmetic issue.
The overlap obscures the sidebar toggle and makes the top-left controls visually ambiguous. The screenshots establish a layout defect; they do not establish whether clicks are intercepted, any control becomes unusable, or unintended window actions occur.
Additional context
Regression closure: zoom in with Command + until the main sidebar is hidden by default, then open and close it without changing zoom. The sidebar toggle must remain usable and opening and closing the main sidebar must leave the toggle icon and its outline separate from the native window controls. Verify both sidebar states visually and confirm that the sidebar toggle and native controls retain distinct, usable click targets. The report remains failing while the overlap shown in the open-sidebar evidence persists.
No implementation cause has been verified. The report covers one visual layout defect and has no known issue dependencies or supported security impact.
Related historical report: #1577 (closed) describes header overlap with the sidebar collapsed after resizing in version 0.0.15. This report specifically concerns the sidebar toggle overlapping native controls when the sidebar is opened after zooming in until it is hidden by default; a shared cause has not been established.