You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(web): clicked workspace areas no longer show the focus ring after a stray key - #33525
Click an empty part of the conversation or home area. Then press any bare key, such as Shift or Meta. A 2px focus ring appears around the whole area. A window switch can send that key for you (Hyprland focus-follows-mouse, a Super-key window switch), so the ring shows up with no keyboard navigation at all.
The cause is [data-workspace-area]:focus-visible. Chromium turns :focus-visible on for the element that already has focus when a key arrives. The same selector made the window-return check treat a clicked area as "reached from the keyboard", so the caret did not go back to the composer.
Change
The workspace focus controller now marks an area with data-workspace-keyboard-focus only when keyboard focus arrives on it: F6, a focus request, or focus that returns from a dialog. A pointer press, focus moving elsewhere, and dispose clear the mark. Window activation refocuses the same element, so it does not count as an arrival.
The ring in index.css and shouldRefocusComposerOnWindowFocus read the mark instead of :focus-visible.
This replaces #28191 by @juliusmarminge, which was 1160 commits behind main and had a conflict. The five original commits are kept with their authorship. The one conflict was in ChatView.logic.ts: main renamed the sidebar selector to [data-sidebar-row]:focus-visible, and this branch keeps that name.
…e key press
A workspace area focused by a mouse click starts matching :focus-visible
once a lone key (a modifier delivered by a window switch) reaches the page,
so it draws the area focus ring and counts as keyboard-reached on window
return. Areas reached with F6 keep both.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Chromium's :focus-visible turns on for an area the user clicked as soon as
any bare key reaches the page, such as a modifier delivered on window
activation. That drew the F6 ring around the clicked home or conversation
area and blocked the composer refocus on window return.
The workspace focus controller now marks an area when it focuses the area
itself and :focus-visible matches at that moment. Focus moving to another
element or a pointer press clears the mark; a window switch does not. The
ring and shouldRefocusComposerOnWindowFocus read that mark instead of bare
:focus-visible, and the area rule also suppresses the UA focus ring.
Fixes#28166
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mark an area on focusin when focus arrives there from elsewhere and is
keyboard-visible, instead of only when the controller focuses it, so focus a
dialog returns to the area keeps its ring. Window activation refocuses the same
element and is not an arrival, so a clicked area still never rings.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Macroscope's review found this PR approvable — Workspace focus rings and window-return focus now use an explicit keyboard-focus marker, avoiding stray rings after pointer interaction. The change is limited to transient UI focus behavior and preserves existing input and popup protections.
You can add or adjust custom eligibility rules. Learn more.
No actionable comments were generated in the recent review.
Walkthrough
Workspace focus handling now marks areas reached by keyboard navigation. The focus-ring styling and composer-refocus eligibility use this marker instead of relying on :focus-visible for workspace areas.
Changes: Workspace focus behavior
Layer / File(s)
Summary
Track keyboard focus on workspace areas apps/web/src/lib/workspaceFocus.ts, apps/web/src/lib/workspaceFocus.browser.test.ts
The controller sets and clears a keyboard-focus marker during focus changes and pointer interaction. Browser tests cover focus-ring behavior for clicked and keyboard-reached areas.
Use the marker for focus display and refocus apps/web/src/index.css, apps/web/src/components/ChatView.logic.ts, apps/web/src/components/ChatView.logic.browser.test.ts
Workspace-area focus styling and composer-refocus eligibility use the marker. A browser test checks window-return eligibility around F6 navigation.
The focus-ring change has no identified issue that needs resolution before merge; proceed with normal checks.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title clearly describes the main change: clicked workspace areas no longer show a focus ring after a stray key.
Description check
The description covers the problem, change, linked issue, scope, verification results, screenshots, and known limitations. It follows the required sections and provides specific test details.
Linked Issues check
Issue [#28166] requires no ring after non-keyboard focus and a ring for F6 navigation. workspaceFocus.ts marks an area only on keyboard-visible focus arrival and clears the mark on pointer input or …
Out of Scope Changes check
All changes support [#28166]. The controller and CSS implement the focus-ring behavior. The browser tests verify the behavior, and the ChatView.logic.ts change keeps window-return focus handling con…
Full details: Linked Issues check
Explanation
Issue [#28166] requires no ring after non-keyboard focus and a ring for F6 navigation. workspaceFocus.ts marks an area only on keyboard-visible focus arrival and clears the mark on pointer input or other focus. index.css draws the ring only for the marked focused area. Browser tests cover a click followed by bare Shift, simulated refocus, F6 navigation, and pointer clearing. ChatView.logic.ts uses the same mark for window-return composer refocus.
Full details: Out of Scope Changes check
Explanation
All changes support [#28166]. The controller and CSS implement the focus-ring behavior. The browser tests verify the behavior, and the ChatView.logic.ts change keeps window-return focus handling consistent with the new keyboard-focus marker. No unrelated changes appear in the pull request 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
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 7 remain after this review.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size:M30-99 changed lines (additions + deletions).vouch:trustedPR author is trusted by repo permissions or the VOUCHED list.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
vouch:trusted
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
kupiainen
left a comment
Problem
Click an empty part of the conversation or home area. Then press any bare key, such as Shift or Meta. A 2px focus ring appears around the whole area. A window switch can send that key for you (Hyprland focus-follows-mouse, a Super-key window switch), so the ring shows up with no keyboard navigation at all.
The cause is
[data-workspace-area]:focus-visible. Chromium turns:focus-visibleon for the element that already has focus when a key arrives. The same selector made the window-return check treat a clicked area as "reached from the keyboard", so the caret did not go back to the composer.Change
The workspace focus controller now marks an area with
data-workspace-keyboard-focusonly when keyboard focus arrives on it: F6, a focus request, or focus that returns from a dialog. A pointer press, focus moving elsewhere, and dispose clear the mark. Window activation refocuses the same element, so it does not count as an arrival.The ring in
index.cssandshouldRefocusComposerOnWindowFocusread the mark instead of:focus-visible.This replaces #28191 by @juliusmarminge, which was 1160 commits behind
mainand had a conflict. The five original commits are kept with their authorship. The one conflict was inChatView.logic.ts:mainrenamed the sidebar selector to[data-sidebar-row]:focus-visible, and this branch keeps that name.Scope and approval
Fixes #28166
Verification
Web app from
vp run dev, T3 Code browser panel, 1280x800. Steps: click the empty conversation area, then press Shift.main2da1b74)outline: solid 2pxoutline: noneF6 still shows the ring, and a click removes it again:
vp test run --project browser src/lib/workspaceFocus.browser.test.ts src/components/ChatView.logic.browser.test.ts(apps/web): 21 passed.vp run check:changed: format, lint, knip, typecheck, tests, and React compiler pass.Not checked:
Original work: Claude Opus 5.5 and GPT-6.1 Sol in T3 Code. Rebase, conflict fix, and verification: Claude Fable 5 in Claude Code.
🤖 Generated with Claude Code