[w3c/editing] Inconsistent `KeyboardEvent.shiftKey` behavior for virtual keyboard autocapitalization (Issue #542)

michael created an issue (w3c/editing#542)

Currently virtual keyboards have inconsistent behavior for `event.shiftKey`.

In an editor you typically want to handle `Shift+Enter` as a distinct command, like inserting a hard break instead of a paragraph.

On physical keyboards the behavior is clear and defined: User holds Shift while pressing Enter, and the `keydown` event has `event.shiftKey === true`.

On mobile virtual keyboards this becomes ambiguous though: 

- iOS Safari sets `event.shiftKey === true` for Enter both when the user explicitly tapped Shift and when autocapitalization would make the next character uppercase
- Android does not set these modifier keys for virtual keyboard input at all
- This means editors cannot reliably tell whether `Shift+Enter` was intentional, or the shift state is there because of autocaptizalization

Desired behavior would be:

- Explicit user Shift press should be reflected in `KeyboardEvent.shiftKey`.
- Implicit autocapitalization should affect only the inserted character, like insert `"A"` instead of `"a"`, without setting `event.shiftKey === true` on unrelated key events such as Enter.

The goal is that editors can safely interpret modifier shortcuts when they reflect user intent, instead of having false positives caused by virtual keyboard autocapitalization.

Related discussion: https://discuss.prosemirror.net/t/shift-enter-in-mobile-phones/4903/6

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/542
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/542@github.com>