gramps
0f72c53aa5
The 15:34 take's box interior is the widget's OWN full-canvas opaque paint — a
black void with wide content strips at the top/bottom and a right-edge bar —
arriving AFTER the first-second blank-transparent dumps. A background-color-only
!important wipe (b4bba4b) can't touch it because CSS gradients/backdrops are
background-IMAGE, not background-color.
OBS's fix for this exact symptom is background-image:none (obsproject/obs-studio#6659:
"set the CSS for html and body to background: none !important"). Injection now wipes
background-image:none!important on html,body,html * alongside the color wipe; HTML
overlay art (<img>/DOM/CSS shapes) survives — that is browser-source semantics.
Also re-arms WidgetDumpRemaining=5 ~30s after nav so the next take dumps the real
document INSIDE the recording window (the previous dumps proved blank at +1s and
missed the later backdrop paint).
9/9 WebView2Manager tests, 0 warnings.
2.9 KiB
HANDOFF — 2026-09-10 (transparency hardening applied)
Branch / Commit State
main HEAD will be = the new transparency-hardening commit (slice 14). Ahead of
origin by 19, NOT pushing (user ruling: no push until web-overlay transparency AND
audio-silence are addressed).
ACTIVE THREAD (ONE problem at a time)
Web-uri transparency — second hardening applied (background-image wipe), awaiting take.
The 15:34 take: the recording's box interior is the widget's OWN full-canvas opaque paint
(bright content strips at top/bottom + right bar over a black void) — NOT desktop, NOT a
compositor blend. The real-document dumps showed blank-transparent at +1s and the page's
backdrop appears later; a background-COLOR-only !important wipe (b4bba4b) leaves CSS
background-IMAGE (gradient/backdrop) intact — the OBS answer is background: none !important, background-image too (obsproject/obs-studio#6659).
Slice 15 (commit target, the fix):
TransparentBackgroundScriptnow also wipesbackground-image:none!importantonhtml,body,html *(gradients/backdrops die;<img>/DOM art survives — OBS semantics).NavigateCompletedre-armsWidgetDumpRemaining = 5~30s in, so this take dumps the real document INSIDE the recording window (the missing evidence last time).- Test extended (asserts
background-image:none!importantpresent, weak inline form absent).
THE ONE REMAINING STEP (verify, no further analysis)
- User records the Live scene, widget animating (pre-record ~35s so the 30s re-arm dump fires mid-take).
- Verdict: element rect shows the scene backdrop behind the widget art (no black box/void) → transparency CLOSED, push gate #1 clears. If a black void persists BEYOND a visible background-image, it's not background painting and only chroma-key remains — bring the take and we do the compositor key, not more capture investigation.
- Then the queued layer-order-save bug (reorder doesn't persist
SortOrder) is next.
Other threads (paused)
- Audio silence —
f3d578chas per-5sAudio live:telemetry; next take with desktop audio ACTIVE names the stage. Push gate #2. - Webcam missing — "MJPG negotiation refused (being used by another process)". Queued.
- Web capture speed — ~10-14Hz effective, user satisfied. Revisit only on request.
Landmines
- testhost shares startup.log with the app — filter by time.
- App was running at commit time;
taskkill //F //IM ytLive.exe(Windowstaskkill.exe, bash-quoted//F //IM) before rebuilds, and re-run ifMSB3021copy-lock appears. - Build/tests:
/mnt/c/Program Files/dotnet/dotnet.exe build …/ vstest. - Probing:
/mnt/c/Program Files/Krita (x64)/bin/ffmpeg.exe/ffprobe.exe— Windows exes take Windows-style paths. - Never re-derive the transparency story again — MyMistakes "SPIN GUARD → RESOLVED" is the record (wash-rinse-repeat cost the user a whole session).