Describe the issue
On iOS, the InputState.keydown() method intercepts Enter (and Backspace/Delete) key events to work around a virtual keyboard state bug. The intercepted key is stored in this.pendingIOSKey and re-dispatched after 250ms via flushIOSKey().
The problem is that PendingKeys entries are plain objects with only { key, keyCode, inputType } — no modifier state. The assignment this.pendingIOSKey = pending || event always picks pending (the plain object) over event (the original KeyboardEvent), because pending is truthy whenever PendingKeys.find() matched.
In flushIOSKey(), the call to dispatchKey() checks key instanceof KeyboardEvent to decide whether to copy modifier properties (shiftKey, altKey, etc.). Since key is the plain object, not the original event, this check is always false, and the re-dispatched synthetic event has all modifiers set to their defaults (false).
This means Shift+Enter on an iPad hardware keyboard is re-dispatched as a plain Enter, with shiftKey: false. Any domEventHandlers or keymap bindings that check shiftKey (e.g. to distinguish "submit" from "insert newline") see the wrong value.
Browser and platform
iPad, latest, with hardware keyboard
Reproduction link
No response
Describe the issue
On iOS, the InputState.keydown() method intercepts Enter (and Backspace/Delete) key events to work around a virtual keyboard state bug. The intercepted key is stored in this.pendingIOSKey and re-dispatched after 250ms via flushIOSKey().
The problem is that PendingKeys entries are plain objects with only { key, keyCode, inputType } — no modifier state. The assignment this.pendingIOSKey = pending || event always picks pending (the plain object) over event (the original KeyboardEvent), because pending is truthy whenever PendingKeys.find() matched.
In flushIOSKey(), the call to dispatchKey() checks key instanceof KeyboardEvent to decide whether to copy modifier properties (shiftKey, altKey, etc.). Since key is the plain object, not the original event, this check is always false, and the re-dispatched synthetic event has all modifiers set to their defaults (false).
This means Shift+Enter on an iPad hardware keyboard is re-dispatched as a plain Enter, with shiftKey: false. Any domEventHandlers or keymap bindings that check shiftKey (e.g. to distinguish "submit" from "insert newline") see the wrong value.
Browser and platform
iPad, latest, with hardware keyboard
Reproduction link
No response