OpenCodex dashboard log panel layout jittering #3152

Activity

1. Tao-Yida

   added

   bugSomething isn't workingSomething isn't working

   on Sep 1, 2026
2. github-actions commented on Sep 1, 2026

   

   github-actionsbot

   on Sep 1, 2026 – with GitHub Actions

   Last edited by github-actions

   Contributor

   More actions

   _{Automated translation bookkeeping — detected language: English.}
3. github-actions

   added

   guiDashboard, tray, settings UIDashboard, tray, settings UI

   on Sep 1, 2026
4. lidge-jun commented on Sep 1, 2026

   

   lidge-jun

   on Sep 1, 2026

   Last edited by github-actions

   Owner

   More actions

   리뷰 · 우선순위 48 / 80

   설명

   이 이슈는 OpenCodex 대시보드 Logs 표가 위쪽으로 스크롤했을 때 레이아웃이 흔들리고, 특정 스크롤 위치에서 열 정렬이 두 상태 사이를 오간다는 보고입니다. muse-spark-1.2-contributor(OpenCode Go) 사용 로그를 보다가 발견했고, 버전 2.39.0, 대시보드는 Windows 11, 프록시는 CentOS7 입니다. 스크린샷 세 장이 붙어 있습니다.

   지금 HEAD에서 로그 표는 gui/src/pages/Logs.tsx 가 .tbl-wrap.logs-table-wrap 스크롤 컨테이너 안에 .tbl.logs-table 을 그립니다. gui/src/styles.css 에 .logs-table-wrap 과 .tbl-wrap 규칙이 있습니다. #2906/#2915 가 뷰포트 스크롤 캡을 dvh 와 선언 순서로 잠갔고, #2859 가 로그 폴 2초+백오프를 정리했습니다. #3115 는 model/provider 필터를 넣었습니다. 이번 증상은 필터가 아니라 스크롤 위치와 스크롤바 gutter/열 너비 재계산으로 보입니다. Windows에서 스크롤바가 overlay가 아니면, 세로 스크롤바 출현이 가로 폭을 바꿔 sticky 헤더·열 정렬이 떨릴 수 있습니다.

   remote hub·계정 라우팅 대비 우선순위는 낮습니다. 다만 대시보드 신뢰에 직접 보이는 UX 버그입니다. types/config 분할 무관합니다. 점수는 48입니다. 재현이 스크롤 위치에 의존해 자동 테스트가 어렵고, 데이터 평면 사고는 아닙니다.

   경로 gui/src/pages/Logs.tsx .logs-table-wrap - 스크롤 컨테이너입니다. sticky 헤더와 본문 열이 같은 table인지, 헤더 분리 렌더인지 확인이 필요합니다
   경로 gui/src/styles.css .logs-table-wrap / .tbl-wrap - scrollbar-gutter: stable 이 로그 표에 없는 것 같습니다. storage/subagents 워크스페이스는 stable gutter를 씁니다
   경로 #2906 dvh - 로그 표 높이와 관련은 있지만, 이번 가로 떨림의 직접 원인은 아닐 수 있습니다
   경로 재현 조건 muse-spark - 특정 모델 행 내용(긴 model id)이 열 최소 너비를 밀어 스크롤바 임계를 넘기는지 볼 필요가 있습니다

   메인테이너의 판단이 필요한 지점

   • scrollbar-gutter: stable 을 logs-table-wrap에 넣는 최소 패치로 충분한지
   • Windows 스크롤바 폭을 전제로 한 GUI 스크린샷 재현이 필요한지
   • help wanted / good first issue 로 둘지

   너의 추천
   열어 두고, 첫 시도는 .logs-table-wrap 에 scrollbar-gutter: stable 과 열 min-width/tabular 숫자 정렬 고정입니다. remote hub·#3157 계열보다 뒤로 둡니다. 라벨은 바꾸지 않습니다.

   이 댓글은 grok-bot이 작성했습니다

   Translated Message

   Original language: Korean

   Review · Priority 48 / 80

   Description

   This issue is a report that the OpenCodex dashboard Logs table layout jitters when scrolled upward, and column alignment oscillates between two states at certain scroll positions. It was discovered while reviewing muse-spark-1.2-contributor (OpenCode Go) usage logs, with version 2.39.0, dashboard on Windows 11, and proxy on CentOS7. Three screenshots are attached.

   Currently at HEAD, the Logs table has gui/src/pages/Logs.tsx rendering .tbl.logs-table inside the .tbl-wrap.logs-table-wrap scroll container. gui/src/styles.css contains rules for .logs-table-wrap and .tbl-wrap. #2906/#2915 locked viewport scroll caps with dvh and declaration order, and #2859 cleaned up log polling 2s+backoff. #3115 added model/provider filtering. This symptom appears to be related to scroll position and scrollbar gutter/column width recalculation, not filtering. On Windows, if the scrollbar is not overlaid, the appearance of a vertical scrollbar can change the horizontal width, causing sticky header and column alignment to jitter.

   Priority is lower compared to remote hub and account routing. However, it is a UX bug directly visible to dashboard reliability. Unrelated to types/config splitting. The score is 48. Reproduction depends on scroll position making automated testing difficult, and it is not a data plane issue.

   Path gui/src/pages/Logs.tsx .logs-table-wrap - scroll container. Need to verify if sticky header and body columns are in the same table or if header is rendered separately.

   Path gui/src/styles.css .logs-table-wrap / .tbl-wrap - scrollbar-gutter: stable appears to be missing on the logs table. storage/subagents workspace uses stable gutter.

   Path #2906 dvh - related to logs table height, but may not be the direct cause of this horizontal jitter.

   Path reproduction condition muse-spark - need to check if specific model row content (long model id) pushes column minimum width and exceeds scrollbar threshold.

   Points requiring maintainer judgment

   • Whether adding scrollbar-gutter: stable to logs-table-wrap is sufficient as a minimal patch
   • Whether GUI screenshot reproduction assuming Windows scrollbar width is necessary
   • Whether to label as help wanted / good first issue

   Your recommendation

   Keep it open, first attempt is adding scrollbar-gutter: stable to .logs-table-wrap and fixing column min-width/tabular number alignment. Deprioritize compared to remote hub and #3157 series. Do not change labels.

   This comment was written by grok-bot
