feat: add onKeyDown prop to ListBoxItem for custom keyboard handling

[hasegawa-101]

Closes #8732

Added onKeyDown prop to ListBoxItem to support custom keyboard event handling for individual items,
enabling features like deleting items with Delete/Backspace keys.

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub
  Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component).
• Looked at the Accessibility Practices for this feature - Aria
  Practices

📝 Test Instructions:

1. Run Storybook: yarn start
2. Navigate to "ListBox With Keyboard Delete" story
3. Focus on an item and press Delete or Backspace
4. Verify the item is removed and keyboard navigation still works

🧢 Your Project:

Open source contribution

[snowystinger]

Thanks for starting this, would you mind removing the docs and storybook in favour of a unit test? it can be added just after this describe block

react-spectrum/packages/react-aria-components/test/ListBox.test.js

Line 1842 in cf7c154

describe('press events', () => {

[hasegawa-101]

@snowystinger

Thanks for the review! I've addressed your feedback. Please take another look.

[nwidynski]

This should be using useKeyboard instead of native event listeners, otherwise we leak the event upwards.

[snowystinger]

Suggested change

	fireEvent.keyDown(options[0], {key: 'Delete'});
	await user.tab();
	await user.keyboard('ArrowDown');

[hasegawa-101]

Fixed! I've updated the test to use userEvent.keyboard() instead of fireEvent.keyDown() to prevent event leaking 🙏

[snowystinger]

question to team, do we want to use useKeyboard for this, it stops events by default so we MUST call continuePropagation here for the "Escape" key to clear the selection.

This is not ideal because it causes the event to continue by default instead through all other event handlers. See my thoughts on this in the description of #8775

[nwidynski]

This is not ideal because it causes the event to continue by default instead through all other event handlers.

Hm, maybe I’m remembering something wrong but isn't that only an issue because the handlers further up do not consistently useKeyboard themselves?

If that were the case propagation wouldnt flow upwards uncontrollably, since it would be stopped at every level if not explicitly continued.