fix(web): model picker no longer shows a double border - #7772

💭 I'm looking at how the PR strips the dropdown-glass class and shadow/clip-path from ModelPickerContent, while ProviderModelPicker now lets the MenuPopup's default glass styling apply instead of overriding border/background/shadow/backdrop-filter, clipping the viewport with an inner radius. I want to check the MenuPopup implementation to see if removing those override classes restores default padding that could cause layout issues.

1. browse_code — apps/web/src/components/ui/menu*.tsx

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

💭 Now I want to check how PopoverPopup is implemented.

3. browse_code — Show the full implementation of PopoverPopup in apps/web/src/components/ui (popover.tsx): its default classes, viewportClassName usage, --viewport-inline-padding variable, before:* pseudo-element, dropdown-glass class, and how ScrollArea/viewport is composed.

💭 I'm recalling that previously the glass styling lived on ModelPickerContent's root while the PopoverPopup was made transparent, so only one border showed up from the inner content. Now I'm reconsidering the fix: move the glass border, background, backdrop-filter, shadow, and rounding onto the popup itself, while the viewport handles padding and inner radius/clip-path, and ModelPickerContent's root drops those glass styles entirely. I want to double-check the hairline hiding and padding variables stay consistent between the two so nothing doubles up again. But I'm now tracing a subtler issue: the viewport declares its own --viewport-inline-padding value that differs from what's set on the popup, and since CSS custom properties inherit down through the DOM, any descendant reading that variable for its width calculation will pick up the viewport's own declared value rather than the popup's override — meaning the transition width math could end up using the wrong padding amount and miscalculate the element's width. The radius math checks out since the viewport sits inside the popup's border, so subtracting 1px gives the correct inner corner. I'm also verifying the overflow and clip-path handling stayed consistent between root and viewport, and now I'm checking whether moving the glass background from the root to the popup still preserves the backdrop-filter effect correctly. Nested popups within ModelPickerContent that use backdrop-filter would be portaled, so that's fine. Let me check ModelPickerContent itself for scroll fades, virtualized lists, or any styling that depends on its own root radius or shadow.

4. browse_code — apps/web/src/components/chat/ModelPickerContent.tsx

💭 I'm checking whether the sidebar background is translucent, since that would mean the popup's glass effect relies on it for the intended layered look. I'm also verifying that moving the glass background from the content root to the popup doesn't change sizing, and noting a potential issue with the viewport inline padding being zeroed out. Tracing through how tailwind-merge resolves the conflicting padding classes, I conclude the padding variable still propagates to descendants at its original value, so the width calculation for transitioning elements stays unaffected — not a real regression since there's only one child anyway. Now I'm examining whether stripping the p-0 border-0 bg-transparent shadow-none classes from the popup changes anything meaningful. Since the Popup element has no default padding (that lives on the viewport), p-0 was always a no-op, so removing it is harmless. I'm also checking that the glass blur effect isn't now doubled since only the popup carries backdrop-filter, and confirming the border renders cleanly against the viewport's clip-path, which actually fixes a prior double-border issue. The one open question is whether hiding the inner hairline via before:hidden creates an inconsistency with other dropdowns in the shared component system that do show that highlight — worth flagging as a possible call-site override of the primitive's styling. Tracing the paint order, the before pseudo-element sits below the in-flow viewport content since both are positioned and the before comes first in DOM, so the translucent background would only partially reveal it anyway — not a strong finding. I'm now considering whether the clip-path rounding on the viewport could be a more concrete issue worth investigating. The overflow-hidden with !important is preexisting behavior since the variant-prefixed overflow-y-auto class survives tailwind-merge. I'm also checking that restoring dropdown-glass on the popup doesn't create corner artifacts since the viewport's clip-path already handles rounding, and noting the popup shadow now comes from the default PopoverPopup styling. I should also consider whether the added border width affects the popup's measured width calculation, though that's likely handled fine. Let me check if other popover components already use a similar full-bleed viewport pattern for consistency, searching for viewportClassName usage elsewhere.

5. git_tools — viewportClassName

6. git_tools — data-model-picker-content|dropdown-glass

💭 I should check whether ModelPickerContent is used anywhere besides ProviderModelPicker, since removing the glass/rounded/shadow styling from its root could break other call sites like a command menu or Menu-based picker.

7. git_tools — ModelPickerContent

💭 Good, only one consumer found. Now I should check whether any tests reference ModelPickerContent classes like dropdown-glass or clip-path, beyond the ComposerCommandMenu tests I already found, so I'll search for tests referencing model picker classes specifically.

8. git_tools — clip-path|bg-transparent|border-0

9. browse_code — apps/web/src/**/odelPicker

