fix(ui): keep relevant file path segments visible - #628
Conversation
Render mention-picker file results with the filename on its own line and an abbreviated first-folder/parent context so deeply nested paths remain identifiable without horizontal scrolling. Keep selection values unchanged, expose the complete path to assistive technology and hover users, and preserve shared overflow behavior for command and agent results. Add focused path-splitting coverage to the PR UI test job. Validated with workspace typecheck, UI production build, the focused Node test, and repeated Gatekeeper review.
pascalandr
left a comment
pascalandr
left a comment
There was a problem hiding this comment.
Gatekeeper review, round 1: 2 findings. Long filenames could wrap across enough lines to consume the picker viewport, and the omitted middle path was unavailable to sighted keyboard/touch users because the complete value was only exposed through sr-only text/title. Both are being corrected while preserving the immediately visible filename, parent, and starting folder.
|
PR builds are available as GitHub Actions artifacts: https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/30355336542 Artifacts expire in 7 days.
|
Keep filename, parent, and root-aligned directory context independently visible while retaining the horizontally scrollable complete directory introduced by the large-workspace picker follow-up. Reset horizontal position when results change, avoid unsupported Array.at calls on older WKWebView releases, and keep the selected attachment payload unchanged. Validated with workspace typecheck, UI production build, focused path tests, diff checks, and Gatekeeper rounds through zero findings.
pascalandr
left a comment
pascalandr
left a comment
There was a problem hiding this comment.
Gatekeeper review, round 2: 3 findings. Query changes preserved horizontal scroll position, Array.at would fail on older supported WKWebView releases, and an extreme filename could push the parent out of the initial viewport. All three are corrected in ab55667. The existing keyboard limitation of PR #623's horizontal panning was classified as pre-existing; no footer workaround was retained.
pascalandr
left a comment
pascalandr
left a comment
There was a problem hiding this comment.
Gatekeeper review, round 3: zero findings. Verified filename/parent/root visibility, complete touch-scrollable directory context, full screen-reader path, unchanged selection values, horizontal reset, older WKWebView compatibility, focused CI coverage, workspace typecheck, UI production build, and diff hygiene.
|
@shantur LGTM |
|
PR builds are available as GitHub Actions artifacts: https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/30357682831 Artifacts expire in 7 days.
|
1 similar comment
|
PR builds are available as GitHub Actions artifacts: https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/30357682831 Artifacts expire in 7 days.
|
2 participants
Summary
Context
PR #623 replaced end truncation with horizontal scrolling. This follow-up keeps that behavior while moving the relevant filename and parent to the start of each result, matching the CLI-style expectation from the report.
Validation
Closes #603