feat: NavigationMenu.Item - openOnHover prop

[huntabyte]

This PR introduces a new prop to NavigationMenu.Item, openOnHover, which defaults to true (behavior today), to enable users to prevent opening the item's NavigationMenu.Content on hover.

To provide more flexibility, we added it to the individual items instead of the NavigationMenu.Root.

When openOnHover={false}, the menu will no longer close when the pointer leaves the trigger/content and will instead expect a more explicit close event, such as pointer down outside, escape key down, or focus outside.

Closes #1222

[changeset-bot]

🦋 Changeset detected

Latest commit: a6581eb

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
bits-ui	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in Stackblitz

npm i https://pkg.pr.new/bits-ui@1223

commit: a6581eb

[github-actions]

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

Name	Status	Preview	Last Commit
bits-ui	✅ Ready (View Log)	Visit Preview	a6581eb

[AlexJMohr]

I think it solves my usecase, in combination with interactOutsideBehavior="ignore" escapeKeydownBehavior="ignore" on NavigationMenu.Content. Thanks!

[philippviereck]

using this pull request resolves a stubborn navigation-menu bug I face on touch devices where often the NavigationMenu.Items / Links that were tapped did not navigate at all and simply closed the navigation menu. I first suspected the issue was due to taps being interpreted as hovers rather than clicks, and later wondered if the paraglide adapter v1 (now replaced by v2) was to blame. So far I haven’t been able narrow it down or reproduce the issue anywhere but in my own project and only when deployed. 🫠

Regardless, the change introduced by this PR would be a welcome feature-especially for sites aimed at less-tech-savvy audiences, such as elderly.