Tab bar / header shifts horizontally when switching tabs (macOS Tahoe, windowed)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 52/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- macos, scss, typescript
Direzione di ricerca
Start in frontend/app/tab/tabbar.tsx and frontend/app/tab/tab.scss, tracing windowDragLeftWidth, setSizeAndPosition(), and the asynchronous MacOSVersion value during tab switches. Reproduce on macOS Tahoe in a windowed window with multiple tabs, then verify that the header’s left origin remains fixed when switching tabs.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
On macOS (Tahoe), in a windowed (non-full-screen) window, the entire left side of the title bar — the Wave AI / workspace icons and the tab row — shifts horizontally by roughly the width of the macOS traffic-light buttons when switching between tabs. The first tab vs. other tabs is the most obvious trigger, but the row visibly jumps left/right and settles in different positions depending on which tab is active.
This is purely a cosmetic/layout jitter, but it's very noticeable.
Environment
- Wave Terminal: v0.14.5
- macOS: 26.5.1 ("Tahoe", build 25F80)
- Arch: Apple Silicon (arm64)
- Window state: windowed (not full-screen), default zoom
- Multiple tabs open (≥3)
Steps to reproduce
- Open a window with several tabs on macOS Tahoe, windowed (not full-screen).
- Switch between tabs (e.g. tab 1 → tab 3 → tab 4 and back).
- Watch the left cluster: the sparkle (Wave AI) icon, the workspace switcher, and the whole tab strip shift horizontally — by approximately the traffic-light reservation width — and land in different positions depending on the active tab.
Expected
The left origin of the header (icons + tab strip) should stay fixed regardless of which tab is active.
Actual
The header's left origin moves by ~the traffic-light width (~74–80px) as the active tab changes; switching away from the first tab is the most reliable way to see it.
Investigation (read against the v0.14.5 tag)
I read frontend/app/tab/tabbar.tsx and frontend/app/tab/tab.scss at v0.14.5 (blob SHAs b404afc / ad10fc8, identical to main at time of writing).
-
The tabs themselves are not what reflows: in
tab.scss,.tabisposition: absolutewith an explicit width, and the.activeclass only restyles the inner pill (background, text color/weight). Intabbar.tsx,setSizeAndPosition()assigns every tab the same computed width and positions each bytranslate3d(index * idealTabWidth).setSizeAndPositionis also not re-run on active-tab change (its effect deps aretabIds, tabsLoaded, newTabId, hideAiButton, appUpdateStatus, zoomFactor, showMenuBar—activeTabIdis absent). So inter-tab geometry is active-tab-independent. -
That means the visible shift is the row's left origin moving, not the tabs reflowing. The only left-origin quantity is
windowDragLeftWidth— the left drag spacer that reserves room for the macOS traffic lights:const MacOSTrafficLightsWidth = 74; const MacOSTahoeTrafficLightsWidth = 80; ... let windowDragLeftWidth = 10; if (env.isMacOS() && !isFullScreen) { const trafficLightsWidth = isMacOSTahoeOrLater() ? MacOSTahoeTrafficLightsWidth : MacOSTrafficLightsWidth; windowDragLeftWidth = zoomFactor > 0 ? trafficLightsWidth / zoomFactor : trafficLightsWidth; } -
The observed shift magnitude matches this reservation (~80px on Tahoe), which strongly implicates this spacer. In code the value depends only on
isMacOS()/isFullScreen/isMacOSTahoeOrLater()/zoomFactor— none of which change on tab switch — so the trigger appears to be a render/measurement timing issue: the reservation (or the measured non-tab width feedingsetSizeAndPosition) is being applied inconsistently across re-renders, and tab switching is what forces the re-render that exposes it.Note:
isMacOSTahoeOrLater()returnsfalseuntilMacOSVersionis set asynchronously, so an early render can reserve 74px and a later one 80px — one plausible source of the desync on Tahoe specifically.
I could not pin the exact line that flips the value at runtime from a static read, but the magnitude and the macOS-Tahoe/windowed-only conditions point squarely at the traffic-light reservation. Happy to provide more screenshots/recordings.
- Lingua principale
- Go
- Stelle
- 22.3k
- Fork
- 1.1k
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di wavetermdev/waveterm
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
wavetermdev/waveterm#3481 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
wavetermdev/waveterm#3435 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
wavetermdev/waveterm#3432 ·
-
enhancement triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
wavetermdev/waveterm#3431 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
wavetermdev/waveterm#3428 ·
Tutte le issue di wavetermdev/waveterm
Issue simili
-
bug github_actions
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
registrystack/registry-stack#1393 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
JakeChampion/lang#10213 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
oasisprotocol/oasis-sdk#2523 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100