fix(echarts): replace every newline in the tooltip, not just the first

[MarkusNeusinger]

Closes CodeQL alert #103 (js/incomplete-sanitization) on plots/bar-heart-rate-zones/implementations/javascript/echarts.js:55.

-`<b>${zoneNames[idx].replace("\n", " ")}</b><br/>` +
+`<b>${zoneNames[idx].replace(/\n/g, " ")}</b><br/>` +

.replace with a string argument replaces only the first occurrence.

Nothing renders differently today

Every entry in zoneNames carries exactly one newline ("Z1\nRecovery", "Z2\nEndurance", …), so first-occurrence and all-occurrences produce the same string. The defect is latent: a label gaining a second line break would put a raw newline inside the tooltip's HTML.

two newlines, before: "A B\nC"   ← the second survives
two newlines, after:  "A B C"

Worth fixing anyway — the alert is real and the cost is one character.

Scope

Checked the whole catalogue: this pattern appears exactly once. If it recurred it would belong in the generation prompt rather than in the generated file, since plots/ is pipeline output and a regeneration of this spec overwrites it.

node --check passes.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR updates the ECharts implementation for the bar-heart-rate-zones plot to ensure all newline characters are removed from the tooltip label (instead of only the first), addressing the CodeQL js/incomplete-sanitization alert scenario described in the PR metadata.

Changes:

• Update tooltip label sanitization from single-occurrence newline replacement to global newline replacement via regex.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

plots/bar-heart-rate-zones/implementations/javascript/echarts.js:55

• The tooltip normalization replaces only \n. If a label ever contains Windows-style line breaks (\r\n), the \r will remain in the HTML string. Normalizing \r?\n makes the change match the intent of “replace every newline” more robustly without affecting current output.

        `<b>${zoneNames[idx].replace(/\n/g, " ")}</b><br/>` +

CHANGELOG.md:241

• This changelog entry says the .replace("\n", " ") pattern occurs “exactly once across the catalogue”. That’s only true if you mean the JavaScript ECharts tooltip specifically; there are other .replace("\n", " ") usages elsewhere in the repo. Suggest tightening the wording so the changelog statement is accurate and unambiguous.

  gaining a second line break would put a raw newline inside the tooltip's HTML. The pattern occurs
  exactly once across the catalogue — were it recurring it would belong in the generation prompt,
  since `plots/` is pipeline output and a regeneration overwrites this file (#10480).

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

plots/bar-heart-rate-zones/implementations/javascript/echarts.js:55

• The tooltip label sanitizer replaces \n but would leave a \r intact if the input ever contains CRLF line endings (e.g., pasted or Windows-originated strings). That can still introduce raw whitespace/control characters into the HTML tooltip string.

        `<b>${zoneNames[idx].replace(/\n/g, " ")}</b><br/>` +

CHANGELOG.md:241

• This changelog entry claims the .replace("\n", " ") pattern occurs "exactly once across the catalogue", but the repo contains other instances (e.g., plots/tree-decision/implementations/python/pygal.py). Consider narrowing the claim to the JavaScript/ECharts tooltip context or removing the "exactly once" assertion to keep the changelog accurate.

  gaining a second line break would put a raw newline inside the tooltip's HTML. The pattern occurs
  exactly once across the catalogue — were it recurring it would belong in the generation prompt,
  since `plots/` is pipeline output and a regeneration overwrites this file (#10480).