Historical Performance graph sized to small

[2ndtlmining]

The historical performance graph is smaller than the Additional metrics, they need to be same size.

[2ndtlmining]

Still too small.

[2ndtlmining]

Problem statement

State: open, no label. Screenshot: the Additional Metrics row (Total App Instances /
Busiest Node / Decentralization) above the Historical Performance chart.

The Historical Performance chart reads smaller than the Additional Metrics cards above it. A fix was merged (PR #154, 1905df1) that compacted the Busiest Node card and raised the chart height 400 → 460, and its commit message claims Closes #149, #153 — but the issue is still open (a Closes line in a squash-commit body doesn't auto-close) and the reporter's follow-up says "Still too small." Live measurement on a production Docker build explains why: .chart-wrapper declares height: 460px and computes to 150px, because that height is an inline style= attribute blocked by the CSP (#157). The chart is sized by Chart.js's fallback — a 656 × 150 px plot inside a 466 px card. No value set in that attribute can ever change the rendered size.

"The historical performance graph is smaller than the Additional metrics, they need to be same size."

The busiest-node half landed; the chart half did not — and the reason is #157

PR #154 (1905df1, merged 2026-09-10T09:03Z) compacted BusiestNodeCard's CPU/RAM/SSD into a
3-column grid and bumped the chart height 400 → 460 (src/routes/+page.svelte:476-485). Its commit
message says Closes #149, #153 — but #153 is still open, because a Closes line in a squash-commit
body doesn't trigger GitHub's auto-close (only the PR description does). So step one is bookkeeping — but the height itself still has to be made to work (below).

Step two is the real finding: the 460 px cannot take effect in the deployed app. It is applied via
style="height: {height}px" (Chart.svelte:1158), which is exactly the inline style attribute the CSP
blocks (#157, verified: computed height stayed at the default while the attribute sat in the DOM). The
.chart-wrapper rule has no height (:1496-1499), so the chart is sized by Chart.js's fallback — i.e.
"too small" survives the fix that claimed to close it.

Measured on the running Docker build (2026-09-11), 22,809 transactions of data loaded:

Property	Value
.chart-wrapper inline attribute	height: 460px
.chart-wrapper computed height	150px
Canvas rendered size	656 × 150 px
.chart-container card height	466 px

So the chart's plot region is a 150px band inside a 466px card — the "smaller than the Additional
Metrics cards" complaint in the issue, exactly. A screenshot of that card is at /tmp/ft-chart.png.
This is reproducible on main today; #153 is not fixed by #154, it is only intended to be.
It also matches the reporter's own follow-up on this issue ("Still too small.", 2026-09-10) — with the
height attribute blocked, no value set there can ever change the rendered size.

What needs to change

• src/lib/components/Chart.svelte:9,1158 — drop the inline height in favour of a size prop selecting a CSS class on .chart-wrapper; no inline style, so SSR/hydration/CSP stop being factors.
• src/routes/+page.svelte:476-485 — pass the size instead of height={460}.
• Re-choose the height by measuring against the Additional Metrics row rather than reusing the 460 that was picked blind; if "same size" means the card, align them with CSS (shared min-height / align-items: stretch) instead of a magic number.
• Bookkeeping: close Historical Performance graph sized to small #153 from a PR body (Closes #153), since a squash-commit message doesn't auto-close it — which is why it is still open after Compact BusiestNode resource layout, taller Historical Performance chart #154 shipped.

Implementation plan

1. Fix Console errors #157's style-attribute mechanism first (or at minimum for this component).
2. Remove the inline height entirely. A custom property set through a style attribute would hit the
   same CSP block, so use a CSS class instead: a size prop (Chart.svelte:9) selects
   .chart-wrapper.chart-tall { height: 460px }. SSR, hydration and CSP all stop being factors.
3. Re-measure before choosing a number: with the double-height Additional Metrics row the chart
   should read as the same visual weight; the PR's 460 was chosen blind against a browser that ignored it.
   If "same size" means the card, not the plot, make the comparison against the tallest sibling card
   via CSS (align-items: stretch on the row / a shared min-height) rather than a magic number.
4. Only after that, close Historical Performance graph sized to small #153 (and note the auto-close gotcha in the PR body, not just the commit).

Success criteria

• On a production build, .chart-wrapper's computed height equals the intended value and the plot reads as the same visual weight as the Additional Metrics cards — i.e. the issue's screenshot is no longer reproducible.
• The fix is CSS-class based: no style= attribute appears on the wrapper in the rendered HTML, so the value cannot be silently blocked again.
• The chart's own states (loading, error, empty, decentralization entity-search) still fill the wrapper, and the CSV button, view/period/metric selects and category pills are unaffected.
• Verified at ≥1280 px, 768–1280 px and <768 px.
• Verified on a deployed/Docker instance, not only in dev, and Historical Performance graph sized to small #153 is closed by a PR whose body carries Closes #153.

Test plan

• Browser assertion: .chart-wrapper computed height equals the intended value, at ≥1280 px,
  768–1280 px, and <768 px (the chart already has responsive CSS at :1531+).
• Visual: side-by-side screenshot with the Additional Metrics row at 3 widths — this is the acceptance
  criterion the issue actually states.
• Regression: the chart's own states (loading / error / empty / entity-search view, :1159-1180) still
  fill the wrapper; CSV export button and category switching unaffected.
• Close-check: verify on the live deployment (not just npm run dev), since dev serves without
  adapter-node's CSP in the same configuration.