Files
LlamaCasty/HANDOFF.md
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

59 lines
3.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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)
1. User REPLACES the app (build is current) and records the Live scene, widget animating,
like the 12:54/13:50 takes.
2. 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.
3. 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).