Customization options for keyboard shortcuts in Startlight Search Modal to avoid conflicts with Embedded Code Playgrounds

[tinchox5]

What version of starlight are you using?

0.11.0

What is your idea?

Issue Description
I'm currently using Startlight for hosting a documentation site for a CSS library (which is not public yet). Within this site, I've implemented an Astro code playground component that enables visitors to interact with and edit example code directly.

Problem Encountered:
The issue arises when using certain keyboard shortcuts within this code playground. Specifically, pressing the '/' key, which is intended for writing code (such as </div>), unexpectedly triggers the Startlight search modal to open. This behavior disrupts the coding experience in the playground.

Suggested Enhancement
To address this, I propose introducing additional customization options for the Startlight search modal's keyboard shortcuts. Specifically:

Customizable Keyboard Shortcut for Search Modal:

Allow developers to redefine the default keybinding for activating the search modal. This would enable developers to choose a shortcut that doesn't conflict with other functionalities on their site.

1. Option to Disable Keyboard Shortcut:
   Provide an option to completely disable the keyboard shortcut for opening the search modal. This can be particularly useful for pages where keyboard interactions are heavily utilized for other purposes, such as code editors or playgrounds.

2. Current Workaround and Concerns
   As a temporary workaround, I have manually removed the event listener from the search component's source code. However, this approach is not ideal, as it involves directly altering the library code, which might lead to maintenance issues and is generally not a recommended practice.

Why is this feature necessary?

I believe this would be a valuable addition to Startlight, especially for documentation sites with embedded code editors or similar interactive components.

Do you have examples of this feature in other projects?

No response

Participation

• I am willing to submit a pull request for this feature.

[HiDeoo]

Thanks for your feedback.

I am wondering if before introducing new options, we should try to see if this is something that could be fixed in the current implementation.

At the moment, the code is checking if the active element is an input before opening the modal using /:

https://github.com/withastro/starlight/blob/main/packages/starlight/components/Search.astro#L91-L93

I just submitted a new PR to slightly improve this behavior as this was ignoring elements with contents that are editable.

Would you be able to describe how your code playground is structured and which element is focused when the / shortcut is pressed and triggers the modal in a way that is not expected?

[tinchox5]

@HiDeoo thank you very much for your quick response and suggested patch. I tried it an now it's working perfectly.

[HiDeoo]

Oh, that was the missing case, even better, thanks for checking it out 🙌

[Treuweille]

Hi I am monjo I want to do everything for good travel to go future fonction !

[delucis]

Fixed by #1065 which will be available in our next release: v0.13

Thanks for flagging this as an issue @tinchox5 and thanks for the quick fix @HiDeoo! ✨

[tinchox5]

@HiDeoo , @delucis thank you! Awesone product and community !!