Mobile search made impossible with keyboard shortcuts enabled [closed]

Question

I have keyboard shortcuts enabled in my profile. They are great, so I can't imagine answering questions and navigating on SE without them now.

However, I don't expect them to be active when using the mobile web interface. But if you try to use the question search box on the mobile web interface, then you suddenly find the achievements box opening, or the inbox, or the keyboard shortcuts help overlay appearing. Actually entering an h or i or r into the search box is impossible however.

Try it yourself:

• enable keyboard shortcuts in preferences
• open the mobile web UI (there is a link at the bottom right)
• select the questions tab
• select the magnifying glass
• try and type some search terms

Please don't even load keyboard shortcuts on the mobile web UI. The keyboard isn't even available most of the time. Or at least disable them for the search box.

Answer 1

It seems that the real bug is that the mobile UI is using <input type=search> for the search box, but the keyboard shortcuts script doesn't recognize that type as a text entry box. The only reason the same bug doesn't occur on the desktop version of the site is because the desktop UI is still using plain old <input type=text> for the search box. Indeed, if you use the browser DOM inspector to change the search box type to text in the mobile view, it starts working normally.

Here's a quick one-line patch against keyboard-shortcuts.en.js to fix this:

--- keyboard-shortcuts.en.js    2018-01-23 15:16:44.924622877 +0200
+++ keyboard-shortcuts.en.fixed.js  2018-01-23 15:29:47.192463128 +0200
@@ -797,7 +797,7 @@
                 if (evt.ctrlKey || evt.altKey || evt.metaKey)
                     return handleResults.notHandled;

-                if ($(evt.target).is("textarea, input[type='text'], input[type='url'], input[type='email'], input[type='password'], input:not([type])")) // default type is text, so if no type is set, it's a textbox as well
+                if ($(evt.target).is("textarea, input:not([type=checkbox],[type=radio],[type=submit],[type=button],[type=image],[type=reset])"))
                     return handleResults.notHandled;

                 var action = currentLevel.actions[keyDescription(evt.which)],

Note that the change above also makes the code slightly more future-proof by assuming that any unrecognized input element types probably also take text input, and so should not have keyboard shortcuts enabled when focused. This seems like the safe bet, both because most of the new HTML5 input types do take text input, at least optionally, and also because the consequences of disabling keyboard shortcuts when a non-text input has focus are a lot less severe that not disabling them when the user is trying to enter text.

In fact, the patched code disables keyboard shortcuts when the focus in on any input element that isn't a checkbox, radio button or one of the several kinds of push button inputs. I'm not sure whether it would be OK to leave the shortcuts enabled for purely numerical input elements like <input type=number> or <input type=range>, but since I wasn't sure, I didn't. In any case it would be a trivial change to make, if deemed safe.

---

Ps. As of v1.50, just released today, my SOUP user script now contains a fix for this bug. It works by installing its own delegated jQuery event handler on $(document.body) (the SE handler is installed on $(document)) that captures any keypress events on elements matching the new selector in the patched code above and prevents them from reaching the SE event handler in the first place. (To actually use SOUP on mobile devices, you need a mobile browser that supports user scripts and/or WebExtensions, such as Firefox for Android. Alas, no such browsers seem to currently exist for iOS.)