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)
- 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])"))
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.)