Text Korrektur - Mobil

Dieses Verhalten ist letztlich der Strategie der Keyboard-Entwickler unter Android zu verdanken, das Standard-Keyboard (inkl. diverser anderer von Drittanbietern) übermitteln beim "Tastendruck" (= Berührung der angezeigten Taste) nur nutzlose Daten, statt der tatsächlich gedrückten Taste. Dies ist allerdings nur der Fall, sollte die Auto-Korrektur aktiv sein, wird diese deaktiviert, werden wie gewohnt alle Informationen an JavaScript übergeben.

Die genauen Hintergründe habe ich im Beta-Forum [1] bereits erläutert:

Quote

This issue only happens when using an on-screen keyboard, using a mechanical keyboard does not trigger these issues because key events are processed just fine. The difference arises from how you would type certain special characters with on-screen keyboards, for example there is no dedicated key for ô (o with accent circumflex) but there is an o on the keyboard. You could tap and hold that key and after some brief delay you're offered with certain variants including the aforementioned character.

Things are a bit more complicated when it comes to the underlying event chain, in most cases each keystroke triggers a keydown followed by a keyup as soon as the user releases the key (or stop tapping it). Think about the example above, the keydown events needs to trigger as soon as the o is touched for the first time and the event would indicate that o has been pressed. This can be an issue, because keyup will actually report ô, which is a completely different key compared to what has been provided with keydown.

This discrepancy can be solved by supplying the special key code 229 which as per spec reports that there was a key event, but the input processor is still busy. In non-technical terms: there is something about to happen but it cannot be reliably determined what is actually going to happen. It looks like we could use 229 to solve this for these special keys, right?

Unfortunately the journey doesn't end here, because not every key has these additional character variants, for example the letter L (for the sake of this example, we simply assume there is none!). Tapping on L would yield a correct key code for keydown because the result of this tap is deterministic, it will always be the letter L without exceptions. This results in the letters L and O behaving differently on tap, simply because there is more logic hidden behind certain keys. On top of that there is auto-complete/auto-correct that can cause a change to the text input without any keystrokes taking place, making it even more obscure that content has changed.

The developers had the intention to unify the behavior by always setting 229, eventually forcing developers to use other ways to reliably detect changes to text inputs. While this isn't that much of a bad idea, this decision included special characters such as a backspace key, but since a developer is supposed to look at the result of the keystroke (and not the start of it), this isn't much of a big deal, right?

Well, no. Turns out that WYSIWYG editors are a big rabbit hole with a lot of different behaviors attached to certain actions, including but not limited to pasting, formatting and backspacing content. Browsers have their own ways to deal with backspaces and due to the lack of reliable specs, every browser is free to do whatever they want as long as backspace is deleting something. WYSIWYG editors sometimes want to control what exactly backspace does in order to enforce a consistent behavior across browsers, requiring them to intercept the backspace and cancel it completely if necessary.

Their decision to nullify the key codes provided with keydown makes it impossible to tell keystroke apart. There is absolutely no indication whatsoever what the user has done on the keyboard. Fair enough, they had good intentions when doing this change, but might have not thought of all consequences.

Display More

[1] https://beta.woltlab.com/forum…sue/?postID=4604#post4604