mirror of
https://github.com/Ark0N/Codeman.git
synced 2026-10-20 09:09:35 +02:00
Codeman maintainer
4ee382832a
On phones and 600-767px tablets the header strip stays one horizontally scrolling row. #538 (Tab Layout, default "by state") orders that row in one flex `order` band per state, so when the ACTIVE session changes state (a prompt sent: idle to working; a permission prompt: needs you) its chip moves to another band while scrollLeft stays put, and the tab in use left the screen (measured at 390px: x 165 to -870). #257's reveal rules only covered a CHANGED active tab: _updateActiveTabImmediate reveals on a switch, and _fullRenderSessionTabs restores scrollLeft and re-reveals only when _lastRenderedActiveTabId changed, while a state change is an incremental pass that never reveals at all. _noteActiveTabBand() records the active tab's band (read off the element, so it is what is on screen) and reports when it moved while the tab stayed active. Both render paths reveal on that, in the single scrolling row only (_isScrollingTabRow: not wrapping, not a vertical list). It is keyed on the band, not the raw order value, because another tab entering or leaving the active tab's band shifts that value by one and another tab's move must not yank a strip the user is browsing. _updateActiveTabImmediate records too, so the pass right after a switch still counts (viewing a waiting tab spends its alert and drops it into the idle row). The incremental path reveals after updateTabOverflowMode(), and only from the branch that reached _syncTabTriageChrome(), so a pass that falls through to a full rebuild mid-loop leaves the record for the rebuild to compare. Tests in test/tab-triage.test.ts pin the reveal on both paths and after a switch, and that another tab's band change, a wrapping strip, a vertical list and an active web tab never scroll. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>