Search/Hotkeys: handle / properly when inside INPUT tags

[humitos]

• do not show search modal when inside input HTML tags
• prevent keypress to propagate when captured by the hotkeys addons
• don't handle / when inside readthedocs-search HTML tag
• focus input field from the modal immediately after pressing /

Closes #165
Closes #160

[agjohnson]

I'm seeing the following runtime errors on the main run dev page (localhost:8000/) and in the test failures:

Cannot read properties of null (reading 'focus')
TypeError: Cannot read properties of null (reading 'focus')
    at SearchElement.updated (http://localhost:8000/readthedocs-addons.js:1726:15)
    at SearchElement._$didUpdate (http://localhost:8000/readthedocs-addons.js:25170:14)
    at SearchElement.performUpdate (http://localhost:8000/readthedocs-addons.js:25136:18)
    at SearchElement.scheduleUpdate (http://localhost:8000/readthedocs-addons.js:25055:21)
    at SearchElement.__enqueueUpdate (http://localhost:8000/readthedocs-addons.js:25028:29)

The search modal doesn't work on the Sphinx example either. / starts typing in the search input box.

It does come up on the Pelican example however, though the modal doesn't close with esc.

This is with an fresh browser environment (chromium), so no addons should be interfering.

[agjohnson]

The code here looks correct, but the problem with focus() is probably a matter of triggering a DOM event on a node that doesn't exist yet.

I don't think this change would negatively impact accessibility, but at some point we should probably return and be testing this with accessibility tooling more.

[humitos]

The search modal doesn't work on the Sphinx example either. / starts typing in the search input box.

This is because Sphinx captures the / key as well. We need to document how to disable it on Sphinx for users wanting to show our own search modal when using the hotkey addons. I think it's gonna be something like:

# docs/conf.py

html_theme_options = {
  "enable_search_shortcuts": False,
}

Reference: https://www.sphinx-doc.org/en/master/usage/theming.html#builtin-themes

I suppose we will have these types of hints/snippets for different doctools while we are finding this incompatibilities.

[humitos]

It does come up on the Pelican example however, though the modal doesn't close with esc.

IIRC, we haven't implemented Esc to close the modal yet. It's only on the modal's bottom as documentation, but it's not on the code 🙃 . Opened #172 to track this work.

[agjohnson]

I suppose we will have these types of hints/snippets for different doctools while we are finding this incompatibilities.

Yeah, I figure the same. Especially where we have both user and theme hotkey customizations to consider. These hurdles are some of the reasons I've been very hesitant to implement hotkey features on any of our product side. I think there is plenty of room to use this pattern for testing purposes though, and wouldn't change our existing patterns. But I eventually see us implementing UI instead of hotkeys as the primary method for invoking these features, leaving keyboard access as a secondary or optional method.

[humitos]

leaving keyboard access as a secondary or optional method.

Yes, I suppose we will be making this opt-in while explaining the potential incompatibilities and linking to our documentation where we explain the known-issues and how to disable conflicting keys.

I think it's impossible to make hotkeys to always work fine on "any HTML the user can create" 🙃 . In any case, I'm happy we have this addon at this moment and we can keep experimenting with it to discover these things.

I may change my mind in the future if I find a way to "disable all the hotkeys for any other JS and only listen to mines", but I think that's not possible anyways 😄