fix(web): unify control sizing across settings pages - #9281

💭 I want to check how the repo handles size variants for Switch, Button, and Select components. I need to verify whether adding a size prop to Switch conflicts with existing Base UI Root props, and I'm looking at call sites like BranchToolbarBranchSelector.tsx where a manual thumb-size class was replaced with a size="sm" prop to see if that changes behavior. I'm also verifying that button variants like icon-xs and icon-micro properly set icon sizing, that selectTriggerVariants is correctly exported and used in SelectTrigger and ComboboxTrigger with the new "sm" size, and checking whether size="compact" still exists after usages were migrated to icon-xs. I'm noticing the FontFamilyPicker change drops w-full, min-w-36, cursor-pointer, and the muted chevron color in favor of selectTriggerVariants — this could be a real width/style regression if those utilities aren't baked into the variant. I also need to confirm ServerUpdateAction's new size prop has the right ComponentProps import before diving into the actual files.

1. browse_code — apps/web/src/components/ui/select.tsx

2. browse_code — apps/web/src/components/ui/button.tsx

💭 Checking FontFamilyPicker's trigger styling — it keeps the default variant's w-full min-w-36, but the size shrinks from default to sm, changing padding and min-height slightly, which seems like an intentional adjustment per the PR. I'm also noting the old styles had text-foreground, shadow, background, and dark mode variants that need to be accounted for. Verifying the chevron icon still gets the muted color from the variant's SVG selector even though its className was simplified. Now I'm shifting focus to Switch — checking whether Base UI's SwitchPrimitive.Root accepts a size prop, and whether the destructured size still gets forwarded via spread props or leaks into data-size placement relative to className. I'm now examining whether moving the thumb-size custom properties from the base class string into a conditional default branch could break other call sites that override [--thumb-size:...] via className, since tailwind-merge treats those as arbitrary-property conflicts scoped by variant. I need to check switch.tsx directly and search for other usages of thumb-size overrides across the codebase.

3. browse_code — apps/web/src/components/ui/switch.tsx

4. git_tools — thumb-size

💭 I'm noticing the git_grep results actually reflect the merge base commit rather than head, since the old-style thumb-size values still appear in switch.tsx and the branch selector — so the grep must default to the repo's clone commit rather than current head. Checking DiffPanel.tsx's switch usage: since the unprefixed --thumb-size from className overrides the base one but the sm: variant is untouched, the behavior matches the original code exactly, so there's no regression there. Now I'm turning to check the BranchToolbarBranchSelector's switch usage next. Looking at BranchToolbarBranchSelector and ProviderModelsSection, the thumb-size changes across breakpoints seem intentional for touch targets, not bugs. I'm also checking whether data-size placement before spread props could get overridden by consumers, but nothing currently reads that attribute so it's a minor non-issue. I want to confirm there's no type conflict with size on the Switch Root props, since Base UI renders a button (where size isn't a valid HTML attribute) rather than an input, so this shouldn't cause a type error. Now I'm verifying call sites like DiagnosticsSettings where cn(isPending && "animate-spin") can produce an empty className — confirming the :not([class*='size-']) selector still matches and applies sizing correctly in that case. The icon-xs change intentionally bumps icons from size-3 (old icon-micro) to size-4/3.5, unifying sizing per the PR. I'm now checking the SourceControlSettings DiscoveryItemRow's size="compact" → size="icon-xs" swap to confirm context matches expectations. I also notice ConnectionsSettings dropped size="xs" on an outline button, defaulting it to a larger size inside a list row—that seems to contradict the PR's documented sizing tiers, so I want to check the surrounding buttons for consistency. Similarly, AddProviderInstanceDialog removed size="sm" from footer buttons, which lines up with the stated rule that dialog footers use the app-wide default size, but I should verify those specific lines are indeed footer buttons. I need to check whether removing the compact className on that ConnectionsSettings badge actually left the size prop unchanged or made it bigger, so let me open the relevant hunks across ConnectionsSettings, SourceControlSettings, AddProviderInstanceDialog, KeybindingsSettings, ProviderInstanceCard, ProviderSettingsForm, and settingsLayout to compare before and after.

