1a39b091a0
The widget page paints html/body opaque, so CapturePreviewAsync output had
zero alpha-0 margins — every take since bccdb48 built the crop on 'the
capture is transparent' and never verified it. WebView2 spec is explicit:
'WebView will always honor a webpage's background content' and
DefaultBackgroundColor only shows through pages with no background style
(MicrosoftEdge/WebView2Feedback specs/BackgroundColor.md). The late
ExecuteScriptAsync injection (NavStarting/NavCompleted) ran after page CSS
and lost the fight.
Fix via CoreWebView2.AddScriptToExecuteOnDocumentCreatedAsync — the
documented pre-parse hook ('before the HTML document has been parsed and
before any other script included by the HTML document is run'), the same
mechanism OBS user.css uses. Nav handlers kept as post-load re-assertion.
Restores the take-23/24 stride-correct crop path (my take-25 removal was
wrong — it regressed the bounding box into a solid black box).
Adds one-shot diagnostics: raw capture PNG -> %TEMP%/ytLive-web-<id>.png
plus alpha min/max/mean/%zero and FindContentBounds result in startup.log,
so the next run proves the capture is transparent instead of guessing.
Build 0 warnings, 289/289 tests pass. MyMistakes.md records the full chain.
46 lines
2.4 KiB
Markdown
46 lines
2.4 KiB
Markdown
# HANDOFF — 2026-09-08
|
|
|
|
## Branch / Commit State
|
|
|
|
**`main` HEAD = `081e4c1`** — take-24 (PasteKey CropBounds). Working tree carries the
|
|
real fix (uncommitted): pre-parse transparency injection + diagnostics.
|
|
|
|
## Web Overlay — the ROOT CAUSE (finally named, not guessed)
|
|
|
|
WebView2's `CapturePreviewAsync` **always honors the page's own background** — the widget
|
|
page paints html/body opaque, so the captured PNG has **no alpha-0 margins, ever**.
|
|
`DefaultBackgroundColor=Transparent` only shows through pages without a background style.
|
|
All prior takes (19-24) assumed the capture had transparent margins — it never did.
|
|
`FindContentBounds` therefore had nothing to crop to, and every blend saw alpha=255 =
|
|
black box + "transparency broken" + lost resizing. One bug, three symptoms.
|
|
|
|
**Fix applied (verify by running):**
|
|
1. `WebView2Manager.InitializeAsync`: `AddScriptToExecuteOnDocumentCreatedAsync(TransparentBackgroundScript)`
|
|
— injects html/body `background:transparent` BEFORE the page parses/scripts run (the
|
|
OBS user.css equivalent). NavStarting/NavCompleted keep the script as post-load re-assert.
|
|
2. Restored the take-23/24 compositor crop path (stride-correct `BlitContentRaw` +
|
|
`CropBounds` in PasteKey) — my previous take-25 gutting was wrong.
|
|
3. Diagnostics: first capture per source dumps the RAW WebView2 PNG to
|
|
`%TEMP%\ytLive-web-<id>.png` and logs alpha stats + FindContentBounds result to
|
|
startup.log.
|
|
|
|
## NEXT STEP (user run required once)
|
|
|
|
Run the app with the web overlay, then:
|
|
- Read `%APPDATA%\ytLlive\startup.log` — the `alpha[min=..,max=..,mean=..,zero=..%]`
|
|
line PROVES whether the capture is transparent now (mean near 0 + high zero% + a tight
|
|
contentBounds = fixed) or still opaque (mean ~255 → injection didn't beat the page).
|
|
- Agent can PIL-analyze `%TEMP%\ytLive-web-<id>.png` for the true alpha bbox.
|
|
|
|
## Still Open
|
|
|
|
- Chat overlay missing from recording (separate issue — not yet touched this session)
|
|
- Audio/sync: non-event (headset volume), closed
|
|
|
|
## Landmines
|
|
|
|
- testhost shares startup.log with app — filter by time when triaging
|
|
- testhost/exe lock DLLs: `taskkill /F /IM testhost.exe /IM ytLive.exe` before rebuild
|
|
- Do NOT run full-suite vstest (WASAPI hang); flow = clean build + per-class + scope-check
|
|
- Kill app before build: `/mnt/c/Windows/System32/taskkill.exe /F /IM ytLive.exe`
|
|
- The PNG dump is written ONCE per session per source (DebugPngWritten flag) |