fix(web): hide chat viewport focus outline after Home/End

[techotaku39]

Summary

• Hide the browser's default focus outline on the keyboard-scrollable chat viewport.
• Preserve the existing focus behavior and Home/End scrolling logic.
• Retain a visible application-colored focus ring for keyboard users.

Root Cause

The chat viewport uses tabIndex={0} to receive keyboard scrolling. Pressing Home or End focuses the viewport and causes the browser's default focus outline to appear around the chat area.

The viewport now suppresses the native outline and uses the existing application link color for its :focus-visible ring. No scrolling or keyboard event logic was changed.

Validation

• Focused HappyThread tests — 31 passed.
• Live keyboard-focus regression — 1 passed; Tab, Home, and End retain a visible focus ring while the native outline remains hidden.
• Test deployment endpoint returned HTTP 200.

[github-actions]

Findings

• [Major] Keyboard focus becomes invisible on the chat viewport — focus:outline-none suppresses the browser indicator for keyboard focus too, while the adjacent tabIndex={0} deliberately keeps this scroll region keyboard-operable. Evidence: web/src/components/AssistantChat/HappyThread.tsx:1616.
  Suggested fix:

  className="app-scroll-y chat-scroll-y min-h-0 flex-1 overflow-x-hidden focus:outline-none focus-visible:ring-2 focus-visible:ring-inset focus-visible:ring-[var(--app-link)]"

Summary
Review mode: initial

One major accessibility regression found. The default outline can be restyled, but the focusable scroll viewport still needs a visible keyboard-focus state.

Testing

• Not run (automation); PR content was not executed.
• Add a real-browser keyboard test that tabs to the viewport and verifies a visible :focus-visible indicator while preserving Home/End scrolling.

HAPI Bot

[github-actions]

[MAJOR] Keyboard users lose the viewport focus indicator.

focus:outline-none applies when this tabIndex={0} scroll region is reached by keyboard, not only after Home/End. With no replacement style, users cannot tell that arrow/Page/Home/End keys will operate the chat viewport. Replace the native outline with a controlled focus-visible indicator.

Suggested fix:

className="app-scroll-y chat-scroll-y min-h-0 flex-1 overflow-x-hidden focus:outline-none focus-visible:ring-2 focus-visible:ring-inset focus-visible:ring-[var(--app-link)]"

[github-actions]

Findings

• None.

Summary
Review mode: follow-up after new commits

No issues found in the latest full diff. The previous keyboard-focus accessibility finding is resolved by retaining a visible focus-visible ring while suppressing the browser default outline. Residual risk: the PR adds no real-browser regression coverage for focus modality.

Testing

• Not run (automation); PR content was not executed.
• No new automated test added; a Playwright keyboard test should tab to the viewport and verify the custom focus indicator while preserving Home/End scrolling.

HAPI Bot

[github-actions]

Findings

• None.

Summary
Review mode: follow-up after new commits

No issues found in the latest full diff. Residual testing gap: the added Playwright coverage is skipped unless HAPI_LIVE=1 and requires a live authenticated session (web/e2e/mermaid-lightbox-session.spec.ts:12-19); standard PR CI runs only terminal-wrap-fidelity.spec.ts from the browser suite (.github/workflows/test.yml:18), so this focus regression is not exercised by default automation.

Testing

• Not run (automation); PR content was not executed.
• GitHub test check was pending at review time.

HAPI Bot