Arrow keys do not work on iPad slim folio case in editor

[geraldthedev]

Describe the bug
The normal function of using arrow keys to navigate the text in the editor does not work. The cursor does not move at all. Normal functions as tabbing works.

To Reproduce
Connect to iPad to Slim folio case and attempt to use cursor in the editor. No other steps needed.

Expected behavior
The arrow keys should navigate through the editor the same as it would a normal text editor.

[geraldthedev]

Edit: the folio that I am directly working with is Logitech - Slim Folio Keyboard Folio Case for Apple® iPad

[geraldthedev]

Edit: Also, When attempting to use ctrl+c to stop a script from running in the terminal, it does not pickup the keystrokes, causing the user to have to close the page to stop the script from running.

[svenefftinge]

somewhat related: eclipse-theia/theia#3557

[geraldthedev]

Thank you for the link to the similar case. Good to know it has come up before. I hope that this is something that can be pushed soon. Awesome way to use github without leaving github.

[nmccready]

YAAASS this fix would be amazing. Gitpod is amazing and making it close to a reality of leaving my laptop upstairs for code! Thanks for everyone’s hard work.

[jankeromnes]

Thank you @hakeem1106 for reporting this issue! I also own an iPad and slim folio keyboard case, and I was able to reproduce this issue.

I agree with you and @nmccready that the experience on iPad can be much improved, and I'd like to look into it, because this would be super helpful for me too.

[jankeromnes]

Update: I think that a good place to fix this would be in the Monaco editor itself (which lives inside the vscode repository), for example in src/vs/base/browser/keyboardEvent.ts.

However, iPad bluetooth keyboard arrow keys are really weird to detect with JavaScript:

• When they're detected at all, they always seem to have event.keyCode === 0
• Using https://keycode.info/, I sometimes get events with event.key being something like UIKeyInputUpArrow, UIKeyInputLeftArrow, UIKeyInputRightArrow or UIKeyInputDownArrow, but if I focus on the text input, arrow key presses are no longer detected at all (as if the arrow keys just stop working)
• This StackOverflow reply looks particularly grim, saying that it's impossible to reliably detect iPad arrow keys, and that we should use other keys like WASD
• However, this other StackOverflow reply says it's detecting arrow keys on keyup/keydown

I'll see if I can somehow detect these from inside the Monaco editor.

[nmccready]

Also are any option to map keys anywhere? Example, Brydge Keyboard decided it would be lovely to not include the escape key.

Looks like CTRL + [ might work.
https://apple.stackexchange.com/questions/56866/how-do-i-type-the-escape-key-on-an-ipad-keyboard

[geraldthedev]

This looks like a step in the right direction. Full disclosure, I am still relatively new to some programming concepts which is a professional statement meaning, "I don't want to break anything" , but @jankeromnes seems to make a lot of sense. It would be nice to see if any other keyboards out there experience the same issue.

[jankeromnes]

Sadly, I can confirm that inside Monaco Editor, neither onKeyUp nor onKeyDown seem to get triggered by the bluetooth keyboard arrow keys. Every other key triggers onKeyDown just fine, e.g. any letters, numbers, Backspace, and even Escape which I trigger with Fn+(whatever that top left key is) because my French slim folio doesn't have a [ key.

EDIT: I am able to detect bluetooth keyboard arrow key presses from a web page when the focus is not inside the editor, with something like:

document.addEventListener('keydown', function (event) {
  alert('keydown: e.key = ' + event.key);
});

However once the editor is focused, the arrow keys no longer trigger any JS listener. (I was hoping to catch arrow keys from outside the editor and properly re-route them, but it seems that iPad's web view doesn't send any arrow key events when an input is focused).

[jankeromnes]

Horrible idea: Maybe we could watch the cursor position in Monaco's textarea with something like this:

document.querySelector('.inputarea').selectionStart

At least on desktop, the cursor position seems to change upon arrow key presses.

EDIT: iPad arrow keys do work on https://codemirror.net, and interestingly it seems like they're indeed polling the textarea for selection changes. Maybe that's not so crazy after all.

EDIT 2: Well, document.querySelector('.inputarea').selectionStart gives accurate values on desktop, but on iPad it seems to always be 0. Sigh.

[jankeromnes]

See also xtermjs/xterm.js#1101 (relevant, because Gitpod/Theia use xtermjs for the terminal).

[meysholdt]

There is a bugreport (just fixed!) in Webkit for this issue:
https://bugs.webkit.org/show_bug.cgi?id=149054

[jankeromnes]

Hooray! I honestly didn't expect this UIKit bug to be fixed before the web-editors community completely switched to a workaround like CodeMirror's cursor-position-polling.

Now let's hope that the fix makes it to iOS updates pretty soon. 🤞

[geraldthedev]

Can confirm, arrow keys now work with Logitech iPad folio keyboard case. 👌🏾

[meysholdt]

yehaaa! :-D

@hakeem1106, which version of iOS are you using?

[jankeromnes]

Wow, so soon? That's incredible 😛 I'm updating my iPad to see if I also get this fix.

EDIT: Sadly, after updating my iPad (to iOS 12.2), I'm still unable to use the arrow keys of my iPad slim folio case in Gitpod's code editor. 😞 I'll have to patiently await the next update and try again.

[geraldthedev]

I updated to 12.2 and it worked. I believe that I pressed the keyboard icon in the editor first. There is a slight lag but it is not that bad.

[jankeromnes]

I believe that I pressed the keyboard icon in the editor first. There is a slight lag but it is not that bad.

Wow, interesting, I hadn't noticed that icon before. When I tap it, it briefly flashes, but my arrow keys still won't work. Am I doing something wrong?

[geraldthedev]

It was working fine at one point. Now I cannot recreate it. I am not sure what is happening but I will keep testing.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.