5. browse_code — apps/web/src/components/settings/ConnectionsSettings.tsx

6. browse_code — apps/web/src/components/settings/ConnectionsSettings.tsx

💭 I'm checking that the size change at line 3424 is just a visual bump consistent with the "headerAction xs" tier, then moving on to check the button in the DialogFooter at line 788. Now I'm moving on to check SourceControlSettings' DiscoveryItemRow around line 315.

7. browse_code — apps/web/src/components/settings/SourceControlSettings.tsx

8. browse_code — apps/web/src/components/settings/SourceControlSettings.tsx

💭 I'm confirming the icon button size upgrade in DiscoveryItemRow looks like an improvement, then checking the KeybindingsSettings button height change from h-7 to h-8 with a responsive sm:h-7 override, verifying the class ordering is still correct. Next I want to check whether that removed size class on line 957 was actually redundant with the button's size prop, or whether it changes the mobile size unexpectedly — I need to look at what size variant (icon vs icon-sm) is applied there. I also still need to review the cancel icon button, the ProviderInstanceCard and ProviderSettingsForm regions, and confirm FontFamilyPicker's ComboboxTrigger doesn't already handle sizing before I check these files in detail.

9. browse_code — apps/web/src/components/settings/KeybindingsSettings.tsx

10. browse_code — apps/web/src/components/settings/KeybindingsSettings.tsx

💭 That icon size change looks good—mobile gets a bigger touch target now instead of the previously forced smaller size. Next I need to check the ProviderInstanceCard sections around those two line ranges.

11. browse_code — apps/web/src/components/settings/ProviderInstanceCard.tsx

12. browse_code — apps/web/src/components/settings/ProviderSettingsForm.tsx

💭 I'm comparing the icon button sizing at line 682 — the new "icon-micro" size gives a 20px button with a default size-3 icon, but here it's overridden to size-3.5, whereas the old version used icon-xs with a forced size-5 button via custom classes. That matches up geometrically, confirming this is a valid migration since icon-micro's fixed 20px size holds across breakpoints like the old override did. For line 749, I'm checking icon-xs replacing a manually sized 24px button — icon-xs defaults to 28px on mobile down to 24px on larger screens, and swaps rounded-sm for the theme's control radius, which should still fit fine within the row's height. Now I'm looking at the ProviderSettingsForm span classes and moving on to check other settings elements for similar sizing patterns. I'm now examining SETTINGS_PICKER_TRIGGER_CLASSNAME, which adds fixed h-8/min-h-8 (with sm h-7/min-h-7) to the trigger — I need to verify whether the picker components it's applied to use fixed heights or padding-driven sizing, since forcing a height could clip content if the trigger relies on padding. I'm tracking down the call sites in ProjectSettingsPanel, SettingsPanels, and SourceControlWritingSettings to check each one.

13. browse_code — apps/web/src/components/settings/ProjectSettingsPanel.tsx

14. browse_code — apps/web/src/components/settings/settingsLayout.tsx

💭 The doc comment about pinning heights to 28px is a bit confusingly worded relative to the mobile h-8 class, but it's explaining the sm control box override rather than a real inconsistency, so I'll let it be. Moving on to check the ProviderModelPicker and TraitsPicker components next.

15. git_tools — triggerClassName

16. browse_code — apps/web/src/components/chat/ProviderModelPicker.tsx

17. browse_code — apps/web/src/components/chat/TraitsPicker.tsx

💭 I'm checking whether ComposerControl's base height class is unprefixed h-7, since the new trigger classname's h-8/min-h-8 mobile override with sm:h-7 restoration depends on tailwind-merge deduping in favor of whichever class comes later in the consumer's className.

18. git_tools — composerControlVariants|function ComposerControl

19. browse_code — apps/web/src/components/chat/ComposerControl.tsx

💭 The composerControlClassName sizing checks out—mobile gets 32px height while sm breakpoint gets 28px, matching the button sizing pattern. The TraitsPicker outline variant looks fine too. Now I want to look at the FontFamilyPicker file to check its imports and layout structure.

20. browse_code — apps/web/src/components/settings/FontFamilyPicker.tsx

21. browse_code — apps/web/src/components/settings/SettingsPanels.tsx

