SvelteKit/bits-ui: Popover triggers incorrectly hydrated with aria-expanded=true/data-state=open
Svelte 4.2.20 + bits-ui 0.22.0 (shadcn-svelte stack), SSR + hydration. Popover triggers written with the documented asChild escape hatch:
<Popover.Root>
<Popover.Trigger asChild let:builder>
<button use:builder.action {...builder} aria-label="…">…</button>
</Popover.Trigger>
<Popover.Content>…</Popover.Content>
</Popover.Root>After hydration every such trigger reports aria-expanded="true" and data-state="open" while the popover is visibly CLOSED and no content element exists in the DOM. The values never change again: opening the popover leaves them true/open, closing with Escape leaves them true/open. A screen reader therefore announces every collapsed trigger on the page as expanded.
The SSR markup is correct — curl of the page shows aria-expanded="false" data-state="closed" on the same button. The wrong value appears only after client-side hydration, so any check against server HTML passes.
Nothing is logged: no hydration warning, no console error, clean svelte-check, and the popover FUNCTIONS normally (click opens, Escape closes, content mounts/unmounts correctly). Only the trigger's own state attributes are wrong.
Dead ends: the attributes are not stale-by-one (they never track state at all); adding bind:open to Popover.Root alone does not fix them, because bits-ui's spread still wins; Tooltip.Trigger asChild with the identical {...builder} spread is NOT affected and reports data-state="closed" correctly, so it is not a generic melt-ui spread-reactivity problem.
This silently poisons browser-automation selectors too: [data-state="open"] and aria-expanded assertions match closed popovers, so tests that wait for a popover to open pass instantly and vacuously.
Both halves of the asChild contract are individually broken; you must supply the state attributes yourself.
An A/B test on two triggers of the same component isolates what each half contributes:
| trigger | aria-haspopup | aria-expanded / data-state | click works |
|---|---|---|---|
use:builder.action + {...builder} | present | present but frozen at true/open | yes |
use:builder.action only | absent | absent entirely | yes |
So use:builder.action carries behaviour only (event wiring), and {...builder} carries the ARIA/state attributes — but for Popover the spread lands on open after hydration and never updates. Dropping the spread to avoid the wrong value just removes all the ARIA instead. Neither half alone is correct.
Fix — bind the open state yourself and re-declare the two attributes AFTER the spread. In Svelte, a literal attribute written after a spread wins over the spread's value:
<script lang="ts">
let open = false;
</script>
<Popover.Root bind:open>
<Popover.Trigger asChild let:builder>
<button
use:builder.action
{...builder}
aria-expanded={open}
data-state={open ? 'open' : 'closed'}
aria-label="…"
>…</button>
</Popover.Trigger>
<Popover.Content>…</Popover.Content>
</Popover.Root>This keeps everything useful from the spread (aria-haspopup="dialog", the generated id, melt's data hooks) and makes only the two state attributes reactive. Verified across hydrate → click-open → Escape-close: values track correctly and, with several popovers on one page, only the clicked instance flips.
Attribute order matters. Putting aria-expanded BEFORE {...builder} restores the bug — the spread overwrites it.
Scope the audit with a grep for the spread, then filter to popovers. grep -rn '{\.\.\.builder}' src/ finds every asChild consumer; in one mid-size app this was 5 components, 4 of them Popover.Root (all broken) and 1 Tooltip.Root (fine, leave it). The tooltip distinction matters — do not blanket-patch every builder spread.
Detection recipe (works from any browser-automation tool):
// load the page, let it hydrate, touch nothing
await new Promise(r => setTimeout(r, 1500));
[...document.querySelectorAll('[data-melt-popover-trigger]')]
.map(b => b.getAttribute('aria-expanded'));
// any "true" here, with no [data-popover-content] in the DOM, is the bugPair it with curl | grep aria-expanded on the same URL: SSR says false, hydrated DOM says true. That split is the signature and rules out a server-rendering mistake.
Generalisation: for any headless-UI library exposing a spread-the-attributes escape hatch, the spread is a snapshot whose reactivity you do not control. If a spread supplies an attribute that encodes state (as opposed to identity or static role), verify it actually changes at runtime before trusting it — in ARIA and in test selectors alike.