I can't use my number pad for 2FA codes

Original Article ↗ Hacker News Discussion ↗

Web developers increasingly intercept keyboard and paste events in login and 2FA forms, breaking basic behaviors like using a numpad, Home/End keys, autofill, or password managers. Commenters argue that custom JavaScript “enhancements” such as split OTP inputs, blocked paste, and hijacked shortcuts harm accessibility, security, and usability compared with plain HTML controls the browser already provides. Many call for browsers to act more as the user’s agent again and for teams to resist unnecessary reimplementation of native form behavior, especially when driven by misguided security or design requirements.

Keyboard and input event hijacking

  • Many commenters complain about sites hijacking key events (Home/End, arrow keys, PageUp/Down, Cmd/Ctrl+F, right-click) for custom behavior.
  • This breaks expected OS/browser features: text navigation, scrolling, suggestions, opening in new tabs, context menus, and accessibility.
  • Using KeyboardEvent.code for validation is criticized as wrong; better to react to text input (input events) instead of raw key events.

Paste and clipboard restrictions

  • Strong frustration at sites that block pasting into password/OTP fields or require a manual keystroke before submission.
  • This undermines password managers and secure long passwords, especially when sites simultaneously demand “strong” credentials.
  • Some note that browsers exposing paste vs typing lets sites do this at all; others counter there are legitimate reasons to intercept paste (e.g., richer clipboard formats).
  • Workarounds include “force paste” extensions, password manager auto-typing, drag-and-drop of passwords, and devtools hacks.

OTP / 2FA input design

  • Multi-box OTP inputs (6 separate fields) are widely disliked:
    • Often break paste (only first digit entered).
    • Mishandle fast typing, navigation (Tab/Shift+Tab, arrows), and correction/backspace.
    • Sometimes require physically typing each digit despite being short-lived, single-use codes.
  • Many argue a single plain text input is superior; any extra behavior (e.g., parsing pasted codes) should be additive, not restrictive.

Standard controls vs custom JS UI

  • Repeated theme: don’t “reimplement the browser.”
  • Native HTML inputs and OS widgets bring accessibility, performance, and correct behavior “for free.”
  • Custom controls and rich JS input logic frequently recreate bugs, ignore autofill, IMEs, mobile keyboards, and screen readers.

Browser role and JavaScript power

  • Several lament that browsers act less as “user agents” and more as canvases for sites, giving developers too much power over basic interaction.
  • Some argue JavaScript violates the “rule of least power” for UI; others respond that powerful client-side behavior was necessary as HTML lagged.

Testing, platforms, and ergonomics

  • Perception that many broken behaviors arise from only testing on macOS with specific shortcuts and hardware.
  • Calls to test on other OSes, older/low-end devices, different browsers, JS-disabled setups, and slow connections.
  • A side discussion debates alternative numpad-style layouts on letter keys; opinions differ on whether this is more ergonomic or just confusing.