feat(Popover): dev-mode warning when display utility overrides native popover hide

[sridhar-3009]

Summary

Closes #448.

When a layout utility class (flex, grid, inline-flex, etc.) is placed directly on <Popover.Content>, it can conflict with the UA [popover]:not(:popover-open) { display: none } rule that hides a closed popover. This was the root cause of #419; the CSS-layer fix landed in #419/398, but there was no developer feedback to prevent the pattern from reappearing.

What this PR adds

PopoverContent.vue — onMounted guard (tree-shaken to nothing in production via typeof __DEV__ !== 'undefined' && __DEV__):

1. Clones the content element and removes its [popover] attribute, so neither the UA closed-state rule nor the component's own [popover]:not(:popover-open){display:none!important} override applies to the clone.
2. Appends the clone off-screen and reads getComputedStyle(clone).display.
3. If the computed value is anything other than none or block (i.e. the default div display), a useLogger('PopoverContent').warn(...) is emitted, naming the detected value and pointing to the fix: wrap layout classes in a child element.
4. Removes the clone immediately — zero DOM leak.

The guard is also SSR-safe via the IN_BROWSER early return.

Tests

Two new cases in index.test.ts under content > dev warning:

• warns when getComputedStyle returns 'flex' for the off-screen probe (simulated via vi.spyOn).
• does not warn when getComputedStyle returns the happy-dom default '' (no utility class present).

Before / After

<!-- triggers warning in dev -->
<Popover.Content class="flex flex-col gap-4">…</Popover.Content>

<!-- correct: layout on the inner wrapper -->
<Popover.Content>
  <div class="flex flex-col gap-4">…</div>
</Popover.Content>

[github-actions]

✅ Changeset found — this change will be included in the next release. Thanks!

[pkg-pr-new]

Open in StackBlitz

commit: 3149bae

[johnleider]

I wonder if this would be better served as a warning to the user. It's definitely a good conversation to have regarding when/where/why we would add behavior like this to a component. @J-Sek @AndreyYolkin @Haviles04

[J-Sek]

code probes computed style, not class, so "A display utility class ..." is not precise and might be misleading.

[J-Sek]

It is hard to take a stance - scenario suggests, the menu is being rendered, so why not just assume it is likely to be visible, making console warning redundant. It only potentially serves people that ship straight to Prod without QA and skipping manual verification locally. That's also a bit weak.. they probably skip opening browser and running affected web page altogether, so console logs won't change much.

I would prefer ESLint rule, but can't help by notice testing against computed style covers more ground. The only issue is potential performance overhead.

Vue DevTools already hit hard, so maybe it does not matter, but we could make sure by having 20x500 table rows here each table has some kind of dropdown for context menu or value selector.

We can also make it lighter by setting empty inner body probe.innerHTML = ''

My vote would be to skip this case. Simply rely on class making the popover visible.

[J-Sek]

I don't think v0 ships these styles + if UA makes the display hidden, then it wins over class and there is no issue to warn about - i.e. cloning is adding friction instead of solving real problem.

[Haviles04]

I agree with Jacek that an ESLINT rule is preferable, this feels heavy just to say "hey maybe don't do that"