Xterm.js: Support mobile platforms

[parisk]

Lately, I have been experimenting with coding with an iPad Pro with a Smart Keyboard on SourceLair.

The experience was buggy, but honestly it was much better than I expected.

One of the caveats (initially pointed out by @exsillium in a different PR) is that the arrows of the Smart Keyboard do not work at all on xterm.js.

It would be great if they did though 😄!

Initial discussion and PR with partial solution: https://github.com/sourcelair/xterm.js/pull/1065

---

Initial approach

At first we tried to fix this by detecting the keydown events of the Smart Keyboard and then handle them in xterm.

This did not work, as the only case where iOS fires consistently keyboard events on Smart Keyboard
arrow presses is the keydown event, when the focus is on document.body.

Potential solution

• Use the terminal's hidden textarea
• Let iOS handle the keyboard event natively
• Detect the keyboard movement via selection change

Proof of Concept: How Ace editor handles this

https://github.com/ajaxorg/ace/blob/eb2437badf4013893e15cb873057607c09cc95ae/lib/ace/keyboard/textinput_ios.js#L483-L526

[tbodt]

I'd propose simply not using a textarea and handling everything through keydown events. This is what hterm does IIRC.

[Tyriar]

@tbodt don't you need a textarea to get the keyboard to show on iOS/Android?

[tbodt]

@Tyriar oh, you're right. the keyboard doesn't show up on iOS with hterm.

[exsilium]

@parisk - Just noting here, that after #1065 & xterm.js v3.1.0 to have the hwkb arrows working, one must unfocus from the textarea to the div element for the keydown event to fire on iPad. As xterm.js refocuses to the textarea on every keyup event, I had to hackishly refocus on the <div> after each keypress.

self.element.addEventListener('keyup', function (ev) {
  self.element.focus();
});

https://github.com/exsilium/cloud9/pull/27/commits/84416fcf9bfe8c25c95cfc55a15704d56a98df7a

Would be good to get this support from the xterm.js natively so that the textarea refocus wouldn't always happen on keyup (or at least be a configurable option?). Cheers! 🍻

[parisk]

Yeah, it would be great if we could get this working but I am afraid it's going to get quirky.

I assigned this to myself and hopefully will put something up for the 3.3 release. Cheers 🍻

[Tyriar]

Improved layering should help with plugging in custom front ends if good mobile support needs a radically different frontend https://github.com/xtermjs/xterm.js/issues/1507

[Tyriar]

IMEs behave weird as called out in https://github.com/xtermjs/xterm.js/issues/1815

[Akarys42]

Adding blank lines at the bottom of the terminal would be quite useful #2672

[anatoly314]

@Akarys42 had the same issue as you, but I honestly think that it should be done by the user and keep xterm as generic as possible. Otherwise, it might become messy with a time.

[anatoly314]

When or more likely if, you will decide that time came to solve this issue, pay attention that the different keyboards on Android behave in a different way. For example SwiftKey, it looks that on every type it just pastes the symbol to the current input field. And how do you delete? It removes everything from the current input, and paste a new string with the removed last char.