gramps
b4bba4bf68
The real-widget dumps (12:54/13:50) proved the OLD inline element.style.background='transparent' injection holds only while the page has nothing to paint: the capture was alpha-transparent, yet the recording showed a black opaque box over the whole element rect (1231,679 705x396) once the widget connected and repainted a container background-COLOR — CapturePreviewAsync always honors page CSS (MicrosoftEdge/WebView2Feedback specs/BackgroundColor.md), so any page-painted background wins over DefaultBackgroundColor. This is the OBS-solved class (all web-uri resources paint their own background): browser sources use a Custom CSS override, and the decade-validated formula for arbitrary pages is a pre-parse <style> with 'background-color: transparent !important' — https://obsproject.com/forum/threads/translucent-transparent-browser-source.59549/ ('body { background-color: rgba(0,0,0,0) !important }') plus the div-level variant for stubborn widgets (woahtech.com OBS custom-CSS guide). Injection is now an idempotent pre-parse style element wiping background-color on html,body,html * with !important (outranks every page rule, runs before page parse via AddScriptToExecuteOnDocumentCreatedAsync). Only background-COLOR is targeted — background images and widget art survive. Regression test asserts the element-wide !important form and that the losing inline form is gone. 9/9 WebView2Manager tests, 0 warnings.
3.4 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 — branch (a) CONFIRMED and FIX-APPLIED, awaiting the verify take.
The 12:54/13:50 dumps proved the REAL widget document captures TRANSPARENT
(%TEMP%\ytLive-web-8d7234ec…-w1..5.png alpha max 0/logged alpha 100% zero) YET the
recording kept showing a black opaque box over the element rect (1231,679,705,396 — crisp
edges, interior mean RGB ≈(1,6,13), NOT the desktop). Conclusion: the OLD inline
element.style.background='transparent' injection only holds while the page has nothing
to paint; once the widget connects and repaints a container background-COLOR, the capture
re-opaques → black box. That is the OBS-solved class ("all web-uri resources paint their
own background").
Slice 14 change (commit target): WebView2Manager.TransparentBackgroundScript is now a
pre-parse <style id='ytl-transparent-bg'> wiping background-color:transparent !important
on html,body,html * (background-images/art survive — only background-COLOR targeted).
Idempotent by element id; !important outranks every page rule (OBS forums 2016 body { background-color: rgba(0,0,0,0) !important } + div variant, woahtech OBS custom-CSS guide —
both cited in the commit message and MyMistakes.md).
internal const+ regression testTransparentBackgroundScript_Is_A_Important_Element_Wide_Wipe(asserts element-wide!important, style-element form, and that the losing inline.style.background=form is gone).- Build 0 warnings; 9/9 WebView2Manager tests pass.
THE ONE REMAINING STEP (verify, no further analysis)
- User REPLACES the app (build is current) and records the Live scene, widget animating, like the 12:54/13:50 takes.
- Verdict: element rect shows scene bg with widget art over it (NO black box) → transparency C LOSED, push gate #1 clears. If it still shows a solid black box you can SEE at a glance inside the widget's 705×396 area, bring it + then (and ONLY then) audit what other layer paints that rect in the composite — the web capture has been exonerated twice.
- Then the queued layer-order-save bug (dragging an element over another doesn't persist
SortOrder) is the next single use case.
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).