OpenCodex dashboard log panel layout jittering

[Tao-Yida]

Client or integration

OpenCodex dashboard

Area

Dashboard

Summary

I was using muse-spark-1.2-contributor provided by Opencode Go and checking usage via Opencodex logs, and I found the spreadsheet was quivering frequently.
As shown in images below, there is an obvious layout misalignment in the spreadsheet.
When the sheet is scrolled to top, it began quivering (image 3, which cannot be capture by screenshot so I took a photo). When I scroll down a little it will stop. At a certain position of scrolling the layout changes between image 1 and 2.

Reproduction

1. Say something in Codex with muse-spark-1.2-contributor
2. Check usage in logs
3. The sheet starts jittering

Version

2.39.0

Operating system

CentOS7 (Dashboard on Windows 11)

Provider and model

No response

Logs or error output

Screenshots and supporting files

Redacted configuration

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}

[lidge-jun]

리뷰 · 우선순위 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

[lidge-jun]

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.

[lidge-jun]

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.