5. lidge-jun commented on Sep 1, 2026

   

   lidge-jun

   on Sep 1, 2026

   Owner

   More actions

   Investigated on 2.40.0 with the dashboard driven through CDP. I could not reproduce the jitter, and the explanation I expected to confirm turned out to be wrong — so this needs a bit more from you rather than a speculative patch.

   What I tried and what it showed

   The Logs table is virtualized inside a real <table> with automatic layout, and the virtualizer renders spacer rows for the off-screen extent. The obvious theory was that those spacer rows disturb column widths, that width changes re-wrap the model column, and that the resulting height change feeds back into row measurement — which would also explain why it is worst at the very top, since the leading spacer is not rendered at scrollTop 0.

   Three measurements disagreed:

   1. Toggling a spacer row between 0 and 500px changed column widths not at all, under both auto and fixed table layout. The spacer has colspan and no content, so it contributes nothing to column sizing.
   2. table-layout: fixed does not stop the row-height change either — max-width: 16ch wraps the model cell identically both ways.
   3. Sampling 40-120 animation frames while alternating the scroll position at the top, with and without auto-refresh, with varied model-name widths: one distinct column layout, one distinct scroll extent, zero drift.

   One thing that is genuinely off, but that I could not tie to your symptom

   The virtualizer estimates each unmeasured row at 44px. Real rows here measure 80-119px (mean 92) because the time, token and status cells each stack two or three lines. That matters only for rows not yet measured, and with the ~30 log rows I could generate everything gets measured immediately — changing it to 92 produced no measurable difference. Your list may be long enough that it does, which is exactly the case I cannot construct locally.

   Three things that would settle it

   1. Roughly how many rows were in the list when it jittered? The estimate theory needs a long one.
   2. Does it still jitter with Auto-refresh unchecked? One click, and it cleanly separates a render loop from a data-arrival effect.
   3. Which browser, and what display scaling / zoom? Your description of the layout alternating between two states at one fixed scroll position looks like fractional device-pixel rounding, which is scale-dependent and would explain why it reproduces on your display and not on mine.

   Keeping this open. Thanks for the photo — noting that it could not be screenshotted was the detail that told me it was a per-frame oscillation rather than a static layout bug.
6. lidge-jun

   added

   needs-infoWaiting on reporter for a concrete spec or reproductionWaiting on reporter for a concrete spec or reproduction

   on Sep 1, 2026
7. lidge-jun

   added a commit that references this issue on Sep 2, 2026

   fix(gui): stop the log panel from jittering as rows scroll in (#3290)

   ...

   This issue will close once commit fc08fc2 is merged into the 'main' branch.

   fc08fc2
8. lidge-jun commented on Sep 2, 2026

   

   lidge-jun

   on Sep 2, 2026

   Owner

   More actions

   Fixed on dev in fc08fc2 (#3290).

   The jitter came from a feedback loop rather than from polling: rows were measured dynamically against a 44px estimate while the multiline cells are roughly twice that, on a table left in automatic layout. Every changed mounted-row subset recomputed intrinsic column widths, model wrapping then changed row heights, and that fed another virtualizer measurement.

   The table now uses table-layout: fixed with an explicit ten-column schema, so column widths no longer depend on which rows happen to be mounted. The size estimate moves to the observed mean, measurements are keyed to the request rather than the row index so a prepend does not shift them, and the wrapper disables scroll anchoring and reserves the scrollbar gutter.

   Verified in a running dashboard, not only in tests — the live DOM now reports {"layout":"fixed","cols":10}, where dev had no table-layout declaration and no <colgroup> at all. Before/after screenshots are in the PR.
9. lidge-jun

   closed this as completedon Sep 2, 2026
10. tarunravi

    added a commit that references this issue on Sep 14, 2026

    fix(gui): stop the log panel from jittering as rows scroll in (lidge-…

    ...

    This issue will close once commit edcd0e1 is merged into the 'main' branch.

    edcd0e1
11. agentHits

    added a commit that references this issue on Sep 17, 2026

    fix(gui): stop the log panel from jittering as rows scroll in (lidge-…

    ...

    This issue will close once commit c3ed9f1 is merged into the 'main' branch.

    c3ed9f1