Did you clear cache before opening an issue?
Is there an existing issue for this?
Does the issue happen when logged in?
Yes
Does the issue happen when logged out?
Yes
Does the issue happen in incognito mode when logged in?
Yes
Does the issue happen in incognito mode when logged out?
Yes
Issue details
Current Behavior
Two spots replace < / > with HTML entities but omit the trailing semicolon, producing non-standard references that interact badly with .slice():
// frontend/src/ts/test/result-word-highlight.ts:314-319
inputWordEl.innerHTML = userInputString
.replace(/\t/g, "_")
.replace(/</g, "<") // no semicolon
.replace(/>/g, ">") // no semicolon
.slice(0, wordEl.childElementCount);
// frontend/src/ts/test/test-ui.ts:1405-1409 — same pattern
Because the slice happens after replacement, input ending in < gets truncated mid-entity (e.g. &l), which then renders as literal garbage text instead of <. Legacy-style semicolon-less entities also double-decode oddly when adjacent entity-like text exists in the typed string.
Expected Behavior
Replace before slicing with proper entities (or escape after slicing):
.replace(/</g, "<")
.replace(/>/g, ">")
Ideally both call sites would share one escaping helper (e.g. reuse Misc.escapeHTML from utils/misc.ts:137-145, which already escapes correctly).
Steps To Reproduce
- Type a word containing
< such that the input length exceeds the word length so .slice() cuts inside the appended entity (e.g. type abc< against word xyz).
- Observe raw
&l fragments rendered in the input overlay instead of the < character.
Environment
- OS: Any
- Browser: Any
- Found via source review of
master @ 91bd24b
Did you clear cache before opening an issue?
Is there an existing issue for this?
Does the issue happen when logged in?
Yes
Does the issue happen when logged out?
Yes
Does the issue happen in incognito mode when logged in?
Yes
Does the issue happen in incognito mode when logged out?
Yes
Issue details
Current Behavior
Two spots replace
</>with HTML entities but omit the trailing semicolon, producing non-standard references that interact badly with.slice():Because the slice happens after replacement, input ending in
<gets truncated mid-entity (e.g.&l), which then renders as literal garbage text instead of<. Legacy-style semicolon-less entities also double-decode oddly when adjacent entity-like text exists in the typed string.Expected Behavior
Replace before slicing with proper entities (or escape after slicing):
Ideally both call sites would share one escaping helper (e.g. reuse
Misc.escapeHTMLfromutils/misc.ts:137-145, which already escapes correctly).Steps To Reproduce
<such that the input length exceeds the word length so.slice()cuts inside the appended entity (e.g. typeabc<against wordxyz).&lfragments rendered in the input overlay instead of the<character.Environment
master@ 91bd24b