Keep shortcuts working after a checkbox is clicked

Ticking "select all" disabled every keyboard shortcut until the reader clicked
somewhere else (#260). Same for the per-message checkboxes, so selecting a few
messages and pressing e to archive them did nothing.

The guard that stops "a" archiving while you are typing into the search box
tested `tagName === "INPUT"`. That is also true of a checkbox, and a checkbox
keeps focus after a click -- correctly, since space should toggle it again.
So the guard was suppressing shortcuts for an element that swallows no
keystroke: space is handled by the browser before this listener runs.

The question is not "is this an input" but "does this input take text", which
is what isTextEntry now asks. A <select> counts, in the sense that matters
here: typing a letter jumps to the option starting with it, and a shortcut
would steal that.

Thirteen checkboxes and seven file inputs across the app were affected, not
just the one reported.

The regression test was checked against the old guard first: it fails there
and passes here, which is the only thing that makes it a regression test.

web/src/lib/keyboard.ts

@@ -54,9 +54,7 @@ class Keyboard {
     // Let modal dialogs and popovers handle their own keys (Escape, arrows, ...).
     if (document.querySelector(".dialog-backdrop, .popover")) return;
     const target = e.target as HTMLElement | null;
-    const inInput =
-      !!target &&
-      (target.tagName === "INPUT" || target.tagName === "TEXTAREA" || target.tagName === "SELECT" || target.isContentEditable);
+    const inInput = isTextEntry(target);
     const combo = comboOf(e);
     if (!combo) return;
 
@@ -102,6 +100,38 @@ class Keyboard {
   }
 }
 
+/**
+ * Is the focused element somewhere the reader is typing?
+ *
+ * This guard exists so that pressing "a" in the search box searches for "a"
+ * rather than archiving the message behind it. The test used to be
+ * `tagName === "INPUT"`, which is true of a checkbox — and a checkbox keeps
+ * focus after you click it, so ticking "select all" silently disabled every
+ * shortcut until the reader clicked somewhere else (#260). Nothing about a
+ * checkbox swallows a keystroke: space toggles it and the browser handles
+ * that before this listener ever runs.
+ *
+ * So the question is not "is this an input" but "does this input take text".
+ * A `<select>` does, in the sense that matters here: typing a letter jumps to
+ * the option beginning with it, which a shortcut would steal.
+ */
+const TEXT_ENTRY_TYPES = new Set([
+  "text", "search", "email", "url", "tel", "password", "number",
+  "date", "datetime-local", "month", "time", "week",
+]);
+
+export function isTextEntry(el: Element | null): boolean {
+  if (!el) return false;
+  const node = el as HTMLElement;
+  if (node.isContentEditable) return true;
+  const tag = node.tagName;
+  if (tag === "TEXTAREA" || tag === "SELECT") return true;
+  if (tag !== "INPUT") return false;
+  // An <input> with no type attribute is a text field.
+  const type = (node as HTMLInputElement).type?.toLowerCase() || "text";
+  return TEXT_ENTRY_TYPES.has(type);
+}
+
 const isMac = typeof navigator !== "undefined" && /Mac|iPhone|iPad/.test(navigator.platform);
 
 export function comboOf(e: KeyboardEvent): string | null {