💭 I'm checking that the FontFamilyPicker trigger's sizing classes from the new variant match its old explicit classes, confirming min-h-8/sm:min-h-7 aligns consistently with the sibling Input size="sm" styling. I want to verify that ComboboxTrigger doesn't have its own conflicting base classes that would clash with the new variant string's pseudo-element styles, since previously the className was just merged as a plain string via cn. I should also confirm the width/flex behavior stays consistent between the picker trigger and the Input alternative, and double-check ComboboxTrigger's base styles for cursor and flex display.

22. git_tools — function ComboboxTrigger

💭 I'm comparing the trigger's className against the base variant styles, checking that select-none and focus-visible ring treatments carry over correctly to the new version. Now I want to confirm the size="sm" prop plays nicely with existing width classes like w-full sm:w-40, and I should check whether any Button in ConnectionsSettings still hardcodes h-7 alongside the new size prop. I'll pull up the specific hunks around lines 2780-2880 and 3060-3075 to verify there's no conflict.

23. browse_code — apps/web/src/components/settings/ConnectionsSettings.tsx

24. browse_code — apps/web/src/components/settings/ConnectionsSettings.tsx

💭 I should check ServerUpdateAction next to confirm the size prop and ComponentProps import are set up correctly, and verify all buttons in that file actually receive the size prop consistently—there might be an extra button like a copy or dropdown trigger still stuck at "xs" that I'd need to reconcile.

25. browse_code — apps/web/src/components/ServerUpdateAction.tsx

26. browse_code — apps/web/src/components/ServerUpdateAction.tsx

💭 I still need to update several more files with the same size-token replacements: AddProviderInstanceDialog, IntegrationsSettings, ProviderModelsSection, ProviderSettingsPanel, and SettingsPanels, tracking each specific icon/button size change and any className adjustments that come with them. Now I'll check AddProviderInstanceDialog around lines 375-440 next.

27. browse_code — apps/web/src/components/settings/AddProviderInstanceDialog.tsx

28. browse_code — apps/web/src/components/settings/ProviderModelsSection.tsx

💭 Next I want to verify the ProviderModelsSection around the add-model row where size and Button props were changed, then check the IntegrationsSettings section further down.

29. browse_code — apps/web/src/components/settings/ProviderModelsSection.tsx

30. browse_code — apps/web/src/components/settings/IntegrationsSettings.tsx

💭 These all look consistent, so I'm moving on to check ProviderSettingsPanel, ThemeEditorPanel, SettingsPanels, ProjectSettingsPanel, and DiagnosticsSettings, specifically looking for cases where a size prop was added to a component that isn't a Button or Select.

31. browse_code — apps/web/src/components/settings/SettingsPanels.tsx

32. browse_code — apps/web/src/components/settings/SettingsPanels.tsx

💭 I want to check whether Input's size prop actually supports "sm" and confirm it doesn't leak through as the native HTML size attribute on the input element, since that would set character width unintentionally—I should verify this in ui/input.tsx.

33. browse_code — apps/web/src/components/ui/input.tsx

💭 Input's sizing matches Button's height calculations properly at 32px/28px for consistency. Now I need to verify DraftInput passes size through correctly, and check whether ProviderSettingsForm's usage of DraftInput with size="sm" is actually supported.

34. git_tools — function DraftInput

💭 Now I need to check the other places using size="sm" - ProjectSettingsPanel at lines 798 and 1195, ThemeEditorPanel around 931/953, and SettingsPanels at line 2419, to see which components those apply to.

35. browse_code — apps/web/src/components/settings/ProjectSettingsPanel.tsx

36. browse_code — apps/web/src/components/settings/ProjectSettingsPanel.tsx

💭 Everything checks out consistently across those sections. I still want to spot check the ThemeEditorPanel and ProviderSettingsPanel more closely before moving on.

37. browse_code — apps/web/src/components/settings/ThemeEditorPanel.tsx

38. browse_code — apps/web/src/components/settings/ProviderSettingsPanel.tsx

💭 I should check whether the DiagnosticsSettings button with size="icon-xs" is nested inside an InputGroup, since that would affect how the svg gets sized—the input-group's own rules might override the icon-xs variant. Let me look at lines 1120-1145 to confirm.

