Composition Helper seems broken (macOS Sierra)

[mofux]

Details

• Browser and browser version: Chrome 59
• OS version: MacOS Sierra 10.12.6
• xterm.js version: 2.9.0

Steps to reproduce

Open the xterm.js demo page, keep holding down the o key. The composition helper should pop up and show a list of characters to select - instead nothing is shown. Still, using the arrow keys seems to toggle through the (invisible) composition popup and displays the selected character at the cursor position. When confirming the selection with enter, nothing happens. The same behaviour happens in Firefox, although sometimes the character is inserted on enter.

Troubleshooting

Part of the problem is that the textarea is rendered off-screen (left: -9999em) initially.
We wait for the compositionstart event, then we move the textarea to the cursor position - but as it seems, the compositionstart event is fired after MacOS draws the composition popup and only once a character is selected in the popup, causing it to render somewhere offscreen.

@Tyriar @parisk do you experience the same problem? Does this also happen on other platforms?

[Tyriar]

I've suspected it's been broken for a while, haven't tested though. Things break when browsers update unfortunately 🙁

[mofux]

Mmmmh... I actually wanted to try myself on a PR for #265 - which made me come across this issue. Terminal.app does not show the composition dialog at all, probably in favour of printing sequential characters, and I wonder if we shouldn't do the same. However, I'm concerned breaking the IME input. Unfortunately I don't know how to test IME composition.

@Tyriar Do you know of a way to test IME input on the Mac, like inserting some Chinese characters?

[Tyriar]

It's a bit of an involved process, particularly if you aren't familiar with the input methods. I typically test Chinese, Japanese and Korean as they all have different input styles, and then you need to test them all in various browsers. To add them you need to add the input method to the OS, I would need to google how to do it on Mac.

I wouldn't expect #265 to be related to this though, I thought that one was to do with moving over to the input even for input tracking?

[mofux]

I also thought so but the input event only fires if the input value of the textbox has changed. That means we can't catch arrow keys or key combinations or F keys and so on with it. Additionally, at least on my Mac, holding down a key does not repeat characters in an input or textbox, it only print a single character, which means that the input event will only fire once. The only listener that fires multiple times while the key is down seems to be the keypress event.

[Tyriar]

I believe this is fixed

[mofux]

Yes. We ignore this kind of composition and repeat the original character instead - which is what Terminal.app is doing.