Fix resuming a session from the drawer by click or enter#563
Merged
Conversation
Clicking a row in the sessions drawer did nothing, and once a click had moved focus off the filter box, enter did nothing either, so the drawer could only be used by typing into the filter first. Two causes: resume was wired only to the filter box's submit, so the list's own click/enter was never handled; and the chat screen's normal-mode key handling swallowed enter for every drawer except the fleet one. Route resume through the list's own selection event so a click and enter both work, on the drawer and the full-screen tab alike, and give the chat screen a shared drawer base to check against so any drawer keeps its own enter instead of each one having to opt in by name.
The test pressed ctrl+d right after opening the drawer and relied on the drawer's mount-time focus having settled on the filter box. Both the filter Input and the chat TextArea bind ctrl+d as delete-right, so when the keypress reached the chat input first under CI load it was eaten silently: no dialog opened, the test failed, and the delete flow stayed uncovered, taking total coverage to 99.99% under the 100% gate. Focus the list explicitly before pressing: it binds no ctrl+d, so the key bubbles to the panel's Delete binding on every runner.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Opening the sessions drawer with
ctrl+oand clicking a conversation did nothing, and after a click, pressing enter also did nothing. The drawer was only usable by typing into the filter box first and then pressing enter, so with a single saved session it looked completely dead. The full-screen Sessions tab had the same problem: enter never resumed anything there.Two separate causes. Resume was wired only to the filter box's submit event, so the list's own click and enter (which Textual already reports) were never handled, and a click also moves keyboard focus off the filter box, leaving no working key to resume with. On top of that, once focus left the chat input the chat screen dropped into normal mode, where its key handling swallowed enter for every drawer except the fleet one, which had a hardcoded exemption.
Solution
Resume now comes from the list's own selection event, so a click and enter both resume the highlighted row, on the drawer and the full-screen tab alike. The chat screen's normal-mode check now asks whether focus sits inside any drawer through a shared base rather than naming a single drawer class, so a drawer keeps its own enter without having to opt in by name and a future drawer can't silently regress the same way.
Verified live in a real terminal across single and multiple sessions on both surfaces (click, click then filter then enter, and the tab), and covered by tests that fail on the old behavior.