Repository navigation
Disarm Escape's Tab exit on click or blur - #467
Merged
Merged
Conversation
Escape arms the next Tab to move focus out of the editor, and only the editor's next keydown disarmed it. A click back into the editor, or focus leaving and returning by keyboard, fires no keydown there, so the next Tab still left the editor instead of indenting. Clearing the flag on pointerdown and blur ends the arm once the candidate is editing again or has already left, while Escape followed directly by Tab or Shift+Tab stays the keyboard way out, since neither event fires between those keys. Closes sysprog21#465
Contributor
|
Add screenshots to the pull request description to illustrate your work, as @ColtenOuO suggests. Example: #349 |
Contributor
Author
|
The description now has before and after screenshots: Google Chrome with a DevTools log of the editor's key, pointer and focus events, on b0059b2 and on this branch. |
Contributor
|
Thank @TKkusa for contributing! |
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
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.
Escape in the editor arms the next Tab to leave it, and only the editor's next keydown disarmed that. A click back into the editor, or focus leaving and coming back by keyboard, such as clicking Run tests and pressing Tab to return, left it armed, so the next Tab moved focus to the test drawer's resize handle instead of indenting. This also clears the flag on the editor's
pointerdownandblur. Escape followed directly by Tab or Shift+Tab still leaves the editor, since neither event fires between those keys, and the existing assertion for that path intests/browser/editor-pipeline.test.jsstill passes.The two new browser tests sit beside it, one per event: a click back into the editor after Escape, and focus leaving and returning without a click. Each fails on
main, each fails again when only its own event is removed from the listener loop, and both pass with the change.Validation:
node --test tests/browser/editor-pipeline.test.jspasses 47 of 47 with none skipped, and./scripts/test.shpasses with no failed gate on this tree. By hand in Chrome 155.0.8059.85, the steps in #465 leave the editor on b0059b2 built from source and indent with this change. Not checked locally: the Java runner's browser tests (no JDK),cargo-audit,actionlint,ruff,commentflowandshfmt; none of them covers the two changed files.Screenshots from Chrome 155.0.8059.85 on builds from source, b0059b2 first and this branch second, with DevTools logging
keydown,pointerdownandbluron the editor andfocusinon the document; the snippet only logs and sits at the top of each console. On b0059b2, the Tab after Escape and a click back into the editor blurs the editor and focus lands on#test-drawer-resizer; theSUMMARYand#results-togglelines are further Tab presses after focus had left. With this change, the same Escape and click are followed by five Tab presses that all stay on#editor; its last two lines came after them, when I switched to the screenshot tool and back. The two runs used different problems, which the key handling does not depend on.#456 also edits this keydown handler, at the top of the function rather than around the flag, so whichever merges second needs at most a trivial rebase.
Closes #465