Follow-up to #35374
Before #19276, the ? shortcut was inaccessible to most Latin-script non-English layouts, and the S/U shortcuts inaccessible to non-Latin-script layouts.
After #19276, both shortcuts were made accessible to all layouts, but for non-English and/or non-QWERTY layouts the glyphs on screen did not always match the physical keys.
After #35374, the glyphs are correct for Latin-script layouts, but for non-Latin-script layouts the shortcuts are once again inaccessible.
Only using KeyboardEvent.key, which represents the character typed by the user, is problematic because it means that non-Latin script keyboard layouts can't use some keyboard shortcuts.
The way I've solved this is: if key does not match any defined shortcuts, also consider KeyboardEvent.code, which represents the physical key pressed in relation to a US QWERTY keyboard layout. Now the shortcuts work if you type the characters s/u/? regardless of whether you're using QWERTY, Dvorak, Colemak, etc., (and regardless of caps lock modifier), but also if you press the keys that physically correspond to S/U/Shift+/ on a US QWERTY keyboard. (There isn't really any better way of handling this that would make everyone happy due to the state of browser APIs.)
In addition, keyboard shortcuts are now no longer triggered when the user is composing text using an IME, which often use arrow keys, escape and enter. So if you're using e.g. a Japanese IME, you can type "PASU" and advance through "ぱす" > "パス" > "pass"> "path" using the arrow keys and hit enter to accept or escape to abort without ending/aborting the search.
Follow-up to #35374
Before [#19276](https://github.com/ziglang/zig/pull/19276), the `?` shortcut was inaccessible to most Latin-script non-English layouts, and the `S`/`U` shortcuts inaccessible to non-Latin-script layouts.
After [#19276](https://github.com/ziglang/zig/pull/19276), both shortcuts were made accessible to all layouts, but for non-English and/or non-QWERTY layouts the glyphs on screen did not always match the physical keys.
After #35374, the glyphs are correct for Latin-script layouts, but for non-Latin-script layouts the shortcuts are once again inaccessible.
Only using `KeyboardEvent.key`, which represents the character typed by the user, is problematic because it means that non-Latin script keyboard layouts can't use some keyboard shortcuts.
The way I've solved this is: if `key` does not match any defined shortcuts, also consider `KeyboardEvent.code`, which represents the physical key pressed in relation to a US QWERTY keyboard layout. Now the shortcuts work if you type the characters `s`/`u`/`?` regardless of whether you're using QWERTY, Dvorak, Colemak, etc., (and regardless of caps lock modifier), but also if you press the keys that physically correspond to `S`/`U`/`Shift`+`/` on a US QWERTY keyboard. (There isn't really any better way of handling this that would make everyone happy due to the state of browser APIs.)
In addition, keyboard shortcuts are now no longer triggered when the user is composing text using an IME, which often use arrow keys, escape and enter. So if you're using e.g. a Japanese IME, you can type "PASU" and advance through "ぱす" > "パス" > "pass"> "path" using the arrow keys and hit enter to accept or escape to abort without ending/aborting the search.