0f72c53aa5
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.
52 lines
2.9 KiB
Markdown
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). |