[juliusmarminge]

Problem

A workspace area the user clicked showed the 2px --ring outline after any later bare key press reached the page. That includes a modifier delivered when the window is activated, as with Hyprland focus-follows-mouse or a Super-key window switch. The ring was drawn by [data-workspace-area]:focus-visible, and Chromium switches :focus-visible on for the already focused element on keyboard input. Reproduced on main 15fe283 in the web app inside Electron 44 under Xvfb:

1. Fresh database with no projects, so "What should we work on?" shows.
2. Click empty space in the main area. The home <main> gets focus with no ring.
3. Switch to another window and back.
4. One bare Meta (or Shift) key event reaches the page, and the ring appears around the whole main area.

The same selector made shouldRefocusComposerOnWindowFocus treat such a clicked area as "reached from the keyboard".

Change

createWorkspaceFocusController (apps/web/src/lib/workspaceFocus.ts) marks an area with data-workspace-keyboard-focus when focus arrives there from another element and is keyboard-visible at that moment. This covers F6, focus requests, and keyboard focus returning from a dialog. It also marks when the controller focuses the area that already has focus, which fires no focusin (F6 with no other visible area). Window activation refocuses the same element, so it never counts as an arrival.

The mark clears on focus moving elsewhere, on a pointer press, and on dispose. The ring in index.css and the window-return check in ChatView.logic.ts read the mark instead of :focus-visible. An area's own :focus-visible outline is set to none so the browser default does not come back.

Scope and approval

Fixes #28166

Verification

• vp test run --project browser src/lib/workspaceFocus.browser.test.ts src/components/ChatView.logic.browser.test.ts (apps/web): 18 passed. The two new tests fail on main:
  • rings an area reached with F6, but not a clicked one after a bare key press: expected 'solid' to be 'none'
  • refocuses the composer on window return from a clicked area after a bare key press: expected false to be true
• The ring test loads the real index.css and also covers:
  • same-element refocus (window return): no ring
  • keyboard focus returning after a dialog: ring
  • click: clears the ring
  • F6 onto the only visible area: ring
• vp run check:changed: format, lint, knip, typecheck, tests and React compiler all pass.
• Real app, before 15fe283 vs after (Electron 44.10.0 / Chromium 152, Xvfb, 1280×800 and 390×844, DPR 1, dark and light, fresh database per side), with real window activation between two BrowserWindows:

Row	Before	After
Clicked home area, window switch, bare Meta / Shift, and Meta before switching away	solid 2px ring	no ring (outline: none)
F6 into an area, window switch, then click	ring, kept across the switch	ring kept across the switch, cleared by the click
Thread: clicked conversation, window return	conversation keeps focus with a ring	caret goes to the composer
Thread: conversation reached with F6, window return	ring and focus kept	ring and focus kept
390 px wide: clicked conversation	pointer ring	no ring; F6 ring kept

The reporter's row was re-run at the PR head 9bda46d with the same result. All other visible differences vanish at 3% fuzz (14 anti-aliased glyph pixels). Screenshots and recordings could not be attached from the triage environment, so this table records what they show.

• Not checked: Hyprland or another Wayland session (cannot-verify wayland). The Linux runs used X11 window activation and synthetic key events.

Model: Claude Opus 5.5 (lead, tests, implementation, review B), GPT-6.1 Sol (review A, proof audit, captures), via T3 Code delegation on the Claude Code harness.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 9bda46d

Macroscope's review found this PR approvable — Workspace focus rings and window-return focus handling now distinguish keyboard navigation from clicked regions. The change is limited to transient browser focus behavior, with existing protected-control exceptions preserved.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: fix/issue-28166
• File: .coderabbit.config.ts
• Commit: 9bda46d
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Team
• Run ID: 9e5fe303-65e2-4f39-8a95-733b48ff7915

Commits

Reviewing files that changed from the base of the PR and between 15fe283 and 9bda46d.

Files selected for processing: 5

• apps/web/src/components/ChatView.logic.browser.test.ts
• apps/web/src/components/ChatView.logic.ts
• apps/web/src/index.css
• apps/web/src/lib/workspaceFocus.browser.test.ts
• apps/web/src/lib/workspaceFocus.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 7 remain after this review.

