Add a keyboard shortcut for Run tests - #144
Conversation
|
@melonpuff The only reference here is |
|
Coming from #175. The page-wide listener and edge-case guards in this PR thoroughly cover what I had envisioned. Regarding @ColtenOuO's comment on discoverability: in my proposal in #175, I had suggested adding a <button id="run-tests" class="run-button" type="button" title="Run tests (Ctrl+Enter / ⌘Enter)">Perhaps we can also adopt that change here Aside from the edge cases already highlighted by @jserv and @ColtenOuO, the implementation looks solid! |
ColtenOuO
left a comment
ColtenOuO
left a comment
There was a problem hiding this comment.
The shortcut behavior looks good, but could we also expose it on the Run tests button before this closes #175?
#175 proposes a button tooltip, and the current UI otherwise gives candidates no way to discover that the shortcut exists. Adding both a visible/hover hint and the semantic shortcut declaration would complete that part of the issue
Yeah, I agree that this properly resolves the issue. While keyboard shortcuts do improve the user experience, we shouldn't assume users will already know about them. |
fb8f0ea to
5073439
Compare
|
Thanks @SkyDrive2 and @ColtenOuO for pointing out the discoverability gap. Fixed in 5073439: the Run tests button now has Screenshot from Chrome on macOS 15: |
|
I think we are almost there. Could you please squash the minor commits and update the commit message accordingly? |
Running the code meant leaving the keyboard for the Run tests button, which a candidate presses many times in an interview. Cmd+Enter now presses it from anywhere on the page, and Ctrl+Enter does the same where there is no Command key, so reading the problem or picking a language costs no click back into the editor. Other text fields keep the chord for their own line breaks, and Shift or Alt with it, a keydown an input method still owns, and the repeats of a held chord are ignored. The shortcut follows the button's disabled state, so it never starts a second run or fires while paused, and it does nothing before the media preflight is done or once the interview has ended, where the button is still enabled. The browser tests count runs rather than clicks and cover both chords, a press from outside the editor, the preflight, an ended interview, a second press during a run, and a press while paused.
Nothing on the page said the shortcut existed, so a candidate who had not met the chord elsewhere would never find it. The Run tests button now names it in a title shown on hover, and carries aria-keyshortcuts for Control+Enter and Meta+Enter so a screen reader announces it too.
01e1825 to
ab3efb0
Compare
|
Thank @melonpuff for contributing! |
4 participants
Summary
Cmd+Enter on macOS, or Ctrl+Enter on Windows and Linux, now runs the tests from anywhere on the interview page. The chord is borrowed from LeetCode, where it submits a solution. CodeTrial has no separate submit, so here it presses Run tests.
The shortcut listens on the whole page rather than on the editor, so it still works right after reading the problem or picking a language, without clicking back into the editor first. Other text fields, such as the report's STAR answers and the candidate case inputs, keep the chord for themselves. Only the plain chord counts: Shift or Alt held with it, a press while composing with an IME, and the repeats of a held chord are ignored.
It follows the Run tests button's disabled state, so it never starts a second run or fires while paused. It also does nothing before the media preflight is done or once the interview has ended. The button names the shortcut in a hover tooltip, and in
aria-keyshortcutsfor screen readers.Testing
Automated, on 01e1825 (macOS 15):
node --test tests/browser/run-shortcut.test.js: 6 passed, 0 skipped. The tests cover:By hand, in Chrome on macOS 15, with the official release binary built from 4874d8d (this branch's base) as the server and
--web-dirpointing it at this branch'sweb/, so the page ran this branch'sinterview.js:Refs #131: the shortcut still reaches Run tests when the avatar covers the button. This may serve as a workaround until the overlap is fixed.
Closes #175
Summary by cubic
Cmd+Enter (macOS) and Ctrl+Enter (Windows/Linux) now run the tests from anywhere on the interview page, without clicking back into the editor first. The shortcut follows the Run tests button's disabled state, so it never starts a second run or fires while paused, and does nothing before the media preflight completes or after the interview ends. Only the plain chord works—Shift and Alt are ignored—and presses during IME composition or key repeat are dropped, so holding the chord cannot fire multiple runs. The shortcut prevents Enter's default, never typing a newline into the code or activating a focused button, except in other text fields, which keep the chord for their own line breaks.
The shortcut is now discoverable: the Run tests button shows it in a hover tooltip and announces it via
aria-keyshortcutsfor screen readers. New browser tests cover both chords in and out of the editor, the preflight, an ended interview, a second press while a run is in flight, and a press while the interview is paused.Written for commit ab3efb0. Summary will update on new commits.