diff --git a/MainWindow.xaml b/MainWindow.xaml index 4c25257..b847181 100644 --- a/MainWindow.xaml +++ b/MainWindow.xaml @@ -45,24 +45,10 @@ - - - - + diff --git a/MyMistakes.md b/MyMistakes.md index 0d6a81c..5c11844 100644 --- a/MyMistakes.md +++ b/MyMistakes.md @@ -89,3 +89,38 @@ paths to `\\wsl.localhost\Debian\…` and throws "not a valid application for th OS" when handed a Linux ELF ffmpeg. So never plan to have dotnet exec a Linux ffmpeg here; verify the contract with shell/python instead, and leave the CLR→real-ffmpeg run to the native Windows suite. + +## WPF hit-test truth in tests: `UIElement.InputHitTest`, NOT `VisualTreeHelper.HitTest` + +(2026-09-01, the RoundClip "known failure" post-mortem — a failure the map carried as +"not a regression" for weeks without ever recording WHY.) + +**The trap:** `VisualTreeHelper.HitTest(window, pt)` returned the window's +`WebViewHostPanel` overlay (`IsHitTestVisible="False"`, `Opacity=0`, ZERO children) for +EVERY point in the window — so a "corner is grabbable" assertion could never pass, and +it looked like a real interaction bug. The actual input pipeline (`UIElement.InputHitTest`, +what Mouse routing uses) correctly returned the element's Grid at elem-center/corner-in/ +corner-exact and fell through to CanvasGrid just past the corner. The product was fine; +the TEST was probing an API that doesn't model input semantics. + +**Rule:** any test asserting "where does a click land" uses `window.InputHitTest(pt)` + +`IsDescendantOf` — never `VisualTreeHelper.HitTest`. + +**Diagnosis recipe (how the lie was caught in ~3 probe cycles, no guessing):** add a TEMP +probe `[Fact]` in the RealApp collection that hit-tests a spread of points +(elem-center / corner-in / corner-exact / corner-out / bg-center) and `Assert.Fail`s with a +composed dump: per-point VTH hit + `InputHitTest` hit + ancestor chain (`GetParent` walk +with `#Name`) + panel properties (`IsHitTestVisible/Opacity/children/actual size`) + +`TranslatePoint` origins. Run the class alone, read the message, delete the probe. + +**Two sibling facts learned the same session (record-once):** +1. A UserControl owns its own XAML namescope — after extracting a region out of a window, + `window.FindName("InnerPart")` returns null; resolve the UserControl by its window-level + name, then `pane.FindName("InnerPart")`. And window-scope STYLES are invisible to a + UserControl's `StaticResource` at parse time — move such styles to `Themes/Controls.xaml` + (the app-scope rule exists for this). +2. Per-class `dotnet.exe vstest` from WSL DOES execute the RealApp/`MainWindow` tests fine + (they passed natively 2026-09-01) — only the FULL suite hangs (WASAPI startup). And the + test process shares `%APPDATA%\ytLlive\startup.log` with the real app: lines like + `camera 'test-camera' failed` are test noise, not DB state — to check pollution, query + the DB directly (`python3 sqlite3`, `SELECT DeviceId FROM Webcam`), not the log. diff --git a/TASKS.md b/TASKS.md index a2d8537..9ab2605 100644 --- a/TASKS.md +++ b/TASKS.md @@ -1311,8 +1311,16 @@ What landed — core optimization + SceneGraph component, all in one commit: **Verification:** SceneCompositorTests 4, StretchMathTests 4, BackgroundTests 16, SceneCatalogTests 18, LayoutStorePersistenceTests 12, FramePumpTests 9, SceneGraphTests 1 all green. RealAppHost GUI/collection -tests (SourceNaming, RoundClip, BackgroundHeal, ...) construct a real `MainWindow` and cannot run in a -headless WSL session (pre-existing limitation, not caused by this change). +tests (SourceNaming, RoundClip, BackgroundHeal, ...) construct a real `MainWindow` — **CORRECTED +2026-09-01:** they DO run from WSL when invoked per-class through the Windows `dotnet.exe` vstest host +(the old "cannot run headless" claim conflated them with the full-suite WASAPI hang). Two first-launch +crashes this refactor shipped with were caught on the first real native launch and fixed same day: +ctor-order `SceneGraph` NRE (`null!` field assigned after first ctor use — now field-initialized) and +window-scope `EyeButton`/`EyeIconStyle` consumed via `StaticResource` from the extracted `LeftPanel` +(UserControl namescopes can't see window resources — styles moved to `Themes/Controls.xaml`, the +app-scope rule honored). The RoundClip "known failure" was then root-caused to stale test code +(`window.FindName` across namescopes + `VisualTreeHelper.HitTest` where `UIElement.InputHitTest` +models input) — test green 2026-09-01, the sole remaining known failure is the audio one. ### Design diff --git a/Themes/Controls.xaml b/Themes/Controls.xaml index 6db611c..6f35c14 100644 --- a/Themes/Controls.xaml +++ b/Themes/Controls.xaml @@ -66,6 +66,29 @@ + + + + + +