rustdoc: Don't override system keyboard shortcuts for search results tab-switcher

[camelid]

Once #79862 is merged, rustdoc will be overriding the macOS system keyboard
shortcuts Ctrl-↑ and Ctrl-↓ (Control–Up Arrow and Control–Down Arrow).

Personally, I don't use these shortcuts, but I imagine others do. We should find
different key combinations that won't override system shortcuts.

See the discussion around #79862 (comment).

cc @GuillaumeGomez @Manishearth

[Manishearth]

Not a fan of overriding system shortcuts, but I do think this is less pressing than the tab issue. Wondering what suggestions people have.

[GuillaumeGomez]

Wouldn't replace ctrl with cmd on mac be enough? It's generally what's done for most shortcuts. I just need a confirmation before making the fix.

[Manishearth]

I believe cmd-up/down is also a system shortcut? If it's not that would work.

[GuillaumeGomez]

To be checked then! I'll try to do that this evening or tomorrow.

[camelid]

Command–Up Arrow and Command–Down Arrow are used for scrolling to the top and bottom of the page in many browsers, including Safari and Firefox (and I assume Google Chrome). I don't think we should override that if we're looking to be as accessible as possible.

Unfortunately, many of the keyboard shortcut options are already taken :/

[GuillaumeGomez]

Arf. :-/

[jsha]

What about using keys without modifiers? E.g. t to cycle through the tabs, or <- and ->. This would mean you'd need to hit down or tab to take focus out of the search box, but I think that's an okay tradeoff.

[GuillaumeGomez]

I'd personnally prefer that those events are only handled when we have the focus on the search input.

[Manishearth]

I think using letter keys for navigation when you're in a search view but outside the search box makes sense.

[GuillaumeGomez]

That could work. I don't know how many of our users have their own letter keys bound to something, not sure if that would be a problem?

[Manishearth]

It's very rare.