Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Tab bar / header shifts horizontally when switching tabs (macOS Tahoe, windowed)

Aperta
#3,375 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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
Ambito
desktop, frontend

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

  1. Open a window with several tabs on macOS Tahoe, windowed (not full-screen).
  2. Switch between tabs (e.g. tab 1 → tab 3 → tab 4 and back).
  3. 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, .tab is position: absolute with an explicit width, and the .active class only restyles the inner pill (background, text color/weight). In tabbar.tsx, setSizeAndPosition() assigns every tab the same computed width and positions each by translate3d(index * idealTabWidth). setSizeAndPosition is also not re-run on active-tab change (its effect deps are tabIds, tabsLoaded, newTabId, hideAiButton, appUpdateStatus, zoomFactor, showMenuBaractiveTabId is 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 feeding setSizeAndPosition) is being applied inconsistently across re-renders, and tab switching is what forces the re-render that exposes it.

    Note: isMacOSTahoeOrLater() returns false until MacOSVersion is 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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di wavetermdev/waveterm

Tutte le issue di wavetermdev/waveterm

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.