Describe the bug
winapp ui get-property does not read the UI Automation IsPassword property. It derives the value as:
IsContentElement && ControlType == Edit
As a result, ordinary editable controls are reported as password fields. This makes the command's factual UIA output incorrect and prevents the value from being safely reused for future password redaction: applying the current value would redact every normal text box.
The authoritative source is UIA_IsPasswordPropertyId (30019), exposed by the UIA provider.
The current implementation is in UiAutomationService.GetPropertiesAsync.
To Reproduce
-
Open Windows Settings.
-
Identify the ordinary Settings search box with winapp ui inspect or ui search.
-
Run:
winapp ui get-property CommandSearchTextBox -w <settings-hwnd> --property IsPassword --json
-
Observe that WinApp reports:
{ "properties": { "IsPassword": "True" } }
The same behavior applies to other normal UIA Edit controls that are content elements.
This was reproduced live on the Settings search box. A separate WinForms probe confirmed that UIA_IsPasswordPropertyId returns false for a normal text box and true only for a genuine password box.
Expected behavior
IsPassword is read from UIA_IsPasswordPropertyId rather than inferred from control type.
- Ordinary text/search inputs report
false.
- Genuine password controls report
true.
- Password values are never exposed if this property is used for value redaction.
- Provider errors or unsupported values are not converted into a guessed password classification.
- Tests cover an ordinary Edit control and a real password control.
A real password-value leak was not reproduced: the tested password control's UIA ValuePattern returned Access denied. The confirmed current defect is incorrect classification; reliable redaction should be added with the authoritative property fix.
Screenshots
N/A — the incorrect value is directly observable in command output.
OS Version and details
Windows 11 ARM64; reproduced 2026-07-28 against Windows Settings and a controlled WinForms UIA probe.
Describe the bug
winapp ui get-propertydoes not read the UI AutomationIsPasswordproperty. It derives the value as:As a result, ordinary editable controls are reported as password fields. This makes the command's factual UIA output incorrect and prevents the value from being safely reused for future password redaction: applying the current value would redact every normal text box.
The authoritative source is
UIA_IsPasswordPropertyId(30019), exposed by the UIA provider.The current implementation is in
UiAutomationService.GetPropertiesAsync.To Reproduce
Open Windows Settings.
Identify the ordinary Settings search box with
winapp ui inspectorui search.Run:
Observe that WinApp reports:
{ "properties": { "IsPassword": "True" } }The same behavior applies to other normal UIA Edit controls that are content elements.
This was reproduced live on the Settings search box. A separate WinForms probe confirmed that
UIA_IsPasswordPropertyIdreturnsfalsefor a normal text box andtrueonly for a genuine password box.Expected behavior
IsPasswordis read fromUIA_IsPasswordPropertyIdrather than inferred from control type.false.true.A real password-value leak was not reproduced: the tested password control's UIA ValuePattern returned
Access denied. The confirmed current defect is incorrect classification; reliable redaction should be added with the authoritative property fix.Screenshots
N/A — the incorrect value is directly observable in command output.
OS Version and details
Windows 11 ARM64; reproduced 2026-07-28 against Windows Settings and a controlled WinForms UIA probe.