Files

T

gramps b4bba4bf68 fix(web): harden the transparency injection to the OBS-standard element-wide !important wipe

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.

2026-09-10 14:04:11 -07:00

3.4 KiB

Raw Blame History

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 test TransparentBackgroundScript_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 — f3d578c has per-5s Audio 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 (Windows taskkill.exe, bash-quoted //F //IM) before rebuilds, and re-run if MSB3021 copy-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).

3.4 KiB Raw Blame History Unescape Escape