Fix outcome timeline overflow in HTML reports

[thomhurst]

Summary

• constrain the overview grid's flexible columns so large timelines cannot widen the report
• add horizontal scrolling when outcome ticks exceed the card width
• add regression coverage for the generated report CSS

Root cause

Each outcome tick has a 2px minimum width plus a 1px gap. With hundreds of tests, that minimum content width expanded the grid's 1fr track beyond the report container.

Impact

Large test suites keep the HTML report within its normal max width while preserving individually clickable timeline ticks through horizontal scrolling.

Validation

• dotnet test tests/TUnit.Engine.Tests/TUnit.Engine.Tests.csproj --no-restore --treenode-filter "/*/*/HtmlReporterTests/*" — 37 passed
• Full TUnit.Engine.Tests run — 238 passed, 124 skipped, 7 unrelated reflection-harness failures where child runs discovered zero tests

Closes #6551

[coderabbitai]

Warning

Review limit reached

@thomhurst, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 16 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: abe5b230-cafa-49c6-b6b2-c9fdd49c5f50

📥 Commits

Reviewing files that changed from the base of the PR and between f824dd6 and 2c42690.

📒 Files selected for processing (2)

• src/TUnit.Engine/Reporters/Html/TestReport.template.html
• tests/TUnit.Engine.Tests/HtmlReporterTests.cs

---

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

This PR prevents large outcome timelines from widening generated HTML reports and preserves access to individual ticks through horizontal scrolling.

• Uses zero-minimum grid tracks in both desktop and responsive layouts.
• Wraps the outcome timeline in a horizontally scrollable container.
• Adds regression assertions for the generated markup and CSS.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
src/TUnit.Engine/Reporters/Html/TestReport.template.html	Constrains all relevant grid tracks and introduces an internal horizontal scroll container, fully addressing the previously reported responsive overflow.
tests/TUnit.Engine.Tests/HtmlReporterTests.cs	Adds regression coverage for the desktop and responsive grid constraints and the timeline overflow markup.

_{Reviews (2): Last reviewed commit: "fix(reporting): handle responsive overfl..." | Re-trigger Greptile}

[claude]

Code review

Summary: this constrains .run-grid-1's flexible columns with minmax(0, 1fr) and adds overflow-x: auto to .outcome-strip so hundreds of 2px-minimum outcome ticks can't inflate the grid past the report's max width. Verified the mechanism is correct for the desktop layout, and confirmed no CLAUDE.md violations (two independent passes — this is CSS/HTML template + test code, outside the scope of the dual-mode, snapshot, VSTest, and AOT rules).

However, I found the fix is incomplete, plus a couple of smaller regressions and a design point worth considering.

1. The fix doesn't apply at narrower viewports — the original bug still reproduces (confirmed with a headless-browser repro)

TUnit/src/TUnit.Engine/Reporters/Html/TestReport.template.html

Lines 617 to 621 in 33cd062

	.run-wrap { max-width: 1280px; margin: 0 auto; padding: 28px 28px 80px; }
	.run-grid-1 { display: grid; grid-template-columns: 320px minmax(0, 1fr) minmax(0, 1fr); gap: 16px; margin-bottom: 16px; }
	@media (max-width: 1100px) { .run-grid-1 { grid-template-columns: 1fr; } }
	.run-grid-2 { display: grid; grid-template-columns: 1.3fr 1fr; gap: 16px; margin-bottom: 16px; }
	@media (max-width: 1100px) { .run-grid-2 { grid-template-columns: 1fr; } }

TUnit/src/TUnit.Engine/Reporters/Html/TestReport.template.html

Lines 995 to 999 in 33cd062

	/* run view: stacked, tighter */
	.run-wrap { padding: 20px 18px 80px; }
	.run-grid-1, .run-grid-2 { grid-template-columns: 1fr; gap: 12px; }
	.donut-card { padding: 18px; }
	.panel-head { padding: 12px 16px; }

