Keep keyboard up on iOS Safari when submitting commands

[dfabulich]

I made sure to test this behavior on old versions of IE. The existing master glkote sample-demo.html doesn't work in IE9 ("Object doesn't support property or method 'matchMedia'"); my PR works fine in IE10+ and Edge.

In addition to fixing an annoying usability bug, keeping the keyboard on screen is also a huge help for iOS Voiceover support. When keyboard focus is lost, Voiceover seems to randomly jump to the tab-selector button (the last control on the screen); keeping the keyboard up means VI users can just continue to type after typing their command (just like the rest of us)!

Fixes https://github.com/erkyrath/glkote/issues/48

[erkyrath]

Hm, I had not considered that matchMedia was causing backwards compatibility problems. I would prefer to make that conditional and get IE9 back.

But for this issue, if not delaying the focus works better on non-IE, I could put in a browser-sniff.

[dfabulich]

I have a hunch that delaying focus isn't required on IE9, either.

[dfabulich]

Also note that Microsoft has dropped support for IE9 on Windows 7; IE9 is now only supported on Windows Vista (and only until Vista runs out of support in April 2017).

If iplayif.com or IFDB has browser analytics, I bet you'll find that IE9 usage is well below whatever minimum threshold you have in mind.

[dfabulich]

Despite my better judgment, I fixed IE9 in PR #11. Sure enough, delaying focus isn't required on IE9, either. I bet it was required for IE8 or something, but IE8 is now totally unsupported by Microsoft and all right-thinking people. 😉

[dfabulich]

Ah, I fooled myself. It only keeps the keyboard up on short responses. If the game replies with enough text to trigger the "More" button, the keyboard goes away.

I think this PR is still an improvement over what's there, but I'll keep poking at it.

[curiousdannii]

IE 9 is down to 0.24% on iplayif.com. Overall matchMedia support is at 98.51% according to caniuse.com, but I think the unsupported % is mostly from unrecognised browsers. Known browsers that don't support it are less than 0.5% combined.

[dfabulich]

I'm giving up on keeping the keyboard up in the general case (at least for tonight). Here are my thoughts:

1. I still think this PR should merge anyway as-is. In master, the keyboard goes away after all responses; in my branch it goes away only after long responses, which is an improvement.

2. I experimented with recording frameel.scrollTop, focusing the element, then setting scrollTop back to what it was. http://stackoverflow.com/questions/4963053/focus-to-input-without-scrolling That seemed to work OK in desktop Chrome, but on iOS, the page partially scrolled down in a way that confused me.

3. I think the more common answer for iOS is to keep a 0x0 input box on the screen and handle all of its key events. http://4pcbr.com/topic/how_to_open_keyboard_on_ipad_with_js Or perhaps the "More" box could be marked contenteditable; similar idea. Nonetheless, this seems like way more surgery than I'm comfortable with.

[dfabulich]

I just remembered this old PR I wrote that apparently never merged. IE9 is wayyyy irrelevant today in 2021; I think this PR can/should merge as-is.

[erkyrath]

Guess what? I merged this one!