Add Ctrl+Enter / Cmd+Enter shortcut to trigger Run tests

[SkyDrive2]

Problem Description

Currently, running tests requires manually moving the cursor and clicking the "Run tests" button with the mouse (web/interview.js:517):

nodes.run.addEventListener("click", runTests);

In mainstream competitive programming and interview platforms (e.g., LeetCode, HackerRank), candidates heavily rely on Ctrl+Enter (Windows/Linux) or Cmd+Enter (macOS) to run tests without taking their hands off the keyboard.

Furthermore, as noted in #131, the "Run tests" button can sometimes wrap or become awkward to click on narrower viewport widths. Having a standard keyboard shortcut significantly reduces interaction friction during timed interviews.

Proposed Changes
In web/interview.js, update the editor's keydown listener (line 581):

nodes.editor.addEventListener("keydown", (event) => {
  // Trigger Run tests with Ctrl+Enter or Cmd+Enter
  if ((event.ctrlKey || event.metaKey) && event.key === "Enter") {
    event.preventDefault();
    if (!nodes.run.disabled) {
      runTests();
    }
    return;
  }
  // existing Tab/Escape handling...
});

Update the button tooltip/title attribute in web/interview.html (line 171):

<button id="run-tests" class="run-button" type="button" title="Run tests (Ctrl+Enter / ⌘Enter)">
  Run tests
</button>

Expected Value
Matches mainstream interview and competitive programming editor ergonomics.
Allows candidates to focus on problem-solving without frequent context switching between keyboard and mouse.

[jserv]

@SkyDrive2 Thanks for the writeup, and for pointing at the exact listener.

This is already implemented in open PR #144, which was opened about a day before this issue. It binds Cmd+Enter on macOS and Ctrl+Enter elsewhere, and it differs from the proposal here in one way worth knowing: the listener sits on the page rather than on the editor, so the chord works right after reading the problem or picking a language, without clicking back into the editor first. It also follows the Run tests disabled state, so it does nothing while paused or before the media preflight is done.

Rather than write a second implementation, please review PR #144 and raise anything it misses there. This issue will close when that PR merges.

[SkyDrive2]

Thanks for pointing that out! Listening on the page level and handling the disabled states in #144 is indeed a cleaner approach. I'll take a look at PR #144. Thanks!