The desktop rule (line 618) got minmax(0, 1fr), but the max-width: 1100px override (line 619) and the nested max-width override (line 997) both collapse back to plain 1fr. overflow-x: auto on .outcome-strip does not fix this for these tracks: that CSS rule ("automatic minimum size = 0 for scroll containers") only zeroes the auto min-width of an element that is itself a direct flex/grid item — here the actual grid item is .strip-card (no overflow set), two levels up from #strip. So .strip-card's min-content width is still driven by the tick strip's intrinsic width.

I reproduced this in headless Chrome at a 900px viewport with 400 ticks: with the current 1fr override, .strip-card renders at 1241px and the whole document overflows (scrollWidth 1269 vs clientWidth 900) — i.e. the exact bug this PR fixes, still present below 1100px width. Changing those two overrides to minmax(0, 1fr) (matching line 618) fixes it: strip scrolls internally, document.scrollWidth stays at 900.

Since this is precisely the large-suite scenario the PR targets, and mobile/narrow-viewport report viewing is a normal case (e.g. checking CI results from a phone), this seems worth fixing in the same PR rather than as a follow-up.

2. Axis labels desync once the strip scrolls

TUnit/src/TUnit.Engine/Reporters/Html/TestReport.template.html

Lines 1236 to 1245 in 33cd062

	<div class="card strip-card">
	<div class="card-title">Outcome timeline</div>
	<div class="outcome-strip" id="strip"></div>
	<div class="strip-axis">
	<span id="stripStart">start</span>
	<span id="stripMid"></span>
	<span id="stripEnd">end</span>
	</div>
	</div>

.strip-axis (start/mid/end labels) is a sibling of #strip, not inside the new scroll container. Once #strip scrolls, the "end" label still sits at the card's right edge while the ticks actually visible are from earlier in the run — the axis now misrepresents what's on screen. Consider wrapping #strip and .strip-axis together in one scroll container, or making the axis reflect the visible scroll position.

3. Minor: hover affordance is clipped

TUnit/src/TUnit.Engine/Reporters/Html/TestReport.template.html

Lines 659 to 661 in 33cd062

	.outcome-strip { display: flex; gap: 1px; height: 60px; align-items: stretch; overflow-x: auto; overflow-y: hidden; }
	.outcome-strip .tick { flex: 1; min-width: 2px; border-radius: 2px; opacity: 0.85; transition: opacity 100ms, transform 100ms; cursor: pointer; }
	.outcome-strip .tick:hover { opacity: 1; transform: scaleY(1.06); }

.tick:hover { transform: scaleY(1.06) } grows a 60px tick to ~63.6px, but the new overflow-y: hidden now clips ~1.8px off each end. Non-blocking (opacity still changes on hover), but worth a quick check — e.g. overflow-y: visible combined with overflow-x: auto isn't valid (computes to auto), so this would need a small wrapper if you want to preserve the effect.

4. Test coverage: consider a name/assertion that matches what's actually verified

TUnit/tests/TUnit.Engine.Tests/HtmlReporterTests.cs

Lines 378 to 396 in 33cd062

	[Test]
	public void GenerateHtml_Constrains_Outcome_Timeline_To_Its_Grid_Column()
	{
	var html = HtmlReportGenerator.GenerateHtml(new ReportData
	{
	AssemblyName = "Tests",
	MachineName = "machine",
	Timestamp = "2026-08-09T00:00:00.0000000Z",
	TUnitVersion = "1.0.0",
	OperatingSystem = "Windows",
	RuntimeVersion = ".NET 10.0",
	TotalDurationMs = 0,
	Summary = new ReportSummary(),
	Groups = [],
	});
	html.ShouldContain("grid-template-columns: 320px minmax(0, 1fr) minmax(0, 1fr)");
	html.ShouldContain(".outcome-strip { display: flex; gap: 1px; height: 60px; align-items: stretch; overflow-x: auto; overflow-y: hidden; }");
	}

