DevFlow: Element discovery via AutomationId unreliable on WinUI

[jongalloway]

Feedback from DevFlow MCP Testing

Summary

Elements with AutomationId set in XAML are not always found by maui_query or targetable by maui_tap on WinUI. Works more consistently on Android. This makes test automation scripts fragile on Windows (the primary dev platform).

Reproduction Steps

1. Define XAML with AutomationId:

<Button AutomationId="StartWorkoutButton" Text="Start" />
<Switch AutomationId="SimulatedSensorToggle" IsToggled="{Binding UseSimulatedSensor}" />

2. On Windows, run:
   maui_query(automationId: "StartWorkoutButton")

3. Observe: Sometimes returns no results even though the element is visible on screen

Expected Behavior

• AutomationId should be a reliable way to find elements cross-platform
• maui_query(automationId: "X") should consistently find matching elements
• maui_tap with IDs from maui_tree should reliably trigger the tap

Actual Behavior

• On WinUI: Intermittent failures finding elements by AutomationId
• On Android: Works consistently
• Tap events sometimes don't register

Impact

Test automation scripts are fragile on Windows (the main dev platform for .NET MAUI). Every test script needs fallbacks and retry logic.

Current Workaround

• Use maui_tap with coordinates calculated from maui_tree bounds (brittle, breaks on layout changes)
• Use text-based button discovery when available (text-dependent, doesn't work for icons)
• Retry loops and timeouts

Environment

• Platform: Windows 11, .NET 10 Preview
• DevFlow MCP: Latest
• App: .NET MAUI 10