What happened
With a shortcut bound to thread.rename, renaming the focused thread leaves the window with no editable focus once the dialog closes. The caret does not return to the composer it was taken from, so the next keystrokes reach nothing and composer.focus has to be pressed manually after every rename.
Steps to reproduce
- Bind the command:
bb settings keyboard set thread.rename "mod+alt+r" (or assign Rename thread in Settings → Keyboard).
- Put the caret in a thread's composer and type a character, so focus is unambiguously in the input.
- Press the rename shortcut, type a new title, confirm with Enter.
- Keep typing without touching the mouse.
Expected
When the dialog closes, focus returns to the element it was taken from — the composer — which is exactly what composer.focus already describes: "Focus the active composer's input and move the caret to the end."
Actual
Focus is dropped entirely. Keystrokes go nowhere until the composer is refocused by clicking it or pressing the composer.focus shortcut.
Related, possibly by design
The same recovery step is needed when switching threads: activating another thread does not move focus into that thread's composer, so a keyboard-only workflow needs a composer.focus press after every switch. If not auto-focusing on switch is deliberate, a Settings → General toggle would serve both preferences. The rename case looks different, though — the dialog took focus from a known element and does not give it back, which reads as a plain focus-restore bug rather than a preference.
The rename command itself came from #1157.
Environment
- bb 0.42.0, desktop, macOS (Darwin 25.6.0)
thread.rename bound to mod+alt+r; no other override in play
What happened
With a shortcut bound to
thread.rename, renaming the focused thread leaves the window with no editable focus once the dialog closes. The caret does not return to the composer it was taken from, so the next keystrokes reach nothing andcomposer.focushas to be pressed manually after every rename.Steps to reproduce
bb settings keyboard set thread.rename "mod+alt+r"(or assign Rename thread in Settings → Keyboard).Expected
When the dialog closes, focus returns to the element it was taken from — the composer — which is exactly what
composer.focusalready describes: "Focus the active composer's input and move the caret to the end."Actual
Focus is dropped entirely. Keystrokes go nowhere until the composer is refocused by clicking it or pressing the
composer.focusshortcut.Related, possibly by design
The same recovery step is needed when switching threads: activating another thread does not move focus into that thread's composer, so a keyboard-only workflow needs a
composer.focuspress after every switch. If not auto-focusing on switch is deliberate, a Settings → General toggle would serve both preferences. The rename case looks different, though — the dialog took focus from a known element and does not give it back, which reads as a plain focus-restore bug rather than a preference.The rename command itself came from #1157.
Environment
thread.renamebound tomod+alt+r; no other override in play