Skip to content

fix(tui): scrollbar visibility, findings scrolling, and report navigation - #1006

Merged
0xallam merged 6 commits into
mainfrom
fix/tui-ux-1005
Aug 7, 2026
Merged

fix(tui): scrollbar visibility, findings scrolling, and report navigation#1006
0xallam merged 6 commits into
mainfrom
fix/tui-ux-1005

Conversation

@0xallam

@0xallam 0xallam commented Aug 7, 2026

Copy link
Copy Markdown
Member

Addresses two of the three reports in #1005, both regressions from the Textual interface, plus one enhancement to the report dialog.

1. The chat scrollbar is too narrow to select

The width is not the problem — Textual's was also one cell (scrollbar-size: 1 1) with the same near-invisible resting thumb (#chat_history { scrollbar-color: #1a1a1a } on black).

What the port dropped is the feedback. The stylesheet never overrode scrollbar-color-hover / scrollbar-color-active, so Textual's defaults applied and the thumb brightened as the pointer neared it and while it was dragged. In Go there was no such state: #1a1a1a on black, always. Invisible, and a one-column target.

  • One resting color for every panel, visible against the background.
  • The bar brightens while dragged.
  • The grab area extends one column either side, since a single column is not a reasonable mouse target.

Hover was considered and rejected: it needs WithMouseAllMotion, and a full frame is ~5.7ms in the existing benchmark, so re-rendering on every pointer move risks the lag this interface has already been criticised for.

2. The findings list behaves like pagination

vulnOffset was an index into the findings, so the list advanced a whole entry at a time; with wrapped titles that reads as pages. Even the scrollbar snapped to entry boundaries. Textual mounted each finding into a VerticalScroll with overflow-y: auto — line by line.

The offset is now a row. The wheel, the keys and the scrollbar all move continuously, and the list still reads ● title with wrapped lines under the title.

Sequence numbers were tried and reverted: the interface this replaced never had them, and they crowd a sidebar only a couple of dozen columns wide.

3. Stepping between reports (enhancement)

Reading a set of related findings meant closing the report, moving in the list and opening the next one. The dialog now carries its position and a pair of step buttons:

1/3  Next ›                              Copy   Done
2/3  ‹ Prev  Next ›                      Copy   Done
3/3  ‹ Prev                              Copy   Done

Reachable the three ways the other buttons are: clicked, tabbed to and pressed with Enter, or through / directly. A direction is offered only when there is a report that way, and the ends do not wrap — rolling from the last back to the first hides that you reached the end. A new report opens at its top and does not inherit the previous one's copy state.

Two details behind the implementation:

  • Both labels carry their arrow (‹ Prev, Next ›) because the click test matches label text against the rendered row, and a finding whose body contains "Next" could otherwise swallow a click.
  • Focus is held by label rather than index: stepping to either end drops a button from the row, and an index would then point at the wrong one. Covered by a test.

This is an enhancement rather than one of the reported bugs. Happy to split it out if you would rather keep the PR to the regressions.

Verification

Rendered and inspected each change: the findings list back to ● title with two-space continuation, a findings scrollbar that can now be seen, and the report row at all three positions plus the single-finding case.

Tests added (11): row-granular scrolling, selection scrolling into view, stepping both directions, clamping at both ends, per-position button availability, click activation, Tab reaching every button, Enter on a focused step button, and the focus fallback when a step button disappears.

gofmt, go vet and the full Go suite pass, including GOOS=windows and GOOS=linux builds.

**Scrollbars.** The chat pane's thumb was #1a1a1a on black, which cannot be seen,
let alone aimed at. That came from the stylesheet, but the stylesheet also gave
Textual's scrollbars hover and active colors it never overrode, so the bar
announced itself as soon as the pointer neared it. One resting color now covers
every panel and it is visible; the bar brightens while dragged; and the grab area
extends a column either side, since a single column is not a reasonable target
for a mouse.

**Findings list.** The offset was an index into the findings, so the list moved a
whole entry at a time and a set of wrapped titles read as pages rather than a
list. The offset is now a row, so the wheel, the keys and the scrollbar all move
it continuously. Each finding also carries its position - 01, 02, 03, padded to
the width of the count - because the report was that similar titles are
impossible to tell apart.

**Colors.** STRIX_TUI_COLORS=terminal draws with the terminal's own 16 colors and
leaves it its background; NO_COLOR drops color entirely. The default is unchanged.
Setting the profile alone is not enough - the greys the layout is built from round
to plain black and every panel outline disappears - so the structural colors are
mapped to ANSI indices by hand.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@greptile-apps

greptile-apps Bot commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

