assert_not_occluded abstains on WebView2/high-DPI — needs DPI-correct hit-test or CDP z-order

[CameronCrow]

Finding (from the 2026-07-23 LLT vision dogfood)

vision.assert_not_occluded (and therefore assert_visible) abstains on the real LLT Import UI (WebView2 / Chromium, high-DPI) rather than deciding occlusion. Two reasons, both real:

1. touchpoint.element_at is coordinate/DPI-unreliable on WebView2. Hit-testing the button's centre (447, 679) returned a role=group element from a different Chromium process whose bounds (959, 606, 1152, 637) do not even contain the queried point. A trustworthy hit-test returns the element at the point; this doesn't. assert_not_occluded now detects "hit rect doesn't contain the point" and abstains (trust guard).
2. Wrapper ambiguity. When the hit does land on the point, it's often an owned/same-process DOM wrapper that encloses the button — indistinguishable by geometry from a real same-window overlay, and element IDs churn across touchpoint reads so we can't chain ancestry. → abstain.

What DOES work reliably today: a foreign-process window painted over the element (an OS dialog, another app) → hard fail. That's the unambiguous, high-value case and it's kept.

What robust occlusion needs

• DPI-correct hit-testing: reconcile the coordinate space touchpoint reports element rects in vs. what element_at expects (physical vs logical pixels). May be an upstream touchpoint issue.
• DOM z-order via CDP (overlaps robustness: React/div-soup apps expose thin a11y trees — make verification robust to them #37): for same-window web overlays, a CDP query (elementsFromPoint / z-index / checkVisibility()) decides "is our node actually the top paint at this point" far more reliably than a native hit-test. This is the real fix for WebView2/Electron/Chromium.

Acceptance

• On a WebView2 app with a known DOM overlay over a button, assert_not_occluded FAILS (not abstains); with no overlay it PASSES (not abstains).
• Never false-passes an actually-covered element.

Non-web/native occlusion already works; this is specifically the embedded-web + high-DPI gap. Discovered by assert_not_occluded abstaining honestly rather than lying — the safety property holding.

[CameronCrow]

Investigation (2026-07-23) — live spike against LLT (WebView2)

Tried every avenue to get a reliable occlusion verdict on WebView2/high-DPI. All four are blocked by touchpoint's current API. Evidence from a live spike (LLT Import UI, launched with WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--remote-debugging-port=9222):

1. touchpoint.element_at(x,y) — broken on WebView2. It routes to CDP only when _topmost_pid_at(x,y) is in cdp.get_owned_pids(). WebView2 is multi-process: the pixel-owning/compositor PID (e.g. 176004, 188136) ≠ the CDP browser PID (cdp.get_owned_pids() == {185196}). So it falls back to the UIA backend, which returns an element whose rect doesn't even contain the queried point (rect=(802,614,1224,801) for a point at (499,733)) — a coordinate/DPI mismatch.

2. cdp.get_element_at(x,y) — coordinate-correct but too coarse. Called directly it returns a CDP element that does contain the point (good), but it's an enclosing container (:14, rect 300x801), not the leaf button (:57). IS_BUTTON=False. Can't tell a benign wrapper from a real overlay from this alone.

3. DOM ancestry — not available. To classify the container hit as "the button's own ancestor" (benign) vs "an unrelated overlay", I need the DOM hierarchy. cdp.get_dom_elements() returns a flattened list: both parent_id (flat call) and reconstructing from children (tree=True) give the button and the container as depth-1 roots with no linking parent among the 33 returned nodes. Ancestry is unknowable.

4. _topmost_pid_at (WindowFromPoint) — unreliable to fail on. It's DPI-robust for native cross-process occlusion, but WebView2's shared-runtime helper processes are not always descendants of the launched PID, so an owned webview's own pixels can report an "unowned" topmost PID → risk of false-fail on our own content. Not safe to hard-fail on for web targets.

Conclusion

Reliable DOM-level occlusion on WebView2/Chromium is not achievable with touchpoint's current API. The safe behavior — assert_not_occluded abstains (never false-passes, never false-fails) — is correct and stays. Shipping any of the above heuristics would risk a false verdict, which the phase's safety rule forbids.

The real fix needs an upstream touchpoint capability: either JS document.elementFromPoint(x,y) + Element.contains() executed in the page (a leaf-accurate, DPI-native DOM z-order hit-test), or fixing element_at's CDP routing to handle WebView2's multi-process compositor. → upstream feature request.

Byproduct (useful)

The spike confirmed WindowHandle.read_dom_text (#37) works live — returned 'Assemble import set' from the real DOM once the app was launched with remote debugging. It also showed the shape of a CDP-enabled session: a second CDP page-target window (app='msedgewebview2', cdp: window id) appears alongside the native host, and DOM ops must run on that window. Making app_session launch Chromium/WebView2 targets with remote debugging (and resolve the CDP window) is the concrete next step that unlocks live DOM reads — the actual React-robustness win — and is a prerequisite for any future CDP occlusion.

Status: blocked on upstream touchpoint support; current abstain validated as correct.