💭 No tests check for these specific classes, so I'm checking whether there's a regression with how the dropdown-glass background interacts with the popup's transparency and the content's muted background utility, since class ordering and merge behavior could affect which style wins. Since dropdown-glass isn't a recognized utility group, both classes apply and CSS declaration order decides the outcome — which was likely the source of the earlier double-border bug where border-0 didn't win. This PR removes that ambiguity, which is an improvement. I'm also checking whether the sidebar's background stays transparent so the glass effect still shows through correctly, and confirming that removing rounded-lg and text-popover-foreground from the content root doesn't break the corner clipping, since that's now handled by clip-path on the viewport instead. I'm verifying the viewport actually matches the popup's inner content box dimensions, and tracing through whether the redundant --viewport-inline-padding:0 setting on the popup still has any effect now that padding is zero — it seems harmless since the viewport's own declaration takes precedence for descendants anyway, consistent with the prior behavior. The real fix is confirming the double-border issue stemmed from both the popup and ModelPickerContent applying dropdown-glass borders independently, creating two visible 1px borders; consolidating to a single glass border on the popup resolves this and matches other primitives, with no apparent accessibility regression. The scroll fades are mask-based on an inner element so they're unaffected. I'm checking whether moving the clip-path from the content root to the viewport could clip the scrollbar lane's corners at the rounded edges, since the scrollbar sits at the right edge inside the content while rounding now happens at the outer viewport level. Working through the geometry, the new radius position is just 1px inward from before, so it's effectively identical — no real regression there. Given that, I'm leaning toward there being no actual findings here, though I need to reconcile that with the response format requirements: the instructions mention outputting "All clear" as plain text, but the system also requires a structured JSON response, so I'll represent the "no issues found" result within that JSON schema instead, marking it as a success state. That's consistent with how other popovers behave already. I don't think dedicated tests for ProviderModelPicker rendering are necessary since this is purely visual, but I should double-check index.css for any rules targeting the popover-popup slot or model-picker-specific overrides that assumed transparency.

10. git_tools — model-picker|popover-popup|popover-viewport

💭 No global CSS specific to the model picker, so I want to check the git history for ProviderModelPicker to see if a past commit deliberately made the popup transparent, perhaps for mobile or inline-preview mode.

11. git_tools — apps/web/src/components/chat/ProviderModelPicker.tsx

💭 That commit title about fixing glass hover compositing artifacts catches my eye — it might be where they added a backdrop-filter override to the popup to prevent compositing issues. I want to check that.

12. git_tools — ece0508

💭 I recall the backdrop-filter was disabled on the popup specifically to avoid nested compositing artifacts, since the inner content already applied its own glass effect. Now that the glass lives only on the popup and the content no longer has backdrop-filter, that conflict shouldn't exist anymore. I should double check there's no other nested backdrop-blur element still inside ModelPickerContent, Sidebar, or ModelListRow, and confirm the model-picker-surface class was fully removed from index.css rather than just relocated. I also want to trace the git blame on that line to see what prior commit set up this transparent popup state before the current PR touched it.

13. git_tools — apps/web/src/components/chat/ModelPickerContent.tsx

14. git_tools — backdrop-blur|backdrop-filter|glass

💭 Good, no nested glass remains. I'm checking the border math on the popup: content root is 360px wide with a 1px border on each side, bringing total popup width to 362px, consistent with before since the old border-0 was likely ineffective anyway. The viewport fills the popup's content box at 100%, so its width is still governed by that 360px max-width. I'm also checking whether dropdown-glass still carries its box-shadow after the refactor moved it elsewhere, and confirming light mode doesn't need bg-clip-padding here since that's only used in other solid-variant surfaces. The one thing worth flagging is that before:hidden is still being applied to suppress the shared inner hairline — now that the popup itself owns the glass surface, that override may no longer be justified since other popovers still show the hairline, though I need to check whether the viewport's clip-path would even let it render visibly. That tooltip glass precedent confirms this isn't a real finding. I'm also checking whether the leftover --viewport-inline-padding declaration is dead code, but since it predates the changed lines it's not a reportable regression, just a minor nit. Similarly, the combination of rounded corners and clip-path looks redundant but likely serves a cross-browser clipping purpose, so it's harmless rather than a violation. Now I'm verifying that the clip-path doesn't interfere with scroll behavior or the input's focus ring, and confirming light mode contrast remains unchanged from before. I'm also considering whether the clip-path creates a new stacking context on the viewport that could affect layering. Actually, I'm catching a potential bug: the arbitrary value calc(var(--radius-lg)-1px) is missing whitespace around the minus operator, which makes it invalid CSS since calc() requires spaces around - when used as subtraction. But since this exact pattern appears throughout the codebase's shared primitives, I suspect Tailwind v4 automatically normalizes spacing in arbitrary calc expressions. I'm trying to recall how Tailwind v4's whitespace-normalization logic tracks nested functions, since it needs to detect when it's inside a math function like calc, min, max, or clamp even when nested inside something like inset(). Since calc() is the innermost enclosing function around the minus sign, the spacing rule applies, turning it into calc(var(--radius-lg) - 1px). I'm also wondering whether arbitrary properties like [clip-path:...] go through the same decoding and whitespace-normalization path — I believe they do, since arbitrary property values use the same decodeArbitraryValue function. I'd like to check if there's precedent in the codebase for a nested calc inside an arbitrary property wrapped in a non-math outer function, so let me search for combinations like [clip-path:inset( paired with calc.

15. git_tools — clip-path:inset

16. git_tools — _calc(var(

💭 There's precedent in card.tsx for this clip-path pattern, so it's established and works. I'm checking how the popup's translucent border interacts with background-clip — since the background paints under the border by default, the semi-transparent border color blends with the glass background beneath it, making it appear slightly different than intended. This behavior isn't unique to this change though — other primitives like contextMenuFallback, tooltip, and card use bg-clip-padding, but PopoverPopup doesn't, so all popovers share this same quirk already. I'm also verifying the viewport's padding, the popup's rounded corners against the content's height constraints (clip-path should handle any overflow), and confirming that removing bg-transparent from the popup doesn't change the visual stack — tracing through it, the background layering ends up identical to before since the content's own bg-muted/40 still sits on top of the same glass base. Given everything checks out with no real issues found, I'll structure the response as a success state with a minimal title and put "All clear" as the summary, per the instruction to keep the final output to that exact phrase.