34

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.

  • 1
    if(!$(e.currentTarget).hasClass('ignore-keyboard-shortcuts')) { dostuff(); } should be added to the shortcut keyboard script. and then add the ignore-shortcuts class to the relevant input fields... – Tschallacka Jan 22 '18 at 9:47
  • Should that actually be posted as an answer, even if it doesn't make it to an implemented fix for everyone with status-completed? – tripleee Jan 22 '18 at 10:23
4

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

  • Now, if only there was a way to patch the live code without having to replace the whole function (and open the patch up to becoming obsolete as other bug fixes are applied). – Martijn Pieters Jan 23 '18 at 13:55
  • @MartijnPieters: github.com/vyznev/soup/commit/… :) – Ilmari Karonen Jan 23 '18 at 14:13
  • No greasemonkey / tampermonkey support on mobile browsers on iOS :-( On my desktop system, I don't have much use for the mobile view. – Martijn Pieters Jan 23 '18 at 14:15
  • @MartijnPieters: That does suck. On Android, things have gotten a lot better now that Firefox for Android has proper extension support and can even run user scripts via Violentmonkey. But it seems iOS is still tightly locked down by Apple. – Ilmari Karonen Jan 23 '18 at 15:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .