Bug: copy/paste prevention listeners never fire — space-separated event names passed to addEventListener

Did you clear cache before opening an issue?

• I have cleared my cache

Is there an existing issue for this?

• I have searched the existing open and closed issues

Does the issue happen when logged in?

N/A

Does the issue happen when logged out?

Yes (source-code bug, independent of account state)

Does the issue happen in incognito mode when logged in?

N/A

Does the issue happen in incognito mode when logged out?

N/A

Issue details

Current Behavior

In frontend/src/ts/input/listeners/misc.ts, native addEventListener is called with space-separated event names (jQuery-style syntax), which registers literal event types that are never dispatched:

// frontend/src/ts/input/listeners/misc.ts:12-19
inputEl.addEventListener("copy paste", (event) => {
  event.preventDefault();
});

//this might not do anything
inputEl.addEventListener("select selectstart", (event) => {
  event.preventDefault();
});

The browser treats "copy paste" as a single event type named copy paste, so neither listener ever fires. As a result, copy/paste on the hidden words input is not actually prevented during a test.

Expected Behavior

Each event name should be registered separately:

for (const eventName of ["copy", "paste"]) {
  inputEl.addEventListener(eventName, (event) => event.preventDefault());
}

(The select/selectstart pair should be evaluated separately — the inline comment already suspects it may be dead code and could possibly be removed.)

Steps To Reproduce

1. Start a test.
2. Focus the words input and attempt to select/copy text or paste into it.
3. The default browser behavior is not prevented because the handlers were never attached to real event types.

Environment

• OS: Any
• Browser: Any
• Found via source review of master @ 91bd24bb8