fix(Calendar,DropdownMenu,NavigationMenu): stop props leaking into the DOM as attributes

[IgorShevchik]

Linked issue

Closes #477

Type of change

• Documentation (updates to the documentation or readme)
• Bug fix (a non-breaking change that fixes an issue)
• Enhancement (improving an existing functionality)
• New feature (a non-breaking change that adds functionality)
• Chore (updates to the build process or auxiliary tools and libraries)
• Revert (undoing a merged change — retitle this PR revert(Scope): ...)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

Three components were putting a prop into the DOM as a fall-through attribute. #477 named one of them; review found the second, and a sweep of the corpus found the third.

Each forwards its props to a reka root through useForwardProps minus a hand-maintained exclusion list, and each list was missing an entry.

where	attribute	whose bug
Calendar	nextmonth nextyear prevmonth prevyear, all ="[object Object]"	upstream has it too
DropdownMenuContent	arrow="true", or ="[object Object]" for the object form	ours — a porting slip
NavigationMenu (test only)	arrow="true" on <nav>	upstream's test, inherited

Calendar — #477

Four button-config props were missing from omittedProps, so Vue rendered each as junk on the picker root:

nextmonth="[object Object]"   nextyear="[object Object]"
prevmonth="[object Object]"   prevyear="[object Object]"

viewControl was already in the list — the tell that the class of bug was known and one of five was covered. The other four are declared identically, as Omit<ButtonProps, LinkPropsKeys>.

Nothing else moved: four changed lines per snapshot file, each dropping only the leaked attribute; [object Object] count 4 → 0.

Worth checking that the existing cases were not vacuous, because before this change with nextYear and its three siblings differed from a plain calendar partly because of the leaked attribute. They did not collapse — ui-btn-lg appears once in each of the four and zero times in the plain calendar, so { size: 'lg' } genuinely reaches its button.

Upstream has the identical defect — same four props, same list without them (only ui vs b24ui differs), same four attributes in its own committed snapshots. Fixing it costs no divergence: that line already differs from upstream, so it is a merge point on every sync either way.

DropdownMenuContent — found in review

arrow is ours, not reka's. Nothing in the DropdownMenuContent → MenuContentProps → PopperContentProps chain declares it — only arrowPadding and hideShiftedArrow. Upstream keeps its arrow in DropdownMenu.vue; we moved it down into DropdownMenuContent so submenus could carry one, and never updated the reactiveOmit list. So it reached the content root as an attribute. The arrow element reads props.arrow directly, so omitting it forwards nothing away.

Only the boolean form was in the corpus, because no render case passed an object. with arrow object adds one, and it pins the other branch of arrowProps: width="12" height="8" against the 20 / 10 default.

The other six components declaring arrow build their forwarded props with reactivePick — a whitelist, safe by construction. ContextMenuContent uses reactiveOmit but has no arrow.

NavigationMenu — a vacuous case, removed

Inherited from upstream, whose NavigationMenu does have an arrow prop and a NavigationMenuIndicator. We did not port either (the @memo on the props interface lists arrow among the things to remove), but the test case came across anyway, still passing arrow: true. Vue put the undeclared prop on <nav>.

That stray attribute was the only thing the case asserted. Measured rather than assumed: strip it and the #454 collision guard immediately reports the snapshot as byte-identical to both with modelValue and with defaultValue. Removed, with a comment in its place so the next sync does not bring it back.

The guard, and what it cannot see

The props all worked, every component rendered correctly, and the only symptom was junk in the markup — which the snapshots dutifully recorded as expected output, for as long as the files have existed.

New test/utils/stringified-props.spec.ts scans the whole corpus for ="[object Object]", built in the shape of the collision guard beside it and reusing its traversal so the two cannot disagree about what the corpus is. It asserts an empty list, not a baseline. Verified by restoring each leak: it goes red in both projects and names the file and the attribute.

Its blind spot is stated in the file, because it is not theoretical. A leak with a scalar value — arrow="true" — is indistinguishable from an intentional attribute by any text pattern. Both arrow leaks were in the corpus in exactly that form when the guard was written, and it saw neither; they were found by reading the components. A green run here means no object-valued leak, not no leak.

Correction to this PR's earlier description

It claimed, as a measured fact, that Calendar was the only site of this class, and rejected the issue's suggested general fix on that basis. That was wrong — there were three.

The conclusion survives the correction, for a different reason: of the components that forward props to a reka root, only these use a blacklist; the rest use reactivePick, which cannot leak an undeclared prop. Deriving the exclusion list automatically would still be machinery, but the honest argument is "two blacklists left", not "one site".

Honest note on value

#477 rates itself P3 and that is right: the props work, users see nothing, the fix is cosmetic in the DOM. What it buys is a few bytes less nonsense per server-rendered component, a snapshot corpus that no longer certifies a defect as correct output, one genuinely vacuous test case gone, and a guard that turns half of this bug class from invisible into a failing test.

Checks

• pnpm lint, pnpm typecheck green
• indistinguishable-snapshots guard green — no new collision, and the removed NavigationMenu case is not silently rejoining an existing one
• stringified-props guard verified red under a restored leak, in both projects

Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

🤖 Generated with Claude Code

https://claude.ai/code/session_012MsMuj8Fic9tjWVjyEyrxc

---

Generated by Claude Code