[bug/windows]: specific-window screenshots fail for WebView2-hosted apps

[oshtz]

Description

On Windows 11, taking a screenshot of a WebView2-hosted desktop app as a specific window does not create a screenshot or open the screenshot editor. Capturing the containing display succeeds and creates the expected screenshot project.

This appears specific to Cap's Windows window-target selection rather than display capture.

Expected behavior: WebView2-hosted apps can be selected and captured like other windows.

Actual behavior: the window capture produces no screenshot project, while display capture works.

Reproduction

1. Open a WebView2-hosted desktop app on Windows.
2. Open Cap's screenshot target picker and choose Window, or use the Screenshot current window hotkey with the cursor over that app.
3. Select the app and attempt the screenshot.
4. Observe that no window screenshot is saved or opened.
5. Capture the full display and observe that it succeeds.

Investigation

Both picker and hotkey selection route through scap_targets::Window::get_topmost_at_cursor.

On Windows, that path starts from WindowFromPoint and rejects executable names containing webview2 or msedgewebview2. A WebView2 child or top-level HWND can therefore be rejected before a capture target is produced. The fix should preserve Cap's self-window exclusion while allowing unrelated WebView2-hosted apps.

The screenshot store contains the successful display capture but no corresponding window project. No Windows Cap log directory was present for additional error output.

Additional Context

• Cap version: current main at d0491b1e59d6ffe4386524ba67047d039e46d58e
• Operating system, version: Windows 11
• Reproducible target: WebView2-hosted desktop application

Acceptance criteria

• WebView2-hosted apps can be selected and captured through the picker.
• The Screenshot current window hotkey works with the cursor over a WebView2-hosted app.
• Cap's own windows and overlays remain excluded.
• Ordinary Win32 window capture and full-display capture remain unchanged.

[linear]

CAP-767

[tembo]

The analysis in the issue is spot-on. The relevant code is in crates/scap-targets/src/platform/win.rs.

There are two places where WebView2 windows get filtered out:

1. Static exclusion list (lines 62-68) used in is_window_valid_for_enumeration:

static IGNORED_EXES: &[&str] = &[
    "webview2",
    "msedgewebview2",
    "cap",
];

2. Dynamic check in is_window_valid_for_topmost_selection (lines 1238-1245) with a substring match:

let exe_name_lower = exe_name.to_lowercase();
if exe_name_lower.contains("webview2")
    || exe_name_lower.contains("msedgewebview2")
    || exe_name_lower.contains("cap")
{
    return false;
}

The issue is that both checks reject any process whose executable name contains these substrings, rather than only rejecting Cap's own WebView2 child processes. A WebView2-hosted app like Milim runs msedgewebview2.exe as its renderer process, so it gets incorrectly rejected.

For the fix, you'll likely want to check that the WebView2 process is parented by Cap's process before excluding it, or compare against Cap's specific process ID rather than using executable name matching. The current_process_id is already available in both functions - you could walk the WebView2 process's parent chain to see if it traces back to Cap.

This is related to #1737 which tracks the broader issue of window exclusion being macOS-only - that issue notes that resolve_window_ids in window_exclusion.rs is #[cfg(target_os = "macos")] only, and the exclusion list in general_settings::default_excluded_windows() isn't wired up for Windows capture yet.