Mobile: keyboard snaps to upper-case after each letter on multiplayer name entry (LOW nit) #108

Closed
opened 2026-06-22 21:10:18 +02:00 by bosun · 1 comment
Owner

Behavior (operator iPhone playtest 2026-06-22, deployed round-18)

On the multiplayer name entry screen, mobile keyboard auto-capitalizes after each entered letter — the keyboard layout snaps back to upper-case after every keystroke.

Severity: LOW (operator-named nit)

The name is uppercased server-side / for display anyway, so functionally the entered name ends up correct regardless. Issue is purely the mobile-keyboard-UX flicker.

Fix-direction (Shipwright lane)

HTML input attributes that control this on mobile:

  • autocapitalize="none" — disables auto-capitalize entirely (probably right call since field is uppercased anyway)
  • autocapitalize="characters" — sticks at upper-case (doesn't fix flicker; same as default)
  • inputmode="text" — also worth checking

The DOM input added for #66 multiplayer name entry is the target element.

Acceptance criteria

  1. Mobile keyboard does NOT snap to upper-case after each keystroke during name entry
  2. Functional behavior preserved (name still ends up correct, server-uppercased)
  3. Desktop behavior unaffected
  4. Verify on iPhone-13 emulation + real device if possible

Anchor

2026-06-22 operator iPhone playtest of round-18 deployed substrate. Operator explicitly framed as "only a nit — the name is uppercased after the entry anyway."

## Behavior (operator iPhone playtest 2026-06-22, deployed round-18) On the multiplayer name entry screen, mobile keyboard auto-capitalizes after each entered letter — the keyboard layout snaps back to upper-case after every keystroke. ## Severity: LOW (operator-named nit) The name is uppercased server-side / for display anyway, so functionally the entered name ends up correct regardless. Issue is purely the mobile-keyboard-UX flicker. ## Fix-direction (Shipwright lane) HTML input attributes that control this on mobile: - `autocapitalize="none"` — disables auto-capitalize entirely (probably right call since field is uppercased anyway) - `autocapitalize="characters"` — sticks at upper-case (doesn't fix flicker; same as default) - `inputmode="text"` — also worth checking The DOM input added for #66 multiplayer name entry is the target element. ## Acceptance criteria 1. Mobile keyboard does NOT snap to upper-case after each keystroke during name entry 2. Functional behavior preserved (name still ends up correct, server-uppercased) 3. Desktop behavior unaffected 4. Verify on iPhone-13 emulation + real device if possible ## Anchor 2026-06-22 operator iPhone playtest of round-18 deployed substrate. Operator explicitly framed as "only a nit — the name is uppercased after the entry anyway."
bosun closed this issue 2026-06-23 19:33:22 +02:00
Author
Owner

Substrate-of-record clarification (post-fix operator playtest 2026-06-24)

Operator clarification on the actual previous behavior:

"The letters were previously locked in upper case / caps, but I could disable the caps manually by pressing the shift key. I came to the idea to try this out because I saw that on Desktop the player name was not all-caps when entering, while on mobile it was always all-caps. So it was not even an issue before, depending on the definition."

Actual previous behavior: mobile defaulted to caps-LOCK (shift-overridable); desktop did not. Mobile-vs-desktop asymmetry on input-case. The original tracker description "upper-case flicker" was imprecise — actual symptom was caps-LOCK not flicker.

Why the fix still works: removing autocapitalize="characters" symmetrizes mobile to match desktop. Both now default to not-caps; shift-key still works on both. Behavior consistent across devices.

Substrate-discipline note: this is a worked-instance of filed-rootcause-is-hypothesis at substrate-of-record-layer. Original tracker characterization ("flicker") was hypothesis-form; empirical playtest revealed actual mechanism (caps-LOCK shift-overridable + cross-device asymmetry). Same intervention (remove autocapitalize) closes both interpretations because the substrate-mechanism is the same — the description-imprecision didn't affect fix correctness.

Substrate-of-record updated honest.

## Substrate-of-record clarification (post-fix operator playtest 2026-06-24) Operator clarification on the actual previous behavior: > "The letters were previously locked in upper case / caps, but I could disable the caps manually by pressing the shift key. I came to the idea to try this out because I saw that on Desktop the player name was not all-caps when entering, while on mobile it was always all-caps. So it was not even an issue before, depending on the definition." **Actual previous behavior**: mobile defaulted to caps-LOCK (shift-overridable); desktop did not. Mobile-vs-desktop asymmetry on input-case. The original tracker description "upper-case flicker" was imprecise — actual symptom was caps-LOCK not flicker. **Why the fix still works**: removing `autocapitalize="characters"` symmetrizes mobile to match desktop. Both now default to not-caps; shift-key still works on both. Behavior consistent across devices. **Substrate-discipline note**: this is a worked-instance of filed-rootcause-is-hypothesis at substrate-of-record-layer. Original tracker characterization ("flicker") was hypothesis-form; empirical playtest revealed actual mechanism (caps-LOCK shift-overridable + cross-device asymmetry). Same intervention (remove autocapitalize) closes both interpretations because the substrate-mechanism is the same — the description-imprecision didn't affect fix correctness. Substrate-of-record updated honest.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
frankenbit/cellblock#108
No description provided.