bug(gui): a square backdrop appears behind the progress rings during a run

[LeyckerS]

Context

Every transfer row shows a circular progress ring. While a run is in flight, a square patch of a slightly different colour appears behind each ring, roughly the size of the ring's box. It is visible on the actively downloading rows and it does not belong to the design.

Reported from real use in the WebView2 GUI. Screenshot in the report shows it on eight simultaneous downloading rows.

Where to look

Two suspects, both in web/styles.css, and they interact.

1. The drop-shadow filter on the ring (L598-606):

.ring .ring-fg {
  stroke: var(--c);
  ...
  filter: drop-shadow(0 0 4px color-mix(in srgb, var(--c) 80%, transparent));
  transition: stroke-dasharray .3s linear;
}

A CSS filter promotes the element to its own compositing layer. In Chromium-based engines that layer is rasterised against the element's bounding box, which is a rectangle — and a rectangle is exactly what is showing.

2. content-visibility on the row (L564-577):

.frow {
  ...
  content-visibility: auto;
  contain-intrinsic-size: 3.4rem;
}

content-visibility: auto applies containment to the row. Containment plus a filtered descendant plus the spin animation on some states (L613-614) is a known source of repaint artifacts in Chromium.

The same drop-shadow pattern also exists on .spark circle (L514) — worth checking whether the sparkline shows a milder version of the same thing.

What to do

Bisect before fixing. In DevTools, on a row that shows the artifact:

1. Disable filter on .ring .ring-fg — does the square disappear?
2. Re-enable it, disable content-visibility on .frow — does it disappear?
3. Report which one it was, or that it needs both.

Then fix the one that is responsible, keeping the glow if you can. Options worth trying, in order of preference:

• Move the filter to a wrapper that has no containment applied to it
• Replace drop-shadow with an SVG <filter> with an explicit oversized filter region
• Give the row contain-intrinsic-size room so the filter's bounds are not clipped
• Last resort: drop the glow on the ring. It is decoration; a square artifact is worse than no glow

Do not remove content-visibility outright without measuring — it is there for scroll performance with long transfer lists, and trading a visual glitch for a janky list is not an improvement. If you conclude it has to go, say so in the PR with what you observed.

Acceptance criteria

• No square backdrop behind the rings in any transfer state (queue, extract, download, ok, fail, kill)
• The ring still animates and still shows progress
• Scrolling a long transfer list is not visibly slower than before
• The PR states which of the two causes it actually was, with what you observed
• Only web/styles.css and, if genuinely needed, web/index.html are touched

Notes for the contributor

This one needs Windows and the WebView2 GUI. It cannot be verified from Linux or macOS, and it cannot be verified from the code alone — which is why the issue asks you to bisect in DevTools rather than guess. Most of the open work here does not need Windows; this one does.

python moon_bridge.py starts the GUI. python render_gui.py out/ renders the interface headlessly in Chromium and may or may not reproduce it — if it does, that is a much faster loop, and worth reporting either way.

Comment here before you start, and say whether you have a Windows machine.

[RubenSanosh]

Hey @LeyckerS, I'd like to take this one too. I've got a Windows machine so I can run the WebView2 GUI and bisect in DevTools like you described.

[LeyckerS]

Every line reference in this issue is now wrong. V3 (#123) rebuilt web/styles.css and moved everything by roughly 130 lines. The bug itself is unchanged — both ingredients are still there — but anyone opening the file at the numbers above would be reading unrelated rules.

Corrected against main at 867e88f:

What the issue says	Where it actually is now
drop-shadow on the ring, L598-606	.ring .ring-fg, lines 737-745 — the filter itself is line 743
content-visibility on the row, L564-577	.frow, content-visibility: auto on line 715, contain-intrinsic-size: 3.4rem on 716
the spin animation, L613-614	applied at 752-753, @keyframes spin at 757
.spark circle, L514	that element no longer exists

Two things worth knowing beyond the renumbering:

The filter value changed. It is no longer a fixed colour:

filter: drop-shadow(0 0 4px color-mix(in srgb, var(--c) 80%, transparent));

--c is the per-state colour set on .frow, so the shadow is now computed per row and changes as a transfer moves between states. If the artifact is a repaint problem, a filter whose colour changes on state transition is a more likely trigger than the old static one, not less.

The sparkline suspect is gone and has been replaced. .spark circle does not exist in V3. The sparkline is now .spark polyline (lines 615-623), and it carries its own drop-shadow on line 622 — a fixed rgba(79, 227, 208, 0.75). So the "check whether the sparkline shows a milder version of the same thing" note still applies, just to a different element with a different filter.

The combination this issue is about — content-visibility: auto containment on .frow, a filtered SVG descendant, and spin running on some states — is intact. Still reproducible, still needs Windows, still unclaimed.