Dioxus macOS desktop launch can run headless or without AX windows outside GUI launch path

[dirvine]

Summary

During studio/macOS UI testing, the Dioxus desktop bundle could run as a process while exposing no visible/controllable app window when launched from SSH/System Events. Launching from the studio GUI Terminal produced a visible window, but the process still reports zero accessibility windows, which blocks reliable Computer Use/AX automation.

Environment

• Studio host: studio1@studio1.local
• Patched bundle: /Users/studio1/Applications/CommunitasDioxus-Patched.app
• Executable: Contents/MacOS/communitas-dioxus
• Bundle id: com.maidsafe.communitas
• x0x studio daemon: 0.21.2, healthy

Evidence

Initial running process was stale/non-patched:
/Users/studio1/Applications/Communitas-Dioxus-0.12.4.app/Contents/MacOS/communitas-dioxus

After stopping it and opening the patched bundle via SSH/Finder/System Events, the patched process ran but had no AX windows:
frontmost=false, visible=true, window_count=0

WindowServer/LaunchServices logged foreground denial for SSH-origin launch:
Application ... tried to be brought forward, but isn't in fPermittedFrontApps, so denying.

Launching the patched app from the studio GUI Terminal did create a visible connected Dioxus window. However, querying AX still returns:
frontmost=true, visible=true, window_count=0

Actual

• App process can run with no visible window when launched from non-GUI session.
• Visible Dioxus window exposes zero accessibility windows/elements.
• Screen Sharing/Computer Use can visually inspect it but cannot reliably focus/type into the WebView input.
• Two installed bundles share com.maidsafe.communitas, making it easy to accidentally test the stale bundle.

Expected

• A desktop launch should create/restore a visible window in the active GUI session.
• The Dioxus WebView/window should expose enough accessibility surface for automation and accessibility users.
• Test/release bundle identity should avoid stale-bundle ambiguity during side-by-side validation.

[dirvine]

Latest local/studio retest on 2026-06-06 after patching and redeploying Dioxus:

Code/build changes now tested locally:

• Release workflows delete generated LSRequiresCarbon after dx bundle and fail if no app bundle exists.
• Local dx bundle --macos --release --package-types macos still generated LSRequiresCarbon=true; I removed it manually from the test bundle before signing/deploying.
• Added explicit Dioxus desktop window config and a macOS startup hook that sets NSWindow sharing/visibility after the WebView window exists.
• Required Rust gates passed after the Dioxus patch: cargo fmt --all, strict cargo clippy --all-features --all-targets -- -D warnings -D clippy::panic -D clippy::unwrap_used -D clippy::expect_used, and cargo check --workspace --all-targets.

Studio evidence after redeploying /Users/studio1/Applications/CommunitasDioxus-Patched.app:

• codesign --verify --deep --strict --verbose=2 passes on the studio app.
• New Dioxus process launched: PID 44449.
• CoreGraphics reports a real onscreen Dioxus window: owner CommunitasDioxus, bounds { X = 360, Y = 70, Width = 1200, Height = 812 }.
• Screen Sharing still shows only the desktop wallpaper.
• System Events reports windows=0 for communitas-dioxus, but also reports windows=0 for Finder, Terminal, Safari, ghostty, etc., while CoreGraphics reports their windows as onscreen. So the current AX/window visibility evidence is session-wide, not Dioxus-specific.
• Remote screencapture -x /tmp/studio-screen.png fails with could not create image from display.

Current interpretation: the Carbon plist bug is addressed in workflows and in the deployed test bundle. Dioxus now creates an onscreen WindowServer window, but the current studio Screen Sharing/AX capture channel is unreliable for all apps, so I cannot yet verify Dioxus pixels or interact with the Dioxus UI through Screen Sharing. Keeping this issue open for the remaining GUI/capture/accessibility path.