Search shortcut "/" is unreachable on Firefix and on keyboard layouts where "/" requires Shift (AZERTY, QWERTZ, etc.)

Problem

Same bug, two different manifestations:

Can't trigger '/' on AZERTY

The / search shortcut can't be triggered on any keyboard layout where / is a shifted character. On French AZERTY, for example, / is Shift + the : key. The moment you press it, e.shiftKey is true, and the global key handler in searcher.js returns on its guard clause before it ever checks for /:

function globalKeyHandler(e) {
    if (e.altKey ||
        e.ctrlKey ||
        e.metaKey ||
        e.shiftKey ||            // returns here on AZERTY '/'
        ...
    ) {
        return;
    }
    ...
    } else if (!hasFocus() && (e.key === 's' || e.key === '/')) {  // never reached

So the search box never opens.

This hits AZERTY, QWERTZ, and any other layout where / sits behind Shift, which is a large share of non-US users.

'/' Conflicts with default Firefox shortcuts

Because the handler returns without calling preventDefault(), the keystroke falls through to the browser. In Chrome nothing happens (Chrome has no page-level / binding).

In Firefox, / is bound to Quick Find, so Firefox's own find bar opens instead of the doc search. Same root cause, two different symptoms.

Reproduction

1. Set your OS keyboard layout to French (AZERTY), or any layout where / needs Shift.
2. Open any mdBook site and press /.
3. Chrome: nothing opens. Firefox: the browser's Quick Find bar opens.

s still works on these layouts, since it's an unshifted key, which confirms the shift-guard is the cause.

Proposed Solution

Suggested fix

Let the / case run even when Shift is held, since on many layouts Shift is exactly how you type /. One approach is to check the search keys before the modifier bailout, and preventDefault() on match so Firefox stops stealing the keystroke:

if (!hasFocus() && !e.ctrlKey && !e.altKey && !e.metaKey &&
    (e.key === 's' || e.key === '/')) {
    e.preventDefault();
    showSearch(true);
    window.scrollTo(0, 0);
    searchbar.select();
    return;
}

(Keying off e.key rather than a keyCode already handles the layout mapping; the only real blocker is the blanket shiftKey return.)

Notes

Alongside the fix above, it'd be worth adding Ctrl/Cmd+K as a second binding.

It's what users now expect from Docusaurus, VitePress, and most modern doc sites, and K isn't shifted on common layouts, so it sidesteps this whole class of problem.

(will open a suggestion about this ! )