GenerateHtml only does string .Replace() against a static embedded template, so this test's ReportData/Groups = [] is unused — it really just pins that two literal CSS strings still exist in the template (same pattern as the existing GenerateHtml_SubstitutesTitleAndProjectPlaceholders, so this is consistent with the file's convention, not a one-off shortcut). The name ..._Constrains_Outcome_Timeline_To_Its_Grid_Column implies it verifies overflow behavior, though — a name like GenerateHtml_EmitsOutcomeTimelineOverflowCss would more accurately describe what's covered. Given finding #1, this test also wouldn't have caught the narrower-breakpoint gap, since it only checks the desktop rule string.

5. Worth a follow-up issue, not a blocker: horizontal scroll vs. "whole run at a glance"

The outcome timeline is meant to be a sparkline-style overview of the entire run. Making it horizontally scrollable means for the large-suite case this PR is about, a viewer only sees the first ~100-150 ticks by default — the "at a glance" property is partly lost, and the scrollbar is a thin affordance to communicate there's more. A bucketed/aggregated tick approach (each tick = N tests, colored by worst outcome in the bucket — similar to CI history sparklines) would preserve the whole-run overview and scale better (fewer DOM nodes/listeners for huge suites) than horizontal scroll. This is a bigger change than this bugfix's scope, so I'd suggest filing it as a follow-up rather than blocking on it here.

[claude]

Review: #6574 — contain outcome timeline overflow

Verified locally: checked out pull/6574/merge, ran dotnet test tests/TUnit.Engine.Tests/TUnit.Engine.Tests.csproj --treenode-filter "/*/*/HtmlReporterTests/*" → 37/37 passed.

What the fix does

• Switches the run-grid-1 grid tracks (and the ≤1100px collapsed layout) from 1fr to minmax(0, 1fr) so a flex child with many min-width: 2px ticks can no longer force the track — and the whole report — wider than its container.
• Wraps the outcome timeline in a .outcome-strip-scroll (overflow-x: auto) / .outcome-strip-content (width: max-content; min-width: 100%) pair, so once tick count exceeds the card width it scrolls horizontally instead of blowing out the page.
• Adds a regression test asserting the generated HTML contains the new CSS/markup.

Prior review feedback — addressed

Greptile flagged that the original commit (33cd062f) left the @media (max-width: 1100px) rule using a bare 1fr, which would reintroduce the overflow bug on narrow viewports. That's fixed in the follow-up commit 2c426901 — both the run-grid-1 media query and the .run-grid-1, .run-grid-2 mobile rule now use minmax(0, 1fr) too. Confirmed the current diff reflects this.

Correctness

• Traced the CSS/flex mechanics: .outcome-strip ticks (flex: 1; min-width: 2px) inside a width: max-content parent will size to min-content (sum of tick minimums) when they don't fit, and stretch to fill when they do — this is the correct way to get "shrink-to-fit-then-scroll" behavior out of flexbox without JS.
• The tick click/hover handlers bind directly to #strip by id, unaffected by the new wrapper divs — no functional regression there.
• The new test's assertion style (literal ShouldContain string matches against the generated HTML/CSS) is consistent with the rest of HtmlReporterTests.cs, not a new pattern introduced here.

Suggestion (non-blocking)

For very large suites (thousands of tests, not just "hundreds"), this still renders one <div class="tick"> per test and relies on the user scrolling a potentially very wide strip. That's a reasonable scope for this bug fix, but if huge timelines come up again, consider capacity-limiting/bucketing ticks (e.g. aggregate runs of same-outcome tests into one wider tick, or virtualize the strip) rather than growing the scrollable width indefinitely — better both for DOM size and for the timeline actually being scannable. Not something this PR needs to solve.

Verdict

Looks good — root cause correctly identified, fix is minimal and targeted, prior review feedback incorporated, and covered by a passing regression test. No blocking issues found.