Walkthrough

The workspace focus controller now tracks areas reached by keyboard navigation. Focus-ring styling and composer refocus eligibility use this marker. Browser tests cover pointer focus, keyboard navigation, and focus returning to the workspace.

Changes: Workspace focus behavior

Layer / File(s)	Summary
Track keyboard-focused workspace areas apps/web/src/lib/workspaceFocus.ts	The controller marks qualifying keyboard focus and clears the marker when focus moves elsewhere, pointer input occurs, or the controller is disposed.
Apply the focus marker to UI behavior apps/web/src/index.css, apps/web/src/components/ChatView.logic.ts, apps/web/src/lib/workspaceFocus.browser.test.ts, apps/web/src/components/ChatView.logic.browser.test.ts	Workspace areas show a focus ring when marked for keyboard focus. Composer refocus eligibility uses the same marker. Browser tests cover the resulting focus behavior.

Estimated code review effort: 2 (Simple) | ~12 minutes

Change: Bug fix · Severity of issue fixed: Low

Possibly related issues

• Issue 27170: The changes suppress the focus ring after pointer input, but do not address the issue’s reported scroll loss.

Suggested reviewers: t3dotgg

Merge Risk: Low · up to 9bda4

In a narrow recovery case, a stray key can still cause a ring and prevent composer refocus. The change is mergeable with awareness of this edge case.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: clicked workspace areas no longer show the focus ring after a stray key press. The changeset adds keyboard-visible focus tracking via data-workspace-keyboard-focus, sw…
Description check		The description follows the repository template. It has Problem, Change, Scope and approval, and Verification sections. The Problem section gives the expected behavior and reproduction steps. The Chan…
Linked Issues check		Issue #28166 requires no ring when focus returns to a clicked workspace area without keyboard navigation, while preserving the ring for keyboard navigation such as F6. workspaceFocus.ts marks only k…
Out of Scope Changes check		The changes stay within the linked issue scope. The controller state, CSS selector, composer-refocus selector, and browser tests all support correct workspace-area focus classification. The composer b…

Full details: Title check

Explanation

The title names the main change: clicked workspace areas no longer show the focus ring after a stray key press. The changeset adds keyboard-visible focus tracking via data-workspace-keyboard-focus, switches the ring styling and window-return check to that mark, and suppresses the area's own :focus-visible outline. The title is specific and follows the conventional commit format, and it is concise. Its wording is a bit long at 81 characters, but it is clear.

Full details: Description check

Explanation

The description follows the repository template. It has Problem, Change, Scope and approval, and Verification sections. The Problem section gives the expected behavior and reproduction steps. The Change section explains the mechanism and why the related composer-refocus check changed. The Scope section links issue #28166. Verification lists focused test commands with results, named failing tests before the fix, the real-app before and after comparison, and what was not checked (Wayland). The description does not include screenshots or recordings, and says they could not be attached. The template asks for before/after screenshots for UI changes, so this is a gap. The description also says the evidence is recorded in a table instead. The author should attach the screenshots or recordings, or link them, if they can be uploaded. The model line appears at the end as the template requests.

Full details: Linked Issues check

Explanation

Issue #28166 requires no ring when focus returns to a clicked workspace area without keyboard navigation, while preserving the ring for keyboard navigation such as F6. workspaceFocus.ts marks only keyboard-visible arrivals and clears the mark on pointer input and disposal. index.css suppresses the area :focus-visible outline and draws the ring only for the mark. The browser tests cover click, bare key input, window-return refocus, F6 navigation, dialog return, and the already-focused F6 case. The related composer-refocus check reads the same mark.

Full details: Out of Scope Changes check

Explanation

The changes stay within the linked issue scope. The controller state, CSS selector, composer-refocus selector, and browser tests all support correct workspace-area focus classification. The composer behavior is a direct consequence of the same incorrect :focus-visible classification. No unrelated production feature or unrelated test change is present in the reviewed diff.

Finishing Touches

Generate docstrings

• Commit to this branch
• Create a new PR

Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

[juliusmarminge]

Thanks @juliusmarminge for the original fix and verification! #33525 carried this work into main in 6e4711d, including the focus-ring and composer-return fixes. Closing this as covered.