Originally filed as b/63409339. Here's an excerpt of what I wrote there:

In this case, YT tries to enforce upper-case 8-letter English alphabets and adds a hyphen in between (e.g. AAAA-AAAA).
I suspect that YT webpage clears the text or cancels key events whenever the key event's keycode does not fall under [a-zA-Z]* type.

On Android, keyboard apps tend to keep users one touch away from suggestions and replacements, so they use text composition more heavily than their desktop counterparts, even for English alphabets. And on Android platform, keycode is not specified from the keyboard app on text composition by design. So Chrome on Android provides a deadkey, which is still compliant with the web standards. The keycode approach is clearly WRONG here.

Then what should be the RIGHT solution for this?

Unfortunately, there is no easy way for an editor to "oppose" IME commands beyond a simple key event. If we extend our thought beyond the de facto US keyboard layout, you can see the same issue on desktop. For example, Japanese websites want to replace full-width numbers with half-width numbers as you type, so they want to replace the characters at keyup events. (https://crbug.com/692387)

If the editor tries to change the text, the keyboard app usually do not respond well to the changed text and behaves weirdly by composing the same text at the end.

One workaround here would be to restart (reset) input method whenever we detect a JS-driven change to the text.

If we go in the direction of the detect-and-restart mechanism, this should be the full workflow:
1) User types 'a'.
2) JS gets 'input' event and sees 'a'.
3) JS replaces 'a' with 'A'.
4) Chrome's renderer process holds off handling of IME operation.
5) Chrome restarts IME input.
6) Chrome's renderer process resumes handling of IME operation.
7) User types '1'.
8) JS gets compositionupdate('1') and cancels the event.
9) Chrome does 4)-6).

Would it make sense?

Note that restart is not an ideal solution here. We found that on Android this causes some issues:
1) It's an expensive operation, and reset causes some delay and context reset. (see b/25311587 and  crbug.com/548501 )
2) If you type something while input is being restarted (through editor-driven call to imm.restartInput()), then you lose what you type. This is observed on Samsung keyboard and Google keyboard. (see crbug.com/740140)
3) Similar to 2), but if you hold down a key, and input gets restarted, then the key event is no longer effective until you release the key. This is observed on Samsung keyboard and Google keyboard.
4) Specific to Chrome, but browser and renderer are separate processes, so we have to ignore more IME operations until round-trip to browser process finishes.