[Zach Teutsch (zateutsch)]

What and why

DevTools shows where each property value came from: XAML, default, style, and so on. It got this wrong in three ways, so you couldn't trust it to show what the developer actually set.

• Properties nobody set showed as [Local]. Windows App SDK writes a starting value for CenterPoint, RasterizationScale, Rotation, RotationAxis, Scale, TransformMatrix and Translation on every element. DevTools listed them as "set on this element". Now a starting value that matches the unset value reads as Default, and the Set view no longer lists it.
• "Derived from" pointed at XAML lines that don't set the value. A local value now keeps its XAML line only when that tag sets the property (x:Name counts for Name). A value set by a live edit is labelled DevTools, and the window tooltip says so. If the app later writes its own value, the property reads as Local again.
• get-property described a binding that a live edit had already replaced. Now it describes the current value. Restoring the binding from the inspector or over the protocol clears the live-edit label.

Fixes #1140

Before / after

Not captured from a running app. These use the repro steps from the issue; the "after" lines are what the new tests check, not observed output.

Before

> winapp devtools get-property CounterText -a <pid>
CenterPoint, RasterizationScale, Rotation, RotationAxis, Scale, TransformMatrix, Translation  -> [Local]

> winapp devtools set-property CounterButton Width 210 -a <pid>
> winapp devtools get-property CounterButton Width -a <pid>
Local 210  MainWindow.xaml:46      # line 46 has no Width attribute

After (expected)

CenterPoint ... Translation  -> Default, and not listed under "Authored on this element"
CounterButton Width  -> DevTools 210, with no XAML line

Not tested / risks

• Not checked by hand in a running WinUI app. Native unit tests and the native dispatcher tests (467/467) pass on an ARM64 build. The x64 build only compiles them, so they don't run there.
• Values set with property-element syntax (<TextBlock.Text>) or as element content lose their XAML line when DevTools can read the XAML file. Keeping them would mean parsing the element body.
• If code-behind sets one of the starting-value properties back to its unset value, that property reads as Default.

Checklist

• Tests added or updated
• Tested locally on Windows
• Docs, samples, and plugins/winapp/skills/ updated if user-facing behavior changed

Notes for reviewers

DevTools records the value each live edit writes. The DevTools label applies only while the property still holds that value, so a later write by the app isn't credited to DevTools. A starting-value property counts as unset only when it equals its unset value, such as an identity matrix. Any other value still reads as Local.

[Copilot]

🟡 Changes recommended

Failed binding restores and later app writes can still produce incorrect value-source labels.

3 open issues

• Discard stale live edits after app overwrite · New
• Preserve live-edit attribution when binding restore fails · New
• Compare readable values for empty property-chain text · New

What changed in this PR

This PR addresses #1140 by improving how DevTools explains property values in the inspector and CLI.

Changes:

• Classifies runtime starting values as Default rather than Local.
• Labels live edits as DevTools and limits XAML source lines to tags that set the property.
• Adds regression tests and documents the live-edit value source.

File	Description
src/​winapp-devtools/​test/​read-tests.cpp	Tests origin labels and unset-value detection.
src/​winapp-devtools/​test/​native-runtime-tests.cpp	Tests XAML locations and live-edit attribution.
src/​winapp-devtools/​test/​bindingrow-tests.cpp	Tests recorded live-edit values.
src/​winapp-devtools/​native/​WinApp.DevTools.Native/​DevToolsWindow.State.inc	Includes live edits in the Set view.
src/​winapp-devtools/​native/​WinApp.DevTools.Native/​DevToolsWindow.PropsLayout.inc	Adds a live-edit source tooltip.
src/​winapp-devtools/​native/​WinApp.DevTools.Native/​DevToolsWindow.PaneSinks.inc	Clears live-edit tracking after successful undo.
src/​winapp-devtools/​native/​WinApp.DevTools.Native/​DevToolsTap.UiDispatch.inc	Records written values and clears tracking after property clears.
src/​winapp-devtools/​native/​WinApp.DevTools.Native/​DevToolsTap.PropertyRead.inc	Adjusts value sources and XAML locations.
src/​winapp-devtools/​native/​WinApp.DevTools.Native/​DevToolsTap.ElementCommands.inc	Adds tracking cleanup for binding operations.
src/​winapp-devtools/​native/​WinApp.DevTools.Native/​DevToolsRead.h	Declares the live-edit label and unset-value helper.
src/​winapp-devtools/​native/​WinApp.DevTools.Native/​DevToolsRead.cpp	Implements unset-value detection and label precedence.
src/​winapp-devtools/​native/​WinApp.DevTools.Native/​DevToolsBindingRow.h	Declares value-aware live-edit tracking.
src/​winapp-devtools/​native/​WinApp.DevTools.Native/​DevToolsBindingRow.cpp	Stores and compares live-edit snapshots.
docs/​guides/​devtools-advanced.md	Documents the DevTools value source.

_{Review effort: Balanced}

[github-actions]

Build Metrics Report

Validation passed. All required build and validation jobs succeeded.

Binary Sizes