39. browse_code — apps/web/src/components/settings/DiagnosticsSettings.tsx

40. browse_code — apps/web/src/components/settings/DiagnosticsSettings.tsx

💭 I'm checking that the spinning refresh icon's className logic still works fine when not pending, and reviewing the keybinding settings styling and the search size prop change to see what component it's applied to. Looking further, I'm confirming that Input's "sm" size is compatible with the previous "compact" size, and verifying no leftover "compact" size references remain. I'm also tracing which Switch instances received the new "sm" size versus which keep the default, and considering whether Base UI's className-as-function pattern could cause an issue if a consumer passes a function to the Switch's className prop. Working through it, I realize clsx silently ignores function values, so this isn't a bug introduced by the current changes—it's pre-existing behavior. I also check whether ordering data-size before spread props matters, but nothing depends on that attribute, so it's not a real finding. Now I'm cross-referencing the doc comment about the picker trigger's classname against the actual button sizing to see if they match. The height math checks out—h-8 min-h-8 sm:h-7 sm:min-h-7 correctly mirrors the sm variant, and the note about ComposerControl pinning to h-7 at all breakpoints explains why the override exists. I confirm this is consistent, then move on to verify the various SelectTrigger and Button size props used elsewhere are all valid values, before looking at a specific sm-sized element in KeybindingsSettings to see if it belongs to an Input inside an InputGroup.

41. browse_code — apps/web/src/components/settings/KeybindingsSettings.tsx

42. browse_code — apps/web/src/components/settings/KeybindingsSettings.tsx

💭 I'm checking the input size change from compact to sm, verifying the padding and icon positioning still line up correctly, and noting that compact previously included a rounded-md on the outer wrapper that I need to account for. I'm scanning for other regressions from the sizing unification: the KeybindingKeyControl pill height matches fine, the search input text size just shifts slightly larger which is cosmetic, and a few button size overrides in SourceControlSettings and ConnectionsSettings look harmless. I'm also checking the Switch component's thumb size on mobile, which actually got a bit larger than before—no regression there either. Now I'm checking FontFamilyPicker, which uses the small select trigger variant on a ComboboxTrigger, confirming the border, background, and responsive text sizing all carry through correctly. I'm also comparing its min-height against the Input component's small size to make sure the 32px/28px totals line up—they do match once accounting for borders, so this trigger's sizing looks consistent. I also want to check the Switch component, which is in scope for review. It uses a plain union type with a size prop rather than cva like Button and Select, but since it still exposes a proper size prop, that's just a stylistic difference rather than an actual issue. Now I want to check if any global styles or other components target the switch's data-slot based on thumb size.

43. git_tools — data-slot=switch|data-size

💭 I'm wondering whether adding a default data-size attribute to Switch could unintentionally interact with InputGroup sibling selectors that target [data-size=sm], so I want to check if Switch is ever actually rendered inside an InputGroup next to addons. The realistic candidates seem to be ProviderModelsSection and BranchToolbar, so let me look at the BranchToolbarBranchSelector code around line 853 to confirm the context there.

44. browse_code — apps/web/src/components/BranchToolbarBranchSelector.tsx

💭 The size change from a fixed 14px thumb to a responsive sm size means mobile gets a slightly larger 16px thumb while desktop stays at 14px, which fits the compact popover footer fine. I'll move on to double-check the ConnectionsSettings region around lines 2869-2875. I want to verify that no leftover conflicting className strings remain alongside the new size props, like a Button with size="sm" plus a redundant h-7 class — the PR appears to have cleaned these up already. I should also confirm the ComponentProps type import in ServerUpdateAction was pre-existing rather than newly added, which it seems to be since it was already used for variant. Now I'm curious whether the PR introduces an inconsistency by changing one control's size without matching sibling controls in the same row — specifically the ArchivedThreadsPanel button around line 2848 where size="xs" replaced several utility classes. I want to look at the surrounding list item to confirm xs is the right tier there.

45. browse_code — apps/web/src/components/settings/SettingsPanels.tsx

