From 0f72c53aa5d530f6287fba0623186f0cfd567921 Mon Sep 17 00:00:00 2001 From: gramps Date: Thu, 10 Sep 2026 15:42:26 -0700 Subject: [PATCH] =?UTF-8?q?fix(web):=20wipe=20background-image=20too=20?= =?UTF-8?q?=E2=80=94=20the=20widget's=20black=20void=20is=20a=20CSS=20back?= =?UTF-8?q?drop=20gradient,=20not=20a=20color?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 (/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. --- HANDOFF.md | 47 ++++++++++++---------------- MyMistakes.md | 25 +++++++++------ Services/WebView2Manager.cs | 23 ++++++++++++-- ytLive.Tests/WebView2ManagerTests.cs | 1 + 4 files changed, 57 insertions(+), 39 deletions(-) diff --git a/HANDOFF.md b/HANDOFF.md index bc2473c..156496e 100644 --- a/HANDOFF.md +++ b/HANDOFF.md @@ -8,37 +8,30 @@ 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"). +**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 14 change (commit target):** `WebView2Manager.TransparentBackgroundScript` is now a -pre-parse `