The PR restores row-granular findings scrolling, improves scrollbar visibility and mouse targeting, and adds previous/next navigation to the report dialog.

  • Uses one findings-row model for rendering, scrolling, selection, and hit-testing.
  • Adds active scrollbar feedback and a wider mouse grab area.
  • Adds report navigation buttons, keyboard controls, focus handling, and coverage for the new interactions.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename Overview
strix/interface/tui/internal/app/vulnerabilities.go Introduces a shared row-based findings layout and report-navigation state; the previously reported render/interaction width divergence is resolved.
strix/interface/tui/internal/app/view.go Renders findings with the shared list width and adds active scrollbar coloring.
strix/interface/tui/internal/app/update.go Adds row-granular scrollbar handling, expanded scrollbar hit targets, and report navigation input handling.
strix/interface/tui/internal/app/findings_test.go Adds focused coverage for row scrolling, width consistency, report stepping, button activation, and focus fallback.
strix/interface/tui/internal/app/model.go Adds report-button focus state and unified resting and active scrollbar colors.
strix/interface/tui/internal/app/model_test.go Updates copy-button and scrollbar tests for the new focus and color behavior.

Reviews (3): Last reviewed commit: "lay the findings list out at one width" | Re-trigger Greptile

Comment thread strix/interface/tui/internal/app/vulnerabilities.go
0xallam and others added 2 commits August 7, 2026 09:43
They were never in the interface this one replaced, and they crowd a sidebar
that is only a couple of dozen columns wide. The list reads "● title" again,
with wrapped lines under the title.

The scrolling change stays: the offset is a row rather than an index into the
findings, which is the part that made the list feel paginated.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
It is not a regression. The interface this replaced forced the same thing -
Screen { background: #000000; color: #d4d4d4 } - so nothing was taken away and
nothing here restores it. It belongs in its own change, judged as the feature it
is, rather than riding along with two fixes.

Reverting also takes back the hand-mapped ANSI palette, which is a second copy
of the colors to keep in step with the first, and which no one has yet seen in a
terminal it was meant for.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@0xallam 0xallam changed the title fix(tui): scrollbar visibility, findings scrolling and numbering, terminal colors fix(tui): scrollbar visibility and findings list scrolling Aug 7, 2026
0xallam and others added 2 commits August 7, 2026 15:44
Reading a set of related findings meant closing the report, moving in the list
and opening the next one. The arrows now walk the list from inside the report,
and it reopens at the top of whichever one they land on, with the copy state left
behind.

The ends do not wrap: a report is one of an ordered list, and rolling off the
last back to the first hides that you reached the end. Each arrow is offered only
while there is something that way, next to a "2/12" position, and a lone finding
is offered neither.

Tab still moves between Copy and Done, which is what the arrows used to do. It is
the better key for it - two buttons are a smaller thing to reach than the rest of
the findings.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Prev and next were key hints, which is a poor way to offer something the rest of
the dialog offers as buttons: the arrows were the only way to reach them, and the
row read as two buttons and some text about the keyboard.

They are buttons now, in the same style as copy and done, and reachable the three
ways the others are - clicked, tabbed to and pressed with enter, or through their
own arrow shortcut. The row keeps its position count and still offers a direction
only when there is a report that way.

Both labels carry their arrow, "‹ Prev" and "Next ›", so a click test cannot be
fooled by the same word appearing in the body of a finding. Focus is held by
label rather than by index, since stepping to either end drops a button from the
row and an index would then point at the wrong one.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@0xallam 0xallam changed the title fix(tui): scrollbar visibility and findings list scrolling fix(tui): scrollbar visibility, findings scrolling, and report navigation Aug 7, 2026
@0xallam

0xallam commented Aug 7, 2026

Copy link
Copy Markdown
Member Author

@greptile

Rendering wrapped titles at sidebarWidth-5 while every interaction wrapped them
at sidebarWidth-6 gives two different row counts for the same list. "ffffff dddd
a a a a" is one row on screen and two to the code deciding what a click means, so
past that point clicks open the wrong finding, the scrollbar reports a length
that is not there, and scrolling to the selection lands short.

The mismatch came in with the one column scrollbar: the render width lost a
column and the width every other path uses did not follow.

vulnerabilityListWidth is now the only width, used by the renderer too, and it
reserves the scrollbar column whether or not the bar is showing so the list does
not reflow as it grows past the panel.

Reported by Greptile on #1006.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@0xallam

0xallam commented Aug 7, 2026

Copy link
Copy Markdown
Member Author

@greptile

@0xallam
0xallam merged commit 0607abf into main Aug 7, 2026
2 checks passed
@0xallam
0xallam deleted the fix/tui-ux-1005 branch August 7, 2026 13:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant