keyboard focus after clicking the "select all mails" checkbox

mbunkus commented

2026-09-03 21:01:21 +00:00

After clicking the "select all mails" checkbox you cannot use any of the keyboard shortcuts until you click somewhere else. I haven't tried everywhere, but areas that definitely process keyboard shortcuts include:

folder in folder list
message in message list
message view
compose button, followed by escape for closing the compose dialog again

_{Rebuilt from: GH Archive, session transcript.}

After clicking the "select all mails" checkbox you cannot use any of the keyboard shortcuts until you click somewhere else. I haven't tried everywhere, but areas that definitely process keyboard shortcuts include: - folder in folder list - message in message list - message view - compose button, followed by escape for closing the compose dialog again <sub>Rebuilt from: GH Archive, session transcript.</sub>

jcoffey-dev commented

2026-09-03 22:14:35 +00:00

Owner

Fixed, and it is in latest now — 2026.9.3-pr272, pushed a few minutes ago.

The cause was not the checkbox keeping focus, which it should. The guard that stops a archiving while you are typing in the search box tested tagName === "INPUT", and that is true of a checkbox too. So every shortcut stayed suppressed while it held focus. Nothing about a checkbox swallows a keystroke in the first place — Space is handled by the browser before that listener ever runs — so there was never anything to protect there.

It now asks whether the focused element takes text rather than whether it is an input. A <select> still counts, since typing a letter jumps to the matching option and a shortcut would steal that.

Your report was the visible half of something broader: thirteen checkboxes and seven file inputs across the app had the same problem. The one that would have annoyed you next is the per-message checkbox — ticking a few messages and pressing e to archive them also did nothing.

I have verified it on the live demo rather than only in tests: "Select all" checked, focus still on the checkbox, ? opens the shortcut list.

Leaving this open so you can confirm it against your own setup — you mentioned you cannot reopen a closed issue, and I would rather you close it than take my word for it.

Fixed, and it is in `latest` now — **`2026.9.3-pr272`**, pushed a few minutes ago. The cause was not the checkbox keeping focus, which it should. The guard that stops <kbd>a</kbd> archiving while you are typing in the search box tested `tagName === "INPUT"`, and that is true of a checkbox too. So every shortcut stayed suppressed while it held focus. Nothing about a checkbox swallows a keystroke in the first place — <kbd>Space</kbd> is handled by the browser before that listener ever runs — so there was never anything to protect there. It now asks whether the focused element *takes text* rather than whether it is an input. A `<select>` still counts, since typing a letter jumps to the matching option and a shortcut would steal that. Your report was the visible half of something broader: thirteen checkboxes and seven file inputs across the app had the same problem. The one that would have annoyed you next is the per-message checkbox — ticking a few messages and pressing <kbd>e</kbd> to archive them also did nothing. I have verified it on the live demo rather than only in tests: "Select all" checked, focus still on the checkbox, <kbd>?</kbd> opens the shortcut list. Leaving this open so you can confirm it against your own setup — you mentioned you cannot reopen a closed issue, and I would rather you close it than take my word for it.

jcoffey-dev commented

2026-09-04 19:16:31 +00:00

Owner

Closing this one — the fix has been in latest since 2026.9.3-pr272, and nothing has come back on it.

To recap what actually changed, since it was not what the title suggests: the checkbox keeping focus was correct and stayed. The guard that stops a archiving while you type in the search box tested tagName === "INPUT", which is true of a checkbox too, so every shortcut stayed suppressed while it held focus. It now asks whether the focused element takes text. Thirteen checkboxes and seven file inputs across the app had the same problem — the per-message checkbox being the one you would have hit next.

You can reopen this yourself now. You mentioned you could not, and you were right: read access does not include it. You are on the Triage role as of today, which does — so if it still misbehaves on your own setup, reopen rather than filing again.

Closing this one — the fix has been in `latest` since **`2026.9.3-pr272`**, and nothing has come back on it. To recap what actually changed, since it was not what the title suggests: the checkbox keeping focus was correct and stayed. The guard that stops <kbd>a</kbd> archiving while you type in the search box tested `tagName === "INPUT"`, which is true of a checkbox too, so every shortcut stayed suppressed while it held focus. It now asks whether the focused element *takes text*. Thirteen checkboxes and seven file inputs across the app had the same problem — the per-message checkbox being the one you would have hit next. **You can reopen this yourself now.** You mentioned you could not, and you were right: read access does not include it. You are on the Triage role as of today, which does — so if it still misbehaves on your own setup, reopen rather than filing again.

keyboard focus after clicking the "select all mails" checkbox #260