Files
LlamaCasty/HANDOFF.md
T
gramps 0f72c53aa5 fix(web): wipe background-image too — the widget's black void is a CSS backdrop gradient, not a color
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.
2026-09-10 15:42:26 -07:00

52 lines
2.9 KiB
Markdown

# 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):**
- `TransparentBackgroundScript` now also wipes `background-image:none!important` on
`html,body,html *` (gradients/backdrops die; `<img>`/DOM art survives — OBS semantics).
- `NavigateCompleted` re-arms `WidgetDumpRemaining = 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!important` present, weak inline form absent).
## THE ONE REMAINING STEP (verify, no further analysis)
1. User records the Live scene, widget animating (pre-record ~35s so the 30s re-arm dump
fires mid-take).
2. 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.
3. Then the queued layer-order-save bug (reorder doesn't persist `SortOrder`) is next.
## 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).