Artifact	Baseline	Current	Delta
CLI (ARM64)	65.05 MB	65.08 MB	📈 +29.0 KB (+0.04%)
CLI (x64)	64.97 MB	65.00 MB	📈 +25.5 KB (+0.04%)
MSIX (ARM64)	26.93 MB	26.94 MB	📈 +12.0 KB (+0.04%)
MSIX (x64)	28.55 MB	28.57 MB	📈 +16.2 KB (+0.06%)
NPM Package	56.12 MB	56.14 MB	📈 +22.7 KB (+0.04%)
NuGet Package	56.27 MB	56.29 MB	📈 +21.8 KB (+0.04%)

.NET Test Results (TRX reports)

Other suites are reflected in the overall validation status above.

✅ 10669 passed, 43 skipped out of 10712 tests in 1922.2s (+5 tests, -662.1s vs. baseline)

Test Coverage

✅ 87.4% line coverage, 81.5% branch coverage · ✅ no change vs. baseline

CLI Startup Time

72ms median (x64, winapp --version) · ⚠️ +12ms vs. baseline

Try This Build

Installs the MSIX for your architecture, replacing any previously installed build. Needs the GitHub CLI — the command offers to install it and sign you in if it is missing.

& ([scriptblock]::Create((irm https://raw.githubusercontent.com/microsoft/winappCli/main/scripts/winapp-pr.ps1))) 1160

Switching between builds often?

Put the tool on your PATH once:

& ([scriptblock]::Create((irm https://raw.githubusercontent.com/microsoft/winappCli/main/scripts/winapp-pr.ps1))) -AddToPath

Then this build is just:

winapp-pr 1160

Run winapp-pr with no arguments to pick from a list of open PRs.

---

Updated 2026-10-23 00:15:54 UTC · commit d1e9e06 · workflow run

[Jaylyn Barbee (Jaylyn-Barbee)]

🤖 AI-generated review (winappcli pr-review skill) — verify before acting.

PR Review — zateutsch-devtools-value-source-validation vs main

Decision

merge — No blocking problems found. The native build passes, and both the unit tests and the dispatcher tests pass on a real ARM64 run. The two items below are optional.

Must fix

None. You can merge this as it is.

Non-blocking

Properties set in the element's body lose their XAML line

• What is wrong: A Local value now keeps its file and line only if the element's opening tag has an attribute for that property. Properties set inside the element's body are missed. That covers property-element syntax (<Button.Background>…) and content (<Button>Save</Button>). Their source position is dropped even though it was correct before this change.
• Show me: <Button x:Name="Go"><Button.Background><SolidColorBrush Color="Red"/></Button.Background></Button> on line 40, then winapp devtools get-property Go Background. On main, the Local chain entry has "file":"ms-appx:///MainWindow.xaml","line":40. On this branch, the same entry has no file and no line.
• Why it matters: Brushes and other object values are often written this way. For them, users lose the link from the value to its XAML line. The PR description lists this as a known risk.
• Smallest fix: Drop the position only when the opening tag can't have a body (it ends in />), or when the body has no <Type.Property> child for this property. Otherwise keep the line as main does. Live edits and unset starting values already drop the line through their own checks.
• Location: src/winapp-devtools/native/WinApp.DevTools.Native/DevToolsTap.PropertyRead.inc:615-622, 684-698

The docs list only two of the ways the DevTools label goes away

• What is wrong: The docs say valueSource stays DevTools "until you clear or undo it." The code also drops the label when the app writes a different value, and when a binding restore succeeds.
• Show me: set-property <TextBlock> Text Hi returns "valueSource":"DevTools". Then the app sets Text = "Count: 1", and get-property returns Local. Nothing was cleared or undone, but the label changed.
• Why it matters: Scripts and agents use this field to tell their own live edits apart from values the app set. The current sentence leads them to misread a Local result.
• Smallest fix: "…until you clear, undo or restore it, or the app sets that property itself."
• Location: docs/guides/devtools-advanced.md:157-158

What was exercised

• scripts\test-native-units.ps1 built and passed all native unit tests. These include the new bindingrow-tests and read-tests cases.
• build-devtools.ps1 -Configuration Release -Arch x64 compiled the engine and tests, and the gates passed. The x64 tests don't run on this ARM64 machine.
• build-devtools.ps1 -Configuration Release -Arch arm64 passed all 468 native dispatcher checks and all 97 native window checks. These include the new value-source and live-edit checks.
• Code checks found no problems:
  • All code that reads or changes the list of live edits runs on the UI thread.
  • Restoring a binding from the DevTools window still goes through the protocol path, so it still clears the live-edit label.
  • The read taken right after an edit records the value the same way later reads do, so the label doesn't drop on the next read by mistake.
  • The new DevTools value doesn't break a published contract, because DevTools isn't in v0.7.1.
• Not exercised: a live WinUI app with real WinAppSDK starting values and repeated reads of object-valued properties such as brushes. No sample app was available. The tests use fake values, so the main remaining gap is behavior against the real runtime.

[Jaylyn Barbee (Jaylyn-Barbee)]

LGTM pending your review of the option items

[Zach Teutsch (zateutsch)]

Fixed both in d1e9e06: values set by a <Type.Property> child or as content keep their XAML line again (dropped only for a self-closing tag or a body that sets other properties), and the docs now list every way the DevTools label goes away.