Repository navigation
fix(web): give permission options even rounded highlights - #28837
gitRasheed wants to merge 4 commits into
Conversation
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — The permission selector gains rounded inset highlights while retaining continuous hover targets. Permission choices, defaults, and selection behavior remain unchanged. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Permission option styling apps/web/src/components/chat/ComposerFooterControls.tsx |
The radio group removes its padding. Options use padded, full-height layouts with selected and highlighted backgrounds and the focus ring on an inner span. |
Estimated code review effort: 1 (Trivial) | ~5 minutes
Change: Bug fix
Possibly related PRs
- pingdotgg/t3code#25869: Adds
ComposerPermissionsSectionand its horizontal runtime-mode options. - pingdotgg/t3code#28840: Changes the permission section’s surface and selection styling.
- pingdotgg/t3code#26514: Removes gaps between the same permission radio options and rounds the row edges.
Suggested reviewers: t3dotgg
Merge Risk: 
Minimal · up to 97e61
-
The permission control retains its visible keyboard focus indicator. No merge-blocking issue was identified.
Pre-merge checks: 
4
-
Full details: Title check
-
Explanation
The title "fix(web): give permission options even rounded highlights" follows the conventional commit format and names the main change. The change gives each permission option a square hit area with a rounded inner highlight span, so all four options look like the end options. The summary and objectives both describe this change. The title is specific and accurate. The wording is terse, so "even rounded highlights" may read awkwardly, but the intent is clear.
Full details: Description check
-
Explanation
The description follows the repository template closely. It has the Problem, Change, Scope and approval, and Verification sections. The Problem section states the bug and the cause. The Change section explains the inner rounded span and why the option itself was not rounded. The Scope section explains why no prior issue is linked and why the change qualifies as a small styling fix to an existing control. The Verification section gives concrete checks with observed results (923 of 7,616 points on main, 0 with the change), lists the tests run, includes before/after and focus screenshots, and names what was not checked (Electron shell, mobile). It also includes the model and harness line that the template requests. The description gives no formal linked issue or maintainer approval for the scope. It relies on an argument that the fix is a small obvious styling correction. The reviewer may need to confirm that this argument meets the template's scope requirement. The template's comment asks for a prior triaged issue or a qualifying explanation, and the author supplied the explanation.
-
Finishing Touches
-
Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
…t-highlight # Conflicts: # apps/web/src/components/chat/ComposerFooterControls.tsx
Problem
#26514 removed the gap between the permission options so the hover preview no longer drops out between them. To do that it rounded only the two outer ends of the row. Auto-accept edits and Auto, in the middle, now get a square highlight that runs into the next option, with 2px of track above and below it and none at the sides.
The hover colour also comes from a different token than the selected colour. In the light theme, hover uses opaque zinc-100, which is lighter than the zinc-300 track, so a hovered option looks like a hole in the row.
Change
Each option is still a square hit area with no gap between options, so the hover fix from #26514 stays. The highlight moves to an inner span with rounded corners and a 2px inset on every side, so all four options look like the end ones. The track's padding moves onto the options, which makes the outer 2px of the row hoverable too.
I didn't round the option itself because Chrome hit-tests rounded corners, and that version left small dead spots where neighbouring corners meet.
Hover now uses
bg-input/32, the same pairing the sharedsegmentedtoggle uses in dark (input/32hover,input/72selected). In dark it looks the same as before. In light it sits between the track and the selected option.Scope and approval
This is a small styling fix to one existing control, with no change to behaviour, so it comes without a prior issue. Selection, closing on pick, keyboard navigation and labels are unchanged. #26702 also edits these lines.
Verification
Hover in default dark, default light and T3 Chat light, main on the left:
Keyboard focus with Left/Right:
I checked every 1px point across the row with
document.elementFromPointand counted points that hit no option: 923 of 7,616 on main, 0 with this change.vp run check:changedandComposerPermissionsSection.browser.test.tsxpass.I checked the web client in Chrome. Desktop renders the same web component; I didn't open the Electron shell. Mobile has its own native controls and isn't affected.
Model: Opus 5.5. Harness: Claude Code in T3 Code. Adversarial review: GPT-6 Astra.