💭 This control slot button was changed from size="sm" (with an h-7 override) to size="xs", but that contradicts the PR's own documented tier for control-slot buttons in settings rows — every other one was normalized to sm, so this seems like an inconsistency. The result is that "Unarchive" now renders at 24px on desktop while sibling settings-row controls stay at 28px, a genuine deviation worth flagging even though the archived list context could arguably justify denser controls. I want to check whether other SettingsRow control slots elsewhere in the codebase adopted xs after this PR, to see if this is an isolated slip or part of a broader pattern.

46. git_tools — size="xs"

💭 I notice the dialog footer's "Copy code" button was normalized to default size, consistent with DialogFooter conventions. Now I'm checking the ArchivedThreadsPanel button in the SettingsRow control slot, comparing it against other control-slot buttons that were normalized to sm in this PR to see if it fits the same list-item pattern. Confirming this is a genuine deviation: the ConnectionsSettings and ResourceTelemetryDiagnostics changes both establish sm as the intended size for control-slot buttons, so this ArchivedThreadsPanel button using xs contradicts that established rule. It's a small but real consistency finding worth flagging inline. I want to check whether those remaining xs instances at lines 1071 and 1103 are inside a list item context or actual control slots, so I'll look at that surrounding region more closely.

47. browse_code — apps/web/src/components/settings/ProjectSettingsPanel.tsx

💭 Those xs buttons look like section-header actions rather than control slots, consistent with the documented pattern. The real deviation is the ArchivedThreadsPanel control-slot button that changed from sm+h-7 to xs, which is exactly the kind of inconsistency this check should flag against the documented tier. Comparing sizes: the removed classes pinned the button at 28px on both breakpoints, whereas the sm tier would give 32px mobile/28px desktop, and xs gives 28px/24px — a 4px shrink on desktop relative to before and to every other control-slot button. That's a real enough finding to warrant one inline comment with a suggestion, though I'm weighing whether it's significant enough to set the check state to failure versus neutral. Before deciding, I want to double-check for other size-prop changes I might've missed across the diff, so I'm rechecking ConnectionsSettings, ProviderInstanceCard, IntegrationsSettings, and a couple spots in SettingsPanels to make sure nothing else got dropped or mismatched.

48. browse_code — apps/web/src/components/settings/SettingsPanels.tsx

49. browse_code — apps/web/src/components/settings/ProviderInstanceCard.tsx

💭 I'll flag the control-slot tier deviation on SettingsPanels.tsx line 2848, then reconsider the ProviderInstanceCard change—swapping icon-xs for icon-micro removes the size-5 rounded-sm padding, but icon-micro's base class already sets a smaller default icon size while the explicit size-3.5 override should still take precedence. Working through the tailwind-merge behavior, I realize the previous className would only override the base size-7, letting sm:size-6 survive, so the button was actually 20px on mobile but 24px at sm+ breakpoints—whereas icon-micro forces 20px everywhere, shrinking desktop by 4px. That's not a regression though, just the intended unification given the size-5 className already signaled 20px was the goal. Now I want to recheck the DiffPanel switch component's class ordering and how the thumb-size custom properties are applied across breakpoints. DiffPanel's 12px need doesn't map to any named size, so I'll leave it untouched. That leaves ArchivedThreadsPanel as the one real finding worth flagging, and since it's a minor inconsistency rather than a blocker, I'm leaning toward posting it as a suggestion rather than a hard failure. The instructions do say clear consistency risks can fail the check, and this PR literally documents the sizing tier it deviates from in the very area it's unifying, which pushes toward failure. But failing over a 4px button feels heavy-handed, and I should consider whether the author deliberately chose the smaller size to keep a dense archived-thread list compact — similar to how ConnectionsSettings handles its list. Actually, the documentation itself is ambiguous here: it doesn't explicitly say list rows should use xs, only that list items/cards/toolbars do, and archived threads are rendered as list items. So the author's choice is arguably consistent with their own documented rule. Given this genuine ambiguity, and the guidance to avoid guessing when ownership or semantic equivalence can't be proven, I shouldn't fail the check on this point — both readings of the documented tiers are defensible, and everything else checks out fine. Since there are no real findings, per the instructions I should produce a response indicating everything is clear, adapted to fit the required JSON schema — success state with a minimal summary reflecting "All clear."