The winget configuration files now provision Visual Studio 2026 (channel 18.Release), but .vsconfig still listed Visual Studio 2022-era component IDs that were renamed or removed in VS 2026. The VSComponents DSC resource silently skipped them, so the Windows 11 SDK (26100) and WindowsAppSDK C# support never installed, breaking the build (cppwinrt / WindowsAppSDK failures).
- Windows10SDK.22621/26100 -> Windows11SDK.22621/26100 (renamed in VS 2026)
- ComponentGroup.WindowsAppSDK.Cs -> WindowsAppSdkSupport.CSharp; added WindowsAppSdkSupport.Cpp
- Removed Windows10SDK.19041 (only a min-version floor) and Windows10SDK.20348 (unused, removed from VS 2026)
- readme: correct '22621' SDK label from Windows 10 to Windows 11
Fixes#48778
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Win+Q and Win+S were both labeled "Open search" in Shortcut Guide. On
Copilot+ PCs, Win+Q launches Click to Do — not Search — so the duplicate
label was misleading.
## Changes
- `+WindowsNT.Shell.en-US.yml`: Renamed Win+Q entry from `Open search` →
`Open Click to Do` with description `On Copilot+ PCs`; Win+S retains
`Open search`
## PR Checklist
- [ ] Closes: #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
The Windows key shortcuts manifest had two entries with identical names
(`Open search`) mapped to Win+Q and Win+S respectively. On Copilot+ PCs,
Win+Q opens Click to Do, not Search. The Win+Q entry is corrected to
`Open Click to Do` with a `On Copilot+ PCs` description to scope its
applicability.
## Validation Steps Performed
- Visually reviewed the YAML diff to confirm only the Win+Q entry name
and description changed; Win+S entry is unchanged.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
## Summary
Fixes#46693
- The `static bool isAltRightKeyInvoked` flag in
`HandleShortcutRemapEvent` is set when AltGr (RAlt+LCtrl) is pressed,
but only reset inside Case 1's else branch — which requires a shortcut
to be actively invoked (`isShortcutInvoked == true`)
- If the user presses and releases AltGr when **no shortcut is active**,
the flag stays `true` permanently across all future calls
- Once stale, the flag blocks modifier key restoration and state resets
at 13 locations throughout the function (lines 646, 670, 791, 800, 866,
880, 889, 907, 927, 978, 996), and causes LCtrl key-up events to `break`
out of the handler loop (line 620-622) instead of being properly
processed
- This makes LCtrl permanently stuck for any shortcut remap that uses
LCtrl as a modifier
## Fix
Reset `isAltRightKeyInvoked` when `VK_RMENU` (Right Alt) is released,
regardless of whether a shortcut is currently invoked. This is added as
an `else if` right after the existing flag-set condition.
## Test plan
- [ ] Configure a shortcut remap using LCtrl (e.g. LCtrl+Y → Backspace)
- [ ] Press and release AltGr without triggering any shortcut
- [ ] Use the LCtrl shortcut — verify Ctrl does not become stuck
- [ ] Verify AltGr-based shortcuts still work correctly
- [ ] Verify normal AltGr character input (e.g. AltGr+Q for @ on German
layout) is unaffected
---------
Co-authored-by: fluffyspace <fluffyspace@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary
Follow-up to #48409. That PR rewrote
`ShellViewModel.Frame_NavigationFailed` to set `e.Handled = true` and
log instead of re-throwing, but the unit tests it added only covered the
`GetPageDisplayName` formatting helper. The actual contract that matters
- "this handler must never throw, regardless of which fields on
`NavigationFailedEventArgs` happen to be null" - was not directly
testable because `NavigationFailedEventArgs` is a sealed WinRT type that
cannot be constructed from MSTest.
## Change
Tiny refactor: split the failure-handling logic out of
`Frame_NavigationFailed` into a pure static
`HandleNavigationFailure(Type sourcePageType, Exception exception)`. The
WinUI-shaped handler now just sets `Handled = true` and delegates.
This makes the "must not throw" invariant testable in isolation - no
WinUI Frame, no Microsoft.UI.Xaml.Navigation types needed.
## Tests
Added four new cases under `ShellViewModelTests`, exercising all four
`(SourcePageType, Exception)` null permutations:
| `sourcePageType` | `exception` |
| - | - |
| null | null |
| typeof(...) | null |
| null | new Exception(...) |
| typeof(...) | new Exception(...) |
Each test simply calls the helper and relies on MSTest's default "if it
throws, the test fails" behavior. Any future change that re-introduces
an unguarded dereference of `e.SourcePageType` or `e.Exception` will
turn the corresponding test red.
## Validation
All six tests pass:
```
Passed GetPageDisplayName_ReturnsFullName_ForKnownType
Passed GetPageDisplayName_ReturnsPlaceholder_ForNullType
Passed HandleNavigationFailure_DoesNotThrow_ForNullInputs
Passed HandleNavigationFailure_DoesNotThrow_ForNullException
Passed HandleNavigationFailure_DoesNotThrow_ForNullPageType
Passed HandleNavigationFailure_DoesNotThrow_ForBothInputsPresent
Total tests: 6, Passed: 6
```
`PowerToys.Settings.csproj` and `Settings.UI.UnitTests.csproj` both
build clean (Release|x64).
## Note
This PR is stacked on top of #48409 (same branch lineage). If #48409 is
merged first this PR will rebase cleanly to a small diff on
`ShellViewModel.cs` + the additional test cases.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
Adds a new "Show AI paste section" setting to Advanced Paste that allows
users to hide the AI paste input box from the Advanced Paste window.
This addresses user requests for a cleaner UI when the AI paste feature
is not needed or desired.
## PR Checklist
- [x] Closes: #32967
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
This PR implements a new boolean setting `ShowAIPaste` that controls the
visibility of the AI paste input box (PromptBox) in the Advanced Paste
window.
### Changes Made
**Settings UI Library:**
- `src/settings-ui/Settings.UI.Library/AdvancedPasteProperties.cs` -
Added `ShowAIPaste` property with JSON serialization
**Settings UI:**
- `src/settings-ui/Settings.UI/ViewModels/AdvancedPasteViewModel.cs` -
Added view model property with change notification
-
`src/settings-ui/Settings.UI/SettingsXAML/Views/AdvancedPastePage.xaml`
- Added checkbox setting in the UI Behavior section
- `src/settings-ui/Settings.UI/Strings/en-us/Resources.resw` - Added
localized strings for header and description
**Advanced Paste Module:**
- `src/modules/AdvancedPaste/AdvancedPaste/Helpers/IUserSettings.cs` -
Added interface property
- `src/modules/AdvancedPaste/AdvancedPaste/Helpers/UserSettings.cs` -
Implemented setting loading from properties
-
`src/modules/AdvancedPaste/AdvancedPaste/ViewModels/OptionsViewModel.cs`
- Added `ShowAIPasteSection` property combining user setting with GPO
policy
-
`src/modules/AdvancedPaste/AdvancedPaste/AdvancedPasteXAML/Pages/MainPage.xaml`
- Bound PromptBox visibility to new property
**Tests:**
-
`src/modules/AdvancedPaste/AdvancedPaste.UnitTests/Mocks/IntegrationTestUserSettings.cs`
- Added mock property
-
`src/modules/AdvancedPaste/UITest-AdvancedPaste/TestFiles/settings.json`
- Updated test settings file
### Behavior
- Default value is `true` (AI paste section visible) to maintain
backward compatibility
- The setting respects GPO policy - if AI is disabled by GPO, the
section will be hidden regardless of user preference
- Setting is persisted in the Advanced Paste settings JSON file
## Validation Steps Performed
- [x] Verified setting appears in Settings UI under Advanced Paste →
UI Behavior
- [x] Verified toggling the setting hides/shows the AI paste input box
in the Advanced Paste window
- [x] Verified setting persists after closing and reopening Settings
- [x] Verified default value is `true` (visible) for new installations
- [x] Verified existing unit tests pass with updated mock
Fixes#32967
---------
Co-authored-by: Niels Laute <niels.laute@live.nl>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This PR addresses issue #20618 by adding the inverted exclamation mark
(**¡**) to the **!** key (`VK_1`) and the inverted question mark (**¿**)
to the **?** key (`VK_SLASH_`) for both Spanish (`SP`) and Catalan
(`CA`) character mappings in Quick Accent.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #20618
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Adds the inverted punctuation marks `¡` (inverted exclamation mark) and
`¿` (inverted question mark) to the character mappings of Spanish (`SP`)
and Catalan (`CA`) languages in `CharacterMappings.cs`.
- `LetterKey.VK_1` (`!`) now maps to `¡`
- `LetterKey.VK_SLASH_` (`?`) now maps to `¿`
This enables quick accent popups when pressing these respective keys,
aligning with the expected behavior for these languages.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
1. Verified character mapping changes build successfully.
2. Verified that the PowerToys CI pipeline checks completed
successfully.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Add webp and jpg support for screenshots.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
## Summary
Harden Peek's `AppWindow.Closing` path so a stale cached preview-handler
factory can't fail-fast the Peek process. Also clean up the matching
path in RegistryPreview.
## Background
Spotted while reading through Peek's `MainWindow` teardown sequence and
the `ShellPreviewHandlerPreviewer` cache for an unrelated review of how
Peek manages out-of-process preview-handler lifetimes.
The Peek `MainWindow` subscribes to `AppWindow.Closing`. The handler
doesn't actually close the window — it sets `args.Cancel = true` and
calls `Uninitialize()`, which in turn calls
`ShellPreviewHandlerPreviewer.ReleaseHandlerFactories()`.
`ReleaseHandlerFactories()` looked like this:
```csharp
public static void ReleaseHandlerFactories()
{
foreach (var factory in HandlerFactories.Values)
{
try { Marshal.FinalReleaseComObject(factory); } catch { }
}
}
```
Two problems:
1. The static `HandlerFactories` dictionary is never cleared. After
`FinalReleaseComObject`, the entries still point at separated RCWs. A
subsequent activation that races with this cleanup (or a second close in
the same process) can pick up the dead RCW from the cache.
2. The cached factory had `LockServer(true)` called on it when it was
first cached, but the matching `LockServer(false)` was never paired.
Any managed exception that escapes a WinRT event callback is projected
back to CFlat as a failed HRESULT and the CsWinRT dispatcher fail-fasts
the process. So a single `InvalidComObjectException` (HRESULT
0x80131527) thrown out of `Uninitialize()` is enough to terminate Peek.
## Changes
* **`ShellPreviewHandlerPreviewer.ReleaseHandlerFactories`** — snapshot
then clear the dictionary up front so that a subsequent call (or a
concurrent `LoadPreviewAsync`) can't pick up a stale RCW. Call
`LockServer(false)` before `FinalReleaseComObject` to mirror the
cache-time `LockServer(true)`. Both COM calls remain individually
wrapped because the RCW may already be unreachable during process
teardown.
* **`Peek.UI/MainWindow.xaml.cs` — `AppWindow_Closing`** — wrap the body
in try/catch + `Logger.LogError`. Any future exception in
`Uninitialize()` (or its callees) will now log instead of fail-fasting
the process.
* **`RegistryPreview/MainWindow.Events.cs` — `AppWindow_Closing`** —
same defensive try/catch, plus null-guard `jsonWindowPlacement` before
`SetNamedValue`. The placement dictionary can legitimately be null on
first run or after a corrupt placement file; previously that would NRE →
fail-fast.
## Risk
Low. The `ReleaseHandlerFactories` change matches the documented
`LockServer`/`FinalReleaseComObject` pairing and only widens the
lifetime window of the cache by `Clear()`-ing earlier; nothing in Peek
calls this method outside of teardown. The two try/catch wrappers
strictly add defense — the success path is unchanged.
## Validation
Spot-built locally; this repo's `dotnet restore` runtime-pack issue
(unrelated to this PR — same NU1102 pattern that's affecting other open
PRs) prevents a full `Build.cmd` here. The C++ side of Peek is
untouched.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
ADO:
https://microsoft.visualstudio.com/DefaultCollection/OS/_workitems/edit/58765809/
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Boliang Zhang <122517415+LegendaryBlair@users.noreply.github.com>
## Summary
Fixes a class of "stuck drag" bugs in FancyZones where closing or
destroying a window **while it is being dragged** leaves FancyZones in a
half-dragging state — zone overlays stay on screen and subsequent
keystrokes (notably number keys) are swallowed or misrouted.
## What this changes
- **Subscribe to and dispatch `EVENT_OBJECT_DESTROY`.** `FancyZonesApp`
never subscribed to the destroy event, and the consumer's
`WM_PRIV_WINDOWDESTROYED` branch could therefore never fire. The event
is now registered and routed through `HandleWinHookEvent`.
- **Abort the drag (without snapping) when the dragged window is
destroyed.** On `WM_PRIV_WINDOWDESTROYED`, if the destroyed HWND is the
one being dragged, call the new `WindowMouseSnap::Abort()` (tears down
overlays/highlights/transparency) instead of `MoveSizeEnd()`, which
would try to snap the now-dead HWND and corrupt zone state. Dragging
state is then disabled.
- **Always clear dragging state in `MoveSizeEnd()`**, even when the
snapper was already null, so the state can't get stranded.
- **Require Win+Ctrl+Alt to switch layouts while dragging.** Previously
any digit switched layouts while `dragging` was true; if drag state was
stuck this "stole" number keys from the focused app. This is the
root-cause fix for the number-key-stealing symptom.
- **Only swallow the bare Shift key during a drag**, not `Shift+<other>`
combos, so real keystrokes are no longer eaten by an in-progress drag.
## Testing
- Builds Release x64 (FancyZones) clean against current `main`.
- Manually verified drag → close window mid-drag no longer leaves
overlays up or steals number keys. (FancyZones has no unit-test harness
for this path.)
This is one of a small set of related "stuck key / stuck state"
hardening fixes; each stands alone.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Muyuan Li <116717757+MuyuanMS@users.noreply.github.com>
## Summary
Hardens the runner's centralized keyboard hook against stuck and "ghost"
key activations — cases where a hotkey action fires after the key was
already released, or a pending timer fires after the hook was torn down.
## What this changes
- **`vkCodePressed` is now `std::atomic<DWORD>`.** It is read/written
from the low-level hook callback and from the timer/teardown paths; the
plain `DWORD` was a data race.
- **Revalidate the key is still physically held before firing a held-key
timer.** The pressed-key timer callback now checks
`GetAsyncKeyState(virtualKey) & 0x8000` before invoking the action,
preventing ghost activations after the user has let go.
- **Tag the injected dummy `0xFF` key-up** with
`CENTRALIZED_KEYBOARD_HOOK_DONT_TRIGGER_FLAG` so the hook does not
reprocess its own synthetic event.
- **`Stop()` kills all pending pressed-key timers and resets
`vkCodePressed` before unhooking**, so a timer can't fire a callback
into a half-removed hook.
## Testing
- Builds Release x64 (runner / `PowerToys.exe`) clean against current
`main`.
This is one of a small set of related "stuck key" hardening fixes; each
stands alone.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The ZoomIt module description contained `"snip screenshots"` — both
words map to the same Chinese term (截图), causing the translation system
to emit the garbled `"截图截图截图"` in the Chinese UI.
## Changes
- **`src/settings-ui/Settings.UI/Strings/en-us/Resources.resw`**:
Changed `"to snip screenshots to the clipboard or to a file"` → `"to
copy screenshots to the clipboard or to a file"` in both
`ZoomIt.ModuleDescription` and `Oobe_ZoomIt.Description`
- `copy` has an unambiguous, distinct Chinese translation (`复制`) with no
overlap with `截图`
- Consistent with the existing `ZoomIt_SnipGroup.Description` which
already uses `"Copy a selected area of the screen to the clipboard or to
a file"`
## PR Checklist
- [ ] Closes: #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
Before (zh-CN rendered):
> 还可以使用 Zoomlt 将屏幕**截图截图截图**剪贴板或文件中
After (expected zh-CN):
> 还可以使用 ZoomIt 将截图**复制到**剪贴板或文件中
Root cause: `snip` (Windows snipping action) and `screenshots` are both
translated to `截图` by the localization pipeline, producing triple
repetition. Replacing `snip` with `copy` — already used in the adjacent
Snip group description — resolves the collision without changing the
functional meaning.
## Validation Steps Performed
- Verified both string keys (`ZoomIt.ModuleDescription`,
`Oobe_ZoomIt.Description`) updated in `en-us/Resources.resw`
- Confirmed no other occurrences of `"snip screenshots"` remain in the
file
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: MuyuanMS <116717757+MuyuanMS@users.noreply.github.com>
## Summary
Removes outdated/unused documentation and asset files:
- **`doc/unofficialInstallMethods.md`** — removed.
- **`doc/planning/`** — removed entire folder (`awake.md`,
`FancyZonesBacklog.md`, `PowerToysBacklog.md`,
`ShortcutGuideBacklog.md`).
- **`doc/images/icons/Video Conference Mute.png`** — removed (unused
module icon, not referenced anywhere in the repo).
Verified there are no remaining references to any of the removed files
across tracked sources (checked literal and `%20`-encoded paths).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
`PowerToys.Update` reads `downloadedInstallerFilename` from the
persisted `UpdateState.json` and combines it with the `Updates` folder
to locate the installer to run. If that cached state is stale,
corrupted, or otherwise unexpected, the stored value could contain path
separators or an absolute path, which would make the updater look for
the installer outside the `Updates` folder.
This PR validates that the cached value is a plain filename and that the
resolved path stays inside the `Updates` folder before using it;
otherwise the update is treated as unavailable. The normal update flow
(a bare asset filename produced by the download step) is unaffected.
## PR Checklist
- [ ] **Communication:** I've discussed this with core contributors
already.
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** No end-user-facing strings added
- [x] **Dev docs:** N/A
- [x] **New binaries:** None
## Detailed Description of the Pull Request / Additional comments
- The filename check is factored into an inline helper
`updating::IsSafeDownloadedInstallerFilename` in
`src/common/updating/updateLifecycle.h` (next to the other inline update
helpers) so it can be unit-tested without a project reference.
- `ObtainInstaller` in `src/Update/PowerToys.Update.cpp` now calls that
helper and additionally confirms, via `weakly_canonical`, that the
resolved installer path's parent is the `Updates` directory.
- No behavior change for normal installer filenames, so the regular
update flow does not regress.
## Validation Steps Performed
- Added `IsSafeDownloadedInstallerFilenameTests` to `Updating.UnitTests`
covering normal filenames, empty values, parent-directory components,
nested path components, and absolute/drive-relative/UNC paths.
- Built `Updating.UnitTests` (Debug x64): 0 warnings, 0 errors.
- Ran the full `Updating.UnitTests` suite: 36/36 passed (30 existing + 6
new).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
Fixes#25353 — the FancyZones Settings page bounces / jumps when the
user scrolls down to the bottom (the **Excluded apps** expander).
Several closed dupes report the same behavior: #31500, #34259, #30164,
#45173, #32099, #32361.
## Root cause
The Excluded-apps `TextBox` (lines 283-305 of `FancyZonesPage.xaml`)
forced its own inner `ScrollViewer` to be permanently enabled with a
visible scrollbar, nested inside the page-level `ScrollViewer` provided
by `SettingsPageControl`:
```xml
ScrollViewer.IsVerticalRailEnabled="True"
ScrollViewer.VerticalScrollBarVisibility="Visible"
ScrollViewer.VerticalScrollMode="Enabled"
```
The expander is `IsExpanded="True"` and sits at the very bottom of the
page, so when you wheel-scroll down the page the pointer ends up over
the TextBox. The TextBox''s inner scroller intercepts the wheel events;
when it has nothing left to scroll the event bubbles back to the outer
page scroller, which tries to over-scroll past content end. The result
is the bounce/jump visible in the videos on the issue.
The unbounded `MinHeight="160"` (with no `MaxHeight`) made it worse,
because the box can grow as users type, triggering layout re-measures
during scrolling.
## Fix
Minimal change to the same TextBox:
- Drop `ScrollViewer.IsVerticalRailEnabled` and
`ScrollViewer.VerticalScrollMode` — `AcceptsReturn="True"` already wires
up the inner scroller correctly.
- Change `ScrollViewer.VerticalScrollBarVisibility` from `Visible` to
`Auto`, so the inner scroller only competes with the outer one when
there is actual overflow to scroll.
- Add `MaxHeight="320"` so the box cannot keep growing as the user
types.
## Validation
- Builds clean (`tools\build\build.cmd` from
`src\settings-ui\Settings.UI`, arm64 Debug, exit 0, 0 errors).
- The same nested-scroller pattern exists on 9 other Settings pages
(AlwaysOnTop, GrabAndMove, MouseUtils, MouseWithoutBorders, PowerAccent,
PowerLauncher, ShortcutGuide). Keeping this PR atomic to the page called
out in #25353; happy to follow up with a sibling PR for those if
reviewers want them in the same pass.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
`PidToIconConverter.Convert` called `Icon.ExtractAssociatedIcon(path)`
without a guard. When a running process's image path is non-empty but
the file no longer exists on disk, the call throws
`FileNotFoundException`. The converter runs per-row while the process
`ListView` virtualizes, so the exception reached
`App_UnhandledException` (which only logs and never sets `e.Handled =
true`) and WinUI 3 fast-failed the whole app (`0xc000027b`).
This is routinely triggered by self-updating software that deletes its
old versioned directory while the old process keeps running — e.g.
Windows Defender (`SenseAPZ`, `MsMpEng`, `MpDefenderCoreService` under
versioned `...\Platform\<ver>\` / `...\DataCollection\<ver>\` paths).
Right-clicking a drive root enumerates every process and reliably
includes such a stale-path process, so the crash is easy to hit in
normal use.
The fix wraps the icon extraction in a try/catch and falls through to
the existing placeholder `BitmapImage`, logging a warning — mirroring
the exception handling already present in `MainViewModel.WatchProcess`.
## PR Checklist
- [x] Closes: #48693
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass — no existing test harness
covers this WinUI converter path; validated manually (steps below)
- [x] **Localization:** All end-user-facing strings can be localized —
n/a; the only new string is a developer log warning, not end-user UI
- [x] **Dev docs:** Added/updated — n/a
- [x] **New binaries:** Added on the required places — n/a; no new
binaries
## Detailed Description of the Pull Request / Additional comments
`src/modules/FileLocksmith/FileLocksmithUI/Converters/PidToIconConverter.cs`:
```csharp
if (!string.IsNullOrEmpty(y))
{
try
{
icon = Icon.ExtractAssociatedIcon(y);
}
catch (Exception ex)
{
// The process image path can be non-empty but no longer exist on disk
// (e.g. self-updating software that deletes its old versioned directory while
// the old process is still running). ExtractAssociatedIcon then throws and,
// because this converter runs per-row during ListView virtualization, the
// exception would otherwise reach App_UnhandledException and fast-fail the app.
// Fall through to the placeholder icon instead of crashing.
Logger.LogWarning($"Couldn't extract the icon for '{y}'. {ex}");
}
}
```
(+ `using ManagedCommon;` — already a project reference; `Logger` is
used identically in `App.xaml.cs`.)
Scope note: this keeps to the targeted converter guard. I deliberately
did **not** also blanket-set `e.Handled = true` in
`App_UnhandledException`, since that would mask unrelated genuine
crashes; the converter guard fully addresses this crash.
## Validation Steps Performed
1. Reproduced on the installed 0.100 build: right-click `C:\` → **Unlock
with File Locksmith** → scroll the list → crash (`0xc000027b`, faulting
module `Microsoft.UI.Xaml.dll`; the FileLocksmith log shows an unhandled
`FileNotFoundException` for `...\SenseAPZ.exe` in
`MainPage...ProcessBindings` / `PidToIconConverter`). Reproduced twice.
2. Built `FileLocksmithUI` (x64/Release) with the fix — 0 warnings / 0
errors.
3. Ran the produced exe on `C:\` and scrolled ~40× over the same list
(which includes the stale `SenseAPZ` row):
- No crash; the process stayed alive and responsive.
- The log shows the new warning firing for the exact `...\SenseAPZ.exe`
path, confirming the catch branch executed on the previously-fatal row.
- 0 unhandled exceptions in the session.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
When you're pinning something to the dock with the dialog, I have _no_
idea what display is 1,2,3,4. That's meaningless to me.
This attempts to resolve that by adding a teachingtip to each dock while
pinning. When we open that pin to dock dialog, we'll display the
teachingtips, and dismiss them when the dialog is closed.
That way folks have at least some indication of where each display is
when pinning.
## Summary
The `TopLevelCommandManager` handles **alot.** And by "alot" I mean too
much. In preparation for future types of extensions, this PR attempts to
pull out the methods for loading/managing extensions to individual
`IExtensionService`s.
These `ExtensionService`s will be injected the `TopLevelCommandManager`
via dependency injection. It will iterate through them asking them to
load their extensions. During that process, they will surface
`ICommandProvider`s back to the `TopLevelCommandManager` for display in
Command Palette.
Currently, there are two types of `IExtensionService`s:
`BuiltInExtensionService` and `WinRTExtensionService`.
- The `BuiltInExtensionService` receives all `ICommandProvider`s
registered with DI.
- The `WinRTExtensionService` manages out-of-process WinRT AppExtension
providers.
## Additional Changes
- **Circular DI dependency resolved**: `BuiltInsCommandProvider` no
longer depends on `IRootPageService`.
Previously, it required the `IRootPageService` solely for the dock
command to open Command Palette (using the RootPage as its command.)
Now, it uses a new `GoHomeDockCommand` which returns
`CommandResult.GoHome()` with the existing `onBeforeShowConfirmation`
callback to show the palette at the dock button position.
Also, fixes#48643
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
Shortcut Guide overlay crashes and closes when navigating between
sidebar sections (e.g. clicking PowerToys, then clicking the Windows
icon to come back). Repro and crash logs in #48448. Crash logs in #48441
show the same propagation path plus a follow-up access violation in
coreclr, indicating exceptions that escape local catches.
This PR fixes the immediate navigation race and adds broader crash
hardening so future exceptions on the UI/background threads are logged
instead of tearing down the overlay.
### Navigation-race fix (commit 1)
Root cause: `WindowSelector_SelectionChanged` calls
`App.TaskBarWindow.Activate()` and then `SetWindowPosition()`
synchronously. `Activate()` runs a reentrant `Window_Activated` →
`BringToFront` → `TaskbarWindow.Activated` chain that can leave
`App.TaskBarWindow.AppWindow` momentarily null, so `SetWindowPosition`
throws `NullReferenceException`.
Because the initial `SelectedItem = MenuItems[0]` is set from
`SetNavItems`, the NRE bubbles up into `InitializeNavItemsAsync`'s catch
block — which sets `_closeType = "InitializationFailed"` and closes the
window. That matches both user-visible symptoms: the overlay "flashes
and disappears" (#48441) on open and "closes when clicking the Windows
icon" (#48448).
Edits in
`src/modules/ShortcutGuide/ShortcutGuide.Ui/ShortcutGuideXAML/MainWindow.xaml.cs`:
- **`SetWindowPosition`**: null-guard `App.TaskBarWindow?.AppWindow` and
skip the taskbar-overlap height adjustment when it is not currently
observable. Wrap the body in `try`/`catch` with `Logger.LogError` so any
future positioning hiccup keeps the previous layout instead of taking
down the overlay.
- **`WindowSelector_SelectionChanged`**: null-guard
`App.TaskBarWindow?.Hide()` / `Activate()` and wrap the body in
`try`/`catch`. This breaks the propagation path that lets a navigation
exception reach `InitializeNavItemsAsync`'s "fatal init failure" branch.
### Crash hardening (commit 2)
Additional defensive changes to cover other unguarded paths surfaced
while reviewing #48441:
- **`App.xaml.cs`**: register `App.UnhandledException`,
`AppDomain.CurrentDomain.UnhandledException`, and
`TaskScheduler.UnobservedTaskException` so a stray exception (e.g. an IO
failure during a fire-and-forget UI handler, or a background `Task`
fault) gets logged instead of tearing the process down with an access
violation in coreclr. Mirrors what Peek, AdvancedPaste, and CmdPal
already do.
- **`App.OnLaunched`**: wrap the launch sequence in `try`/`catch` and
exit cleanly with an error log on failure (`LoadData` / `MainWindow` /
`TaskbarWindow` ctors and `Activate` are all reachable failure points).
- **`App.LoadData`**: broaden the `Pinned.json` deserialize catch to
also handle `IOException` / `UnauthorizedAccessException`, and guard the
round-trip `SaveSettings` call as best-effort with a warning log.
- **`PinnedShortcutsHelper.Save`**: catch `IOException` /
`UnauthorizedAccessException` / `JsonException` and log; `Pin` / `Unpin`
runs from a synchronous UI handler so an unguarded `File.WriteAllText`
would tear down the overlay on any disk hiccup.
- **`TaskbarWindow.UpdateTasklistButtons`**: move the `AppWindow.Move`
calls inside the existing `try` block, null-guard
`App.MainWindow?.AppWindow` up front, and wrap the whole body so the
method (which runs from the ctor and from `Activated`) cannot tear the
overlay down when `MainWindow` is in a transient state.
## PR Checklist
- [x] Closes: #48448
- [x] Likely also fixes: #48441
- [x] **Communication:** Defensive fix to known crash paths; no API
change.
- [ ] **Tests:** No automated tests added — the failures are reentrancy
/ timing races that are hard to deterministically trigger in CI.
Validated with a synthetic repro (see below).
- [x] **Localization:** N/A — only logger strings.
- [x] **Dev docs:** N/A
- [x] **New binaries:** N/A
## Detailed Description of the Pull Request / Additional comments
The fix is intentionally defensive (rather than restructuring the
reentrant activation flow) because the legacy taskbar UIA enumeration
(`TasklistPositions.GetButtons`) on Windows 10 is what most reliably
widens the race window and is out of scope to redesign for a hotfix.
## Validation Steps Performed
- Build: `tools\build\build.cmd` from
`src\modules\ShortcutGuide\ShortcutGuide.Ui` — exit 0, errors log empty
for both commits.
- Synthetic repro: temporarily injected `throw new
NullReferenceException()` at the top of `SetWindowPosition` to exercise
the exact propagation path the reporter's log shows (`SetWindowPosition`
→ `SelectionChanged` → `set_SelectedItem` →
`InitializeNavItemsAsync.catch` → `Close("InitializationFailed")`).
- Before fix: overlay flashes and closes, log shows `Failed to
initialize navigation items.` with the NRE.
- After fix: overlay stays open, page navigates, log shows `Failed to
set Shortcut Guide window position; keeping previous layout.` from the
new `catch`.
- Did not reproduce the live race on a Win11 dev box; the reporter's
repro is Windows 10 19045 / Microsoft Store install where the legacy
taskbar UIA timing makes the reentrant chain more likely to expose the
null.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
The per-user **"Autorun for <user>"** logon scheduled task
(created in `src/runner/auto_start_helper.cpp`) was registered with a
security descriptor that granted **full access to Everyone**
(`D:(A;;FA;;;WD)`). This PR scopes the task's permissions to only the
accounts that actually need them.
## Changes
- `src/runner/auto_start_helper.cpp`
- Added a small `get_auto_start_task_sddl()` helper that builds the
task's security descriptor granting full control to **Local System**,
the **Administrators** group, and **the user the task belongs to** (SID
read from the current process token).
- Use it when calling `RegisterTaskDefinition` instead of the previous
Everyone descriptor.
- Added `#include <sddl.h>` for `ConvertSidToStringSidW`.
## Behavior / compatibility
- No change to the run-at-startup or run-elevated flows. The decision
logic in `general_settings.cpp` is untouched — only the descriptor
string passed to `RegisterTaskDefinition` changed.
- The task owner can still fully manage (enable / disable / delete) its
own task in both elevated and non-elevated runner modes, because a
user's token SID is identical across elevation.
- The Task Scheduler service (SYSTEM) retains full control, so the task
still runs at logon as before.
## Validation
- Built `src/runner/runner.vcxproj` (x64 / Debug): **0 errors, 0
warnings**.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
Profiles in the Environment Variables utility override **User**
variables only, as described in
[`doc/devdocs/modules/environmentvariables.md`](https://github.com/microsoft/PowerToys/blob/main/doc/devdocs/modules/environmentvariables.md).
This change makes the implementation apply that documented behavior
consistently: every registry write performed while applying, unapplying,
or editing a profile now goes through dedicated user-scope helpers
instead of the generic `ParentType`-based helpers. It also removes some
dead code along the way.
## PR Checklist
- [ ] Closes: N/A (code consistency / cleanup)
- [x] **Tests:** No automated test project exists for this module;
validated via build + manual steps (see below)
- [x] **Localization:** No end-user-facing strings changed
- [x] **Dev docs:** Existing docs already describe the user-scoped
profile behavior; no change needed
- [x] **New binaries:** None
## Detailed Description of the Pull Request / Additional comments
- Added `SetProfileVariableWithoutNotify` /
`UnsetProfileVariableWithoutNotify` to `EnvironmentVariablesHelper`.
They centralize writing profile-driven variables to the current-user
environment, reusing the existing
`SetEnvironmentVariableFromRegistryWithoutNotify` primitive.
- Updated `ProfileVariablesSet.Apply` / `UnapplyVariable` and the
profile branch of `Variable.Update` to use these helpers.
- Removed an unused local (`var applyToSystem =
variable.ApplyToSystem;`) in `ProfileVariablesSet.Apply`.
- Removed the now-unused `SetVariableWithoutNotify` /
`UnsetVariableWithoutNotify` helpers. The notify variants (`SetVariable`
/ `UnsetVariable`) are unchanged and still back the default User/System
set editing.
- Net change: 3 files, +18 / −33.
## Validation Steps Performed
- Built `EnvironmentVariablesUILib` (Debug, x64): **succeeded, 0
warnings / 0 errors**.
- Manual: created, enabled, disabled, and edited profiles; confirmed
profile variables apply, back up the overridden values, and restore them
on disable exactly as before.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
Mouse Without Borders encrypts the socket streams it uses to talk
between machines. Previously the PBKDF2 salt and the AES-CBC IV were
both derived from a single fixed constant, so every connection reused
identical key-derivation material.
This change generates a fresh random salt and IV for each connection and
exchanges them in-band as a small cleartext header ahead of the cipher
text. The AES key is now derived from the per-connection salt.
## Changes
- `Encryption.cs`: generate a random per-connection salt + IV,
write/read them as a cleartext header in
`GetEncryptedStream`/`GetDecryptedStream`, and derive the key from that
salt.
- Removed the now-unused fixed-IV helper (`GenLegalIV`), the `InitialIV`
constant, and the derived-key cache (a per-connection salt makes caching
pointless).
- The header exchange reuses the same tolerant socket-close handling as
the existing random first-block handshake, so the exception behavior
seen by callers (`SocketStuff`, `Clipboard`) is unchanged. Call sites
are untouched.
## Compatibility
This changes the on-the-wire format, so all paired machines must run
this version. Mouse Without Borders already requires the same version on
every machine (it surfaces *"make sure you run the same version in all
machines"* on a handshake mismatch). Existing keys and settings are
preserved - no re-pairing is needed once every machine is updated.
## Validation
- Built `MouseWithoutBorders` App and UnitTests (Release | x64) - clean
(exit 0).
- Added `EncryptionTests` covering encrypt -> decrypt round-tripping and
per-connection uniqueness (salt/IV/header differ on every connection).
All 3 tests pass.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
Hardens the local `github-artifacts` MCP helper
(`tools/mcp/github-artifacts/server.js`) so the `GITHUB_TOKEN` bearer
token is only ever sent to allowlisted GitHub API hosts. Previously the
same token was attached when downloading image and ZIP URLs extracted
from issue/PR Markdown, which could forward the token to any host
referenced in untrusted issue content.
This is repository MCP dev-tooling, not the shipped PowerToys runtime.
## What changed
- **New `auth.js`** centralizes token handling:
- `AUTH_ALLOWED_HOSTS = { api.github.com }`
- `shouldSendGitHubToken(url)` — true only for HTTPS + allowlisted host
- `headersForUrl(url, token, extra)` — attaches `Authorization` only
when the host is allowlisted
- **`server.js`** routes all three request sites (`fetchJson`,
`downloadBytes`, `downloadZipBytes`) through `headersForUrl`. Image/ZIP
URLs from issue content are now fetched **without** `Authorization`.
Removed the ZIP dual-attempt auth retry that previously sent the token
to untrusted hosts.
- **New `test-token-allowlist.js`** regression test (wired into `npm
test` / `npm run test:unit`).
## Verification
- Unit test: 13/13 pass — token attached for `api.github.com`, withheld
from arbitrary hosts, loopback, look-alike hostnames
(`api.github.com.attacker.com`), non-HTTPS, and
`*.githubusercontent.com`.
- Cross-origin redirects: confirmed Node's `fetch` (undici) strips
`Authorization` when a redirect leaves the origin.
- Functionality preserved (real public issues, real token): issue #25595
images (5/5 downloaded) and issue #39476 `PowerToysReport_*.zip`
(downloaded + extracted) both succeed without the token — GitHub serves
this content via public/signed URLs.
## Note
For private-repo attachments that would require an `Authorization`
header on a non-API host, the token is intentionally not sent (the
recommended tradeoff). PowerToys is public, so the helper's normal use
is unaffected.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
This PR adds `Microsoft.Plugin.Folder.UnitTests` to SLNX as a project
instead of a plain file.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Remove `UPDATE_STAGE2_RESTART_PT` and `UPDATE_STAGE2_DONT_START_PT`
constants from `UpdateUtils.h`. Never referenced anywhere in the
codebase.
Fixes#46968. Found during multi-agent code review of #46889.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
On dual-GPU laptops, Power Display stopped detecting the built-in panel
(and adjusting its brightness) when the **discrete GPU** drives the
display — it showed "can't detect the display". This fixes that by
classifying displays by **capability** (does WMI brightness work on it?)
instead of by the nominal `OutputTechnology` value, which the discrete
GPU misreports for the internal panel.
## PR Checklist
- [x] Closes: #48587
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized (no
new user-facing strings added)
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
## Detailed Description of the Pull Request / Additional comments
### Root cause
On a hybrid / MUX laptop, when the **discrete GPU** drives the built-in
eDP panel, `QueryDisplayConfig` reports the panel's
`DISPLAYCONFIG_VIDEO_OUTPUT_TECHNOLOGY` as `DISPLAYPORT_EXTERNAL` (`10`)
instead of the `INTERNAL` flag (`0x80000000`) it reports under the
integrated GPU. It is the *same physical panel* (same EDID) — only the
reported connector type changes with the active GPU.
PR #47740 introduced a strict classifier: `OutputTechnology` →
internal/external, then **internal → WMI-only, external → DDC/CI-only,
with no fallback**. So under the discrete GPU the built-in panel was
classified *external* and sent to DDC/CI only — but a laptop eDP panel
does not speak DDC/CI, so it was dropped and Power Display reported it
couldn't detect any monitor. (`WmiMonitorBrightness` still exposes that
panel regardless of which GPU drives it, so the panel was actually
controllable — it just never got routed to WMI.)
### Fix: classify by capability, not by nominal output technology
- **`MonitorManager`** now runs **WMI discovery first** over the full
`QueryDisplayConfig` inventory. Every display `WmiMonitorBrightness`
exposes is treated as internal (WMI-controlled); whatever WMI does
**not** claim is routed to DDC/CI. The `OutputTechnology`-based
classifier is gone.
- **`WmiController`** matches the system-wide `WmiMonitorBrightness`
results against the full inventory by `Monitor.Id`. The persisted
`Monitor.Id` is still taken from the matched `DevicePath`
(byte-identical to the DDC route and to prior releases), so saved
brightness/per-monitor settings survive upgrades.
- New **`MonitorIdentity.FromInstanceName`** reduces a WMI
`InstanceName` to the same canonical `Monitor.Id` as `FromDevicePath`;
the separate `PnpHardwareKey` helper is removed.
- **Deleted** `DisplayClassifier` and `MonitorDisplayInfo.IsInternal`
(net ~150 fewer lines).
### Accepted trade-off
A monitor that exposes **both** `WmiMonitorBrightness` **and** DDC/CI is
now controlled via WMI only and won't get DDC-only features (contrast /
volume / input source / color temperature / power). This is uncommon
(typical laptop panels are WMI-only; typical external monitors are
DDC-only) and is a deliberate decision: it removes the entire class of
`OutputTechnology` misclassification bugs while keeping the performance
win of not DDC-probing internal panels.
## Validation Steps Performed
- Built the Power Display app (`PowerDisplay.csproj`) and
`PowerDisplay.Lib.UnitTests` (x64 / Debug) with MSBuild — both succeed,
including after merging latest `main` (Windows App SDK 2.2.0).
- Ran the unit test suite: **128/128 pass**, including new
`FromInstanceName` tests — the `FromInstanceName == FromDevicePath`
equivalence invariant and a concrete #48587 regression case (the BOE
panel reported as `OutputTechnology=10`).
- Traced the fix against the reporter's diagnostic logs: the panel that
previously went `OutputTechnology=10 → External → DDC → dropped` is now
claimed by WMI and controllable.
- Reviewed the diff for regressions (Monitor.Id persistence, monitor
blacklist, mirror mode, dual-internal-panel devices, external-only
desktops).
---------
Co-authored-by: Yu Leng <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Increase sleep duration while waiting for IPC setup in the interop unit
test.
A number of PRs have had failures recently even though they do not touch
interop, likely due to this sleep being too short. An existing comment
points to the addition of the delay being because of this, and
resource-constrained build agents/environments could need a longer
duration.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
See comments on #47211 and #48106.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
N/A
## Summary of the Pull Request
Converts the literal-digit shortcut keys in the bundled Shortcut Guide
manifests to the `<N>` special-key convention, so they render as the
correct number.
Per the manifest spec, a bare number in `Keys:` is a virtual-key code. A
literal digit key authored as a bare number is therefore misread (VK `9`
is Tab, VK `1` is the left mouse button, VK `0` is undefined) and
renders incorrectly. The fix authors these as the `<N>` token (for
example `"<9>"`), which `KeyVisual` strips to display the digit.
This is a data-only change: **91 literal-digit keys across 14
manifests** become `<N>` tokens. No code or doc changes; the renderer
and converter already support `<N>`, and the convention is documented in
the spec.
Follow-up to #48461, which introduced and documented the `<N>`
convention (per @noraa-junker's request for a separate PR to fix the
remaining manifests). Together with #48461 this resolves the rendering
reported in #48460.
Files touched (all under
`src/modules/ShortcutGuide/ShortcutGuide.Ui/Assets/ShortcutGuide/Manifests/`):
Adobe.Illustrator (18), Adobe.Photoshop (17), SlackTechnologies.Slack
(13), Adobe.InDesign (11), JetBrains.IntelliJIDEA.Community (11),
BlenderFoundation.Blender (3), Figma.Figma (3), Google.Chrome (3),
Microsoft.Edge (3), Microsoft.VisualStudioCode (3), Mozilla.Firefox (3),
+WindowsNT.Notepad (1), Adobe.AfterEffects (1), GIMP.GIMP (1).
## PR Checklist
- [ ] **Closes:** N/A (follow-up to #48461; contributes to #48460)
- [ ] **Communication:** discussed in #48461; @noraa-junker requested
this separate PR.
- [ ] **Tests:** N/A for data; the converter and `<N>` convention are
unit-tested in #48461. Validated here by deserializing every manifest
with YamlDotNet (see below).
- [x] **Localization:** unchanged; these are per-language manifest
files.
- [ ] **Dev docs:** N/A (the `<N>` convention is documented in the spec
via #48461).
- [ ] **New binaries:** N/A.
- [ ] **Documentation updated:** N/A.
## Detailed Description of the Pull Request / Additional comments
Each change wraps a single bare digit in angle brackets, for example:
```yaml
Keys:
- - 9
+ - "<9>"
```
Quoted tokens (`"<9>"`) are used to match the dominant special-token
style already in the manifests (`"<Enter>"`, `"<Down>"`, etc.).
Note (out of scope): `Adobe.Photoshop.en-US.yml` has a shortcut with an
empty `Name: ""` (around line 799). That is a pre-existing data issue
unrelated to digit rendering; the digit is still converted, and the
empty name is left as-is.
## Validation Steps Performed
- Confirmed the diff touches only the 14 manifests, 91 insertions and 91
deletions, with each changed line being a digit wrapped as `"<N>"` (no
whitespace, indentation, or encoding churn).
- Confirmed zero bare-digit `Keys` entries remain and exactly 91 new
`"<N>"` tokens exist.
- Deserialized all 32 manifests with YamlDotNet (the same library the
app uses at runtime): 0 parse errors.
- Rendering behavior for `<N>` is already verified in #48461 (the
renderer strips the brackets to show the digit).
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
## Summary of the Pull Request
Adds a Shortcut Guide manifest for **Postman** and fixes a rendering bug
where single-digit keys in manifests displayed incorrectly.
- **Fix numbered-key rendering** —
`src/modules/ShortcutGuide/ShortcutGuide.Ui/Converters/ShortcutDescriptionToKeysConverter.cs`:
a single digit (`0`–`9`) in a manifest's `Keys` was treated as a Windows
virtual-key code instead of the literal digit. Since VK `1` is the left
mouse button, VK `9` is Tab, and VK `0` is undefined, shortcuts such as
`Ctrl+0` (reset zoom) and `Ctrl+9` (last tab) rendered as
blank/incorrect glyphs. Single digits are now rendered as the literal
character.
- **Add Postman shortcuts** —
`src/modules/ShortcutGuide/ShortcutGuide.Ui/Assets/ShortcutGuide/Manifests/Postman.Postman.en-US.yml`:
new manifest for `Postman.exe` covering Tabs, Sidebar, Request,
Interface, Window and modals, and Console. Auto-included via the
existing `Manifests/*.yml` glob in `ShortcutGuide.Ui.csproj`.
- **Show tab-number ranges** — Edge, Chrome, Firefox, and Postman
manifests: the "switch to a specific tab" entry used the literal key
`1`, which (after the fix above) read as `Ctrl + 1`. It now uses a `1 -
8` range so the keycap conveys "any tab number 1 through 8". The
separate "last tab" (`9`) and "reset zoom" (`0`) entries remain literal
single keys.
- **Add unit tests** — new `ShortcutGuide.UnitTests` (MSTest) project
covering `ShortcutDescriptionToKeysConverter.GetKeysList`, including the
single-digit regression.
## PR Checklist
- [x] Closes: #48460
- [ ] **Communication:** I've discussed this with core contributors
already. <!-- Filed #48460; the v0.100 announcement invites app-shortcut
contributions via PR. -->
- [x] **Tests:** Added/updated and all pass <!-- New
ShortcutGuide.UnitTests (MSTest); 8 tests pass locally via
vstest.console. -->
- [x] **Localization:** All end-user-facing strings can be localized
<!-- Shortcut names live in per-language manifest files (`*.en-US.yml`);
other locales fall back to en-US, consistent with existing manifests.
-->
- [ ] **Dev docs:** Added/updated <!-- N/A: no behavior requiring
dev-doc changes. -->
- [ ] **New binaries:** Added on the required places <!-- N/A: the new
manifest is a data asset under an already-shipped, globbed folder. The
new test project is auto-discovered by the existing `**\*UnitTest*.dll`
VSTest glob, so no CI pipeline change is required. -->
- [ ] **Documentation updated:** <!-- N/A -->
## Detailed Description of the Pull Request / Additional comments
The Shortcut Guide displays per-app shortcuts from YAML manifests,
matched to the foreground window via `WindowFilter`. Keys are converted
to keycaps by `ShortcutDescriptionToKeysConverter`. Numeric key strings
were unconditionally parsed as virtual-key codes, so literal-digit
shortcuts rendered wrong. The fix adds a `>= 0 and <= 9` case that emits
the digit character as-is; non-digit numeric codes (arrows, etc.) are
unchanged.
The new Postman manifest exercises this with `Ctrl+0` / `Ctrl+9`. The
browser/Postman "specific tab" entries were updated from the literal `1`
to the `1 - 8` range string, rendered verbatim by `KeyVisual` (the same
path used by the existing `Number (1-9)` key in the Windows Explorer
manifest).
A new `ShortcutGuide.UnitTests` (MSTest) project covers the converter:
single digits render literally (regression test), modifier ordering,
non-numeric passthrough (e.g. `1 - 8`), and arrow-key VK mapping.
## Validation Steps Performed
Built and ran locally (x64 Debug):
- Built `ShortcutGuideModuleInterface`, `ShortcutGuide.Ui`, and
`ShortcutGuide.IndexYmlGenerator`; launched the Debug `PowerToys.exe`.
- Triggered Shortcut Guide (`Win+Shift+/`) with **Postman** focused: the
Postman section renders with all categories, and `Ctrl+1` / `Ctrl+9` /
`Ctrl+0` display correctly (previously blank/incorrect).
- Verified the "specific tab" entry renders as `Ctrl + 1 - 8` in
**Edge**, **Chrome**, **Firefox**, and **Postman**.
- Built `ShortcutGuide.UnitTests` and ran via `vstest.console.exe`:
**8/8 tests pass**.
<img width="845" height="1432" alt="PowerToys Shortcut Guide Running
Postman"
src="https://github.com/user-attachments/assets/6359617e-3e2c-48b0-8005-b3684594ec94"
/>
Co-Authored-By: Claude Opus 4.8
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #37801
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
This uses `SetWindowAffinity()` with the `WDA_EXCLUDEFROMCAPTURE`
constant on the main Color Picker window to ensure the ZoomWindow bitmap
creation excludes the corner of the picker UI. The ability to capture
the picker window is restored immediately after, so it's still visible
in Snipping Tool, Remote Desktop and other tools.
The fix uses a new helper with simple `Include()` / `Exclude()` methods
as an adapter to the native code. This may potentially be included in
Common if other utilities needed it.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
1. Repro'd the original issue on the current Color Picker release:
<img width="262" height="263" alt="image"
src="https://github.com/user-attachments/assets/bc12b2f8-b67f-4b56-a803-57ab2fe0fa17"
/>
2. Confirmed that the fix worked and normal window affinity was restored
(otherwise I would not have been able to snip this):
<img width="262" height="262" alt="image"
src="https://github.com/user-attachments/assets/bc336ad0-4114-49fa-8440-b78466de363f"
/>
3. Repeated zooming in and out over a normal session.
Closes#45025
## [QuickAccent] Add Pitjantjatjara / Yankunytjatjara Language Support
### Summary
This pull request adds support for Pitjantjatjara/Yankunytjatjara
to the Quick Accent feature. Pitjantjatjara/Yankunytjatjara is an
Australian Aboriginal language
spoken in the Western and South Australian deserts.
### What's New
- Users can now access Pitjantjatjara/Yankunytjatjara retroflex
consonant characters (ḻ, ṉ, ṟ, ṯ)
through Quick Accent
- Language is available in the Quick Accent settings dropdown menu
- Full localization support for UI display
### Why This Matters
Pitjantjatjara/Yankunytjatjara uses unique retroflex consonants that are
essential for:
- **Correct pronunciation:** Retroflex sounds are phonetically distinct
from regular consonants
- **Written accuracy:** Proper character representation in educational
materials
- **Cultural preservation:** Supporting Aboriginal language
documentation and teaching
- **Accessibility:** Users without specialized keyboards can now type
these characters easily
### Character Mappings
The implementation adds 4 retroflex consonants:
- **L → ḻ** (Retroflex lateral approximant)
- **N → ṉ** (Retroflex nasal)
- **R → ṟ** (Retroflex approximant)
- **T → ṯ** (Retroflex stop)
### Files Changed
1. **Language.cs** - Added `PJT` enum value
2. **CharacterMappings.cs** - Added language entry with character
mappings and display order
3. **Resources.resw** - Added localized UI string
4. **expect.txt** - Added language name to spell-check whitelist
### Testing
- ✅ Language appears in Quick Accent settings dropdown
- ✅ Retroflex characters appear when holding L/N/R/T + activation key
- ✅ No build errors or warnings
## Summary
Fixes VS Code Workspaces recent entries discovery after VS Code 1.118
moved `history.recentlyOpenedPathsList` to the shared application
storage database.
The plugin now probes both the legacy `User/globalStorage/state.vscdb`
database and the new shared storage database for VS Code Stable,
Insiders, Exploration, VSCodium, VSCodium Insiders, and portable
installs.
It also deduplicates results that may appear in both locations.
Fixes#47445
## Validation
- Reviewed the change against the issue's documented VS Code 1.118
storage paths.
- Attempted local focused build from
`src/modules/launcher/Plugins/Community.PowerToys.Run.Plugin.VSCodeWorkspaces`
with `tools/build/build.cmd -Platform x64 -Configuration Debug`.
- Build was blocked by local environment/tooling issues unrelated to
this C# change: missing/invalid VC tooling/Windows SDK.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [X] Closes: #48443
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
The PR modifies the `CharacterMappings.cs` file by adding the Philippine
peso symbol to the symbols for the "P" key under the Currency group.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
No validation steps were performed as I assume this would not create any
breaking changes.
## Summary
Refines the **Grab and Move** drag/resize overlay so it matches the
polish of **Always on Top (AoT)**, and lowers the AoT default border
thickness. Created at the request of @crutkas.
Two related border-refinement changes, kept in one PR because the Grab
and Move "double layer" is designed around AoT's border.
https://github.com/user-attachments/assets/0b605f92-60bd-44a0-a540-70e6d425146a
### 1. Always on Top - default border thickness 15 -> 4
The default highlight border was `15px`, which is visually heavy.
Dropped to `4px` for a tighter, Fluent-style frame.
- `src/modules/alwaysontop/AlwaysOnTop/Settings.h` (C++ default)
- `src/settings-ui/Settings.UI.Library/AlwaysOnTopProperties.cs`
(`DefaultFrameThickness`)
- Existing users keep their configured value; only fresh installs /
"reset" pick up `4`. Slider range (1-30) is unchanged.
### 2. Grab and Move - tight, warning-gold overlay (fill + border)
Previously the overlay was a full translucent **white wash** sized to
`GetWindowRect`, which includes the invisible resize-border / shadow
margins (~7px) - so it sat *off* the visible window. It now hugs the
visible frame, mirroring AoT:
- **Keeps the translucent white wash** over the visible window (the
familiar "grabbed" feedback) and adds a tight **warning-gold border on
top**. Both hug the visible frame and are rounded to match the window
corners.
- **Tight geometry:** anchored to `DWMWA_EXTENDED_FRAME_BOUNDS` (inset
by the invisible-border margins) instead of `GetWindowRect`.
- **Corner detection:** matches the window's corner radius via
`DWMWA_WINDOW_CORNER_PREFERENCE` (same mapping AoT uses); border
thickness and radius scale with the target window DPI.
- **Distinct accent:** Fluent **warning gold `#FFB900`** - the literal
equivalent of WinUI
[`SystemFillColorCaution`](https://learn.microsoft.com/en-us/windows/apps/design/style/color)
(used as a `ThemeResource` for warnings across the Settings UI; a Win32
layered window can't resolve a `ThemeResource`, so a literal is
required). Keeps Grab and Move visually distinct from AoT's accent-blue.
- **Double layer, for free:** the Grab and Move border is drawn just
**inside** the visible edge, while AoT draws its border just **outside**
the visible edge. The two naturally stack into a clean double layer, so
Grab and Move stays a constant **4px** with no AoT detection / window
enumeration.
Rendering keeps the existing GDI + `UpdateLayeredWindow` per-pixel-alpha
path and adds **GDI+** (a Windows system library - no new third-party
dependency) for the antialiased, rounded fill and border. Frame metrics
are computed **once per drag/resize** (never in the mouse-move hot
path). The optional geometry label is unchanged.
## Before / After
| | Before | After |
|---|---|---|
| Grab and Move overlay | Full white wash, offset from the window edge |
Same wash, now tight to the visible frame + gold border, corner-matched
|
| AoT default border | 15px | 4px |
| AoT + Grab and Move together | white wash over AoT border | GM gold
inside the edge + AoT accent outside it = double layer |
## Validation
- Builds clean (exit 0, 0 warnings/errors) for **x64 Debug**:
`GrabAndMove`, `AlwaysOnTop`, and `Settings.UI.Library` (Code Analysis /
C26451 clean).
- Smoke-tested live by running the standalone module exes: tight gold
border + wash on Alt-drag / Alt-right-drag, AoT 4px border, and the
inside/outside double layer on a pinned window.
- WARNING: still **draft** pending broader visual validation (border
tightness across DPIs, the exact gold, rounded vs square corners, AoT
z-order during fast drags - AoT renders from a separate process and
follows on a ~100ms timer). Screenshots to be added.
## Follow-up (not in this PR)
AoT and Grab and Move remain **separate** overlay systems (AoT:
persistent per-window Direct2D border; Grab and Move: transient
GDI/`UpdateLayeredWindow` overlay). They can't share one runtime window,
but the frame-geometry + corner-detection + DPI helpers are worth
extracting into `src/common` (seeded by AoT's
`WindowCornersUtil`/`ScalingUtils`). Tracked separately to keep this PR
atomic (`src/common` is an ABI-careful area).
## Notes
- No IPC/JSON schema changes; no new settings.
- No new third-party dependencies (GDI+ is a system library).
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This pull request adds a custom `docmd` plugin to improve how
documentation links to source files are handled, ensuring that
repo-root-relative links work both when editing locally and on the
published site. The main changes include introducing the new plugin,
updating configuration to use it, and documenting its behavior.
**Plugin integration and configuration:**
* Added a new local plugin `github-source-links` in `docmd-plugins/`,
which rewrites repo-root-relative links (e.g., `/src/.../Foo.cpp`) in
Markdown files to absolute GitHub blob URLs during the documentation
build process, ensuring links remain functional on the published site.
[[1]](diffhunk://#diff-c2c746e6974a6cfdd229031c2977f2bb0dca37c6d5f598ed45dc0d9f0b74c7caR1-R52)
[[2]](diffhunk://#diff-a97f3ce59c97313aacd716b9874b445d162c45ee2e6ef9fd2db59fe17235e1cfR1-R8)
* Updated `docmd.config.json` to register the new plugin under the
`plugins` key, enabling it for documentation builds.
* Updated `package.json` to include the plugin as a dependency,
referencing the local plugin directory.
**Documentation updates:**
* Updated `README.md` to document the new `docmd-plugins/` folder,
explain the purpose of repo-root-relative links, and describe how the
plugin rewrites these links for the published site.
This pull request introduces a new, automated workflow for building and
publishing the developer documentation website using
[docmd](https://docmd.io/). The static site is now generated from
`doc/devdocs`, built in the `doc/devdocs-website` folder, and deployed
to GitHub Pages via a GitHub Actions workflow. The build output is not
committed to the repository but is instead published as an artifact.
Supporting configuration files, documentation, and `.gitignore` entries
are also added to streamline local development and CI/CD.
**Automated build and deployment:**
* Added `.github/workflows/regenerate-devdocs-website.yml` to build the
static site with docmd and deploy it to GitHub Pages automatically on
changes to `doc/devdocs` or `doc/devdocs-website`, or via manual
trigger.
**Project setup and configuration:**
* Added `doc/devdocs-website/package.json` to define the Node.js
project, pin the docmd version, and provide scripts for local
development and builds.
* Added `doc/devdocs-website/docmd.config.json` to configure docmd (site
title, source, output directory, base path).
* Added `doc/devdocs-website/.npmrc` to disable lockfile generation,
ensuring fresh dependency installs each build.
**Documentation and housekeeping:**
* Added `doc/devdocs-website/README.md` with instructions for editing,
building, and publishing the docs website.
* Added `doc/devdocs-website/.gitignore` to exclude the generated
`site/` output from version control.
This pull request updates the `auto-labeler.yml` GitHub Actions workflow
to improve reliability and maintain compatibility. The most important
changes are an upgrade to the `actions/github-script` version and
improved error handling when applying labels, ensuring the workflow does
not fail due to restricted permissions.
**Dependency upgrade:**
* Upgraded `actions/github-script` from version 7 to version 9 in the
`Apply area labels with AI` step, ensuring continued support and access
to the latest features and security updates.
**Error handling improvements:**
* Added a `try/catch` block around the label application logic to
gracefully handle cases where the workflow lacks permission to write
labels (e.g., due to restricted integration tokens), logging a message
and skipping the operation instead of failing the entire workflow.
This is a totally minor nitpick.
I don't have the dock enabled on all my displays. But the current "pin
to dock" dialog lets me pin it to a display I don't have the dock on.
When that happens, it effectively results in _nothing_ happening. Not
great.
This PR mitigates that situation, but only listing the enabled docks
when pinning.
This PR fixes Issue #48680 where the CmdPal dock performance meter shows
'???' after restart.
**Root cause**: The PerformanceWidgetsPage initially returns items with
a placeholder title ('???') because ContentData hasn't loaded yet. The
DataManager timer starts when the dock subscribes to ItemsChanged, and
the Updated event fires 1 second later with real data. However, the
Updated event handlers were updating ListItem.Title directly without
calling RaiseItemsChanged() on the page, so the dock was never notified
that the items had changed and continued to display the stale '???'
title.
**Fix**: Added a RaiseItemsChanged() call to each of the 5 Updated event
handlers (CPU, Memory, Network, GPU, Battery) after the item titles are
updated. This causes the dock to re-call GetItems() and refresh the
displayed titles.
Fixes#48680
This pull request makes minor adjustments to the
`.github/workflows/auto-labeler.yml` GitHub Actions workflow, focusing
on permissions and event triggers.
Workflow configuration updates:
* Added `pull-requests: write` permission to the workflow to ensure it
has the necessary access for managing pull requests.
* Removed the `edited` event from the list of triggers for
`pull_request_target`, so the workflow will no longer run when a pull
request is edited.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Changed the icon from the sleep icon to the hibernate icon, which fixes
the issue in #48535
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #48535
## Detailed Description of the Pull Request / Additional comments
The icon was previously the sleep icon, and I have changed it to the
hibernate icon.
## Validation Steps Performed
I have visually checked that the icon is now updated to the correct
icon.
Regressed in one of the last two releases.
The problem was that `history.ToImmutableList()` ran on the projected
`IVector<string>`. `ImmutableList.CreateRange` checks for
`IReadOnlyCollection<string>`, and resolving that interface on a WinRT
object requires a helper type that AOT can't generate.
So we have to just _not do that_.
Closes#48445
## Summary of the Pull Request
Gives the CmdPal toast notification a glow-up: it now slides in/out with
a nice fade, has acrylic + a soft shadow, and stops fighting with
`SizeToContent`.
Along the way, the toast guts got refactored into a couple of reusable
bits that live in `PowerToys.Common.UI.Controls` so other PowerToys
utilities can grab them for their own transient overlays:
- **`TransparentWindow`** — a `WindowEx`-derived host that strips the
native frame, hides from taskbar/Alt-Tab, uses `TransparentTintBackdrop`
for transparency, and runs show/hide implicit animations on its content.
Supply your own animations via `ShowAnimations` / `HideAnimations`, or
take the defaults (fade + slide).
- **`TransparentCard`** — a templated `ContentControl` with acrylic
(`AlwaysActiveDesktopAcrylicBackdrop`), rounded corners, border, and
shadow. Drop whatever XAML you want inside.
- **`AlwaysActiveDesktopAcrylicBackdrop`** — small `SystemBackdrop`
wrapper so the acrylic doesn''t go grey when the window isn''t focused
(transient overlays are never focused).
CmdPal''s `ToastWindow` is now basically a 16-line wrapper: derives from
`TransparentWindow`, drops a bound `TextBlock` inside, and handles its
own 2.5s auto-hide timer + bottom-center positioning.
https://github.com/user-attachments/assets/3a62080c-22f0-480c-ac4d-028bcc32f07d
## PR Checklist
- [x] Closes: #40886
- [x] **Communication:** I''ve discussed this with core contributors
already.
- [ ] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
## Detailed Description of the Pull Request / Additional comments
A couple of design notes worth calling out:
- The window is sized slightly bigger than the visible card (~24px
breathing room on each side) so the shadow and slide animation have room
to render without clipping. That buffer area is transparent but NOT
click-through — kept it small on purpose. We explored `SetWindowRgn` and
`EnableWindow` tricks to make it click-through too, but neither plays
nicely with WinUI 3''s DesktopWindowXamlSource. Small transparent frame
is the pragmatic compromise.
- Animations use the Toolkit''s implicit `ShowAnimations` /
`HideAnimations` so there''s zero animation code in
`ToastWindow.xaml.cs`.
- `TransparentCard.xaml` is registered in `Themes/Generic.xaml` —
required for templated controls in a library project;
`<GenerateLibraryLayout>` alone doesn''t auto-merge per-control xaml.
## Validation Steps Performed
- Built clean (arm64 Debug).
- Triggered a CmdPal toast manually: fades + slides in, hangs for 2.5s,
fades + slides out.
- Acrylic stays active when the window isn''t focused (toasts are never
focused).
- Shadow renders fully without clipping.
---------
Co-authored-by: niels9001 <niels9001@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Fixes some typos and grammar mistakes inside docs, strings, and
comments.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
None
---------
Co-authored-by: Niels Laute <niels.laute@live.nl>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This pull request updates the auto-labeling workflow to support both
issues and pull requests, improves clarity in logs and prompts, and
renames the workflow file for broader applicability. The changes enhance
automation for triaging by enabling area label assignment to new or
updated pull requests in addition to issues.
**Expanded triage coverage and workflow improvements:**
* The workflow now triggers on both issue and pull request events
(`opened`, `reopened`, `edited`, `synchronize`), allowing automatic area
labeling for pull requests as well as issues.
(`.github/workflows/auto-labeler.yml`,
[.github/workflows/auto-labeler.ymlL1-R7](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL1-R7))
* The concurrency group logic has been updated to handle pull request
events separately from issues, ensuring that rapid updates to a PR or
issue are managed correctly. (`.github/workflows/auto-labeler.yml`,
[.github/workflows/auto-labeler.ymlR24-R26](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eR24-R26))
**User experience and clarity enhancements:**
* Console logs and prompt messages now refer generically to "item" or
distinguish between "Issue" and "Pull request" as appropriate, improving
clarity in workflow output and AI prompts.
(`.github/workflows/auto-labeler.yml`,
[[1]](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL41-R44)
[[2]](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL58-R79)
[[3]](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL139-R146)
[[4]](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL212-R217)
* The system prompt for the AI labeling assistant has been updated to
clarify that both issues and pull requests should be classified and
labeled. (`.github/workflows/auto-labeler.yml`,
[.github/workflows/auto-labeler.ymlL127-R133](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL127-R133))
**File naming:**
* The workflow file has been renamed from
`.github/workflows/auto-label-issues.yml` to
`.github/workflows/auto-labeler.yml` to reflect its broader scope.
(`.github/workflows/auto-labeler.yml`,
[.github/workflows/auto-labeler.ymlL1-R7](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL1-R7))
Adds a `SettingsManager` scaffold to the CmdPal extension template so
new extensions have a ready-to-use settings pattern out of the box.
## Summary of the Pull Request
Most extensions need configuration. The template previously had no
settings infrastructure, leaving developers to discover the pattern from
built-in extensions. This adds a wired-up `SettingsManager` following
the same conventions used across all built-in extensions.
## PR Checklist
- [ ] Closes: #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
**`Helpers/SettingsManager.cs`** (new)
- Extends `JsonSettingsManager` (already bundled in
`Microsoft.CommandPalette.Extensions`)
- Uses `Utilities.BaseSettingsPath()` for correct local-state path
(packaged and unpackaged)
- Includes commented-out `ToggleSetting` example illustrating the full
add/register/expose cycle
- Auto-saves via `Settings.SettingsChanged` event
**`TemplateCmdPalExtensionCommandsProvider.cs`** (updated)
- Instantiates `SettingsManager` as a field
- Sets `Settings = _settingsManager.Settings` to advertise settings to
CmdPal
- Exposes `_settingsManager.Settings.SettingsPage` in `MoreCommands` for
in-app settings access
```csharp
// Helpers/SettingsManager.cs
internal sealed partial class SettingsManager : JsonSettingsManager
{
private static readonly string _namespace = "templatecmdpalextension";
private static string Namespaced(string propertyName) => $"{_namespace}.{propertyName}";
// TODO: Add your settings here. For example:
// private readonly ToggleSetting _myToggle = new(
// Namespaced(nameof(MyToggle)), "My toggle setting", "Description", false);
// public bool MyToggle => _myToggle.Value;
public SettingsManager()
{
FilePath = SettingsJsonPath();
// Settings.Add(_myToggle);
LoadSettings();
Settings.SettingsChanged += (_, _) => SaveSettings();
}
}
// TemplateCmdPalExtensionCommandsProvider.cs
private readonly SettingsManager _settingsManager = new();
public TemplateCmdPalExtensionCommandsProvider()
{
// ...
_commands = [
new CommandItem(new TemplateCmdPalExtensionPage())
{
Title = DisplayName,
MoreCommands = [new CommandContextItem(_settingsManager.Settings.SettingsPage)],
},
];
Settings = _settingsManager.Settings;
}
```
The template wizard replaces `"TemplateCmdPalExtension"` throughout all
files, so `BaseSettingsPath` and the namespace string will update
automatically when scaffolding a new extension.
## Validation Steps Performed
- Verified `SettingsManager` pattern matches existing built-in
extensions (`ClipboardHistory`, `System`, `Registry`)
- No new package references required — `JsonSettingsManager`,
`ToggleSetting`, and `Utilities` are all included in the existing
`Microsoft.CommandPalette.Extensions` NuGet package
<!-- START COPILOT ORIGINAL PROMPT -->
<details>
<summary>Original prompt</summary>
>
> ----
>
> *This section details on the original issue you should resolve*
>
> <issue_title>CmdPal: Include basic SettingsManager in
Template</issue_title>
> <issue_description>### Description of the new feature / enhancement
>
> Include basic `SettingsManager` in template.
>
> ### Scenario when this would be used?
>
> I believe most extensions will require some form of configuration, so
adding basic `SettingsManager` would be helpful.
>
> ### Supporting information
>
> _No response_</issue_description>
>
> ## Comments on the Issue (you are @copilot in this section)
>
> <comments>
> </comments>
>
</details>
<!-- START COPILOT CODING AGENT SUFFIX -->
- Fixesmicrosoft/PowerToys#39274
<!-- START COPILOT CODING AGENT TIPS -->
---
🔒 GitHub Advanced Security automatically protects Copilot coding agent
pull requests. You can protect all pull requests by enabling Advanced
Security for your repositories. [Learn more about Advanced
Security.](https://gh.io/cca-advanced-security)
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: niels9001 <9866362+niels9001@users.noreply.github.com>
Co-authored-by: Muyuan Li (from Dev Box) <muyuanli@microsoft.com>
## Summary
Fixes incorrect Chinese translation where both Sleep and Hibernate
commands showed '休眠' (hibernation) instead of using distinct terms: '睡眠'
for Sleep and '休眠' for Hibernate.
## Changes
Added \<comment>\ elements with \ZH:\ guidance to 6 resource entries in
\Microsoft.CmdPal.Ext.System\\Properties\\Resources.resx\:
| Resource Key | Current Comment | Added ZH Guidance |
|---|---|---|
| \Microsoft_plugin_command_name_hibernate\ | *(none)* | translate as
'休眠' |
| \Microsoft_plugin_sys_hibernate\ | Existing English comment | use 休眠
not 睡眠 |
| \Microsoft_plugin_sys_hibernate_confirmation\ | Existing English
comment | use 休眠 not 睡眠 |
| \Microsoft_plugin_command_name_sleep\ | *(none)* | translate as '睡眠',
do NOT use '休眠' |
| \Microsoft_plugin_sys_sleep\ | Existing English comment | use 睡眠 not
休眠 |
| \Microsoft_plugin_sys_sleep_confirmation\ | Existing English comment |
use 睡眠 not 休眠 |
## Why comments only?
Chinese translations are managed by the internal CDPX localization
pipeline. Adding \<comment>\ elements to the English \.resx\ file is the
standard way to guide translators for the next localization pass. See
similar fix in PR #48649 for Japanese translation guidance.
## Summary
Adds translation guidance comments to English .resx resource strings
that have incorrect Japanese translations in the CDPX localization
pipeline.
## Problem
- **Download/Downloading** — translated as 受け取り (implies physical
package receipt) instead of the correct IT term 受信
- **Battery** (laptop/tablet context) — translated as 電池 (dry cell)
instead of バッテリー (built-in battery)
## Fix
Added comment elements to 9 resource entries across 3 files with the
prefix JA: to guide the localization team:
| File | Strings | Comment |
|------|---------|---------|
| Microsoft.CmdPal.Ext.WinGet\Properties\Resources.resx |
winget_downloading, winget_download_progress | JA: translate as 受信 not
受け取り |
| Microsoft.CmdPal.UI.ViewModels\Properties\Resources.resx |
winget_operation_status_downloading,
winget_operation_status_downloading_percent,
gallery_item_winget_action_downloading_with_progress,
gallery_item_winget_action_downloading | JA: translate as 受信 not 受け取り |
| Microsoft.CmdPal.Ext.WindowsSettings\Properties\Resources.resx |
BatterySaver, BatterySaverSettings, BatteryUse | JA: translate as バッテリー
not 電池 |
## Background
As documented in doc/devdocs/development/localization.md, localized
.resx files are generated at build time by the CDPX pipeline from .lcl
files managed by the internal localization team. The comment elements in
English .resx files are surfaced to translators and are the correct
mechanism for providing translation guidance. The actual .lcl file fixes
must be applied by the internal team.
Closes#48598
## Summary
Adds the two missing top-level exception handlers in the QuickAccess
(Preview) flyout host so that an unhandled XAML exception during launch
or page navigation no longer FailFasts `PowerToys.QuickAccess.exe`.
Spotted while reading through `App.OnLaunched` and `ShellPage` for an
unrelated review of the flyout startup path — none of the existing
handlers exist yet, so any throw during `MainWindow` construction,
`ShellHost.Initialize`, or `ContentFrame.Navigate(typeof(LaunchPage) |
typeof(AppsListPage), …)` bubbles all the way out to the Windows App SDK
runtime and is stowed as a XAML failure. Compare with
`src\settings-ui\Settings.UI\SettingsXAML\App.xaml.cs`, which already
wires `UnhandledException += App_UnhandledException`.
## Changes
**`src\settings-ui\QuickAccess.UI\QuickAccessXAML\App.xaml.cs`**
- Hook `Application.UnhandledException` in the constructor. The handler
logs the exception via `ManagedCommon.Logger.LogError` (same logger
Settings uses) and sets `e.Handled = true`. QuickAccess is a transient
launcher flyout owned by the runner, so swallowing a stray XAML error
and keeping the host alive for the next summon is the correct trade-off
— the failure is still recorded for diagnostics.
- Wrap the body of `OnLaunched` in a try/catch. If `MainWindow` (which
sets up window chrome, listener threads, the IPC coordinator, and the
XAML shell) fails to construct, log the exception and call `Exit()`
cleanly rather than letting the throw escape into the Windows App SDK
launch path.
**`src\settings-ui\QuickAccess.UI\QuickAccessXAML\Flyout\ShellPage.xaml.cs`**
- Subscribe to `ContentFrame.NavigationFailed` after
`InitializeComponent`. A page constructor or XAML-load failure in
`LaunchPage` / `AppsListPage` would otherwise bubble out of the `Frame`
and crash the launcher. The handler logs the failure
(`SourcePageType.FullName` + the exception) and marks it handled so the
next summon retries navigation.
No production behaviour changes when things work — only the failure
paths are different. No public API surface changes.
## Why both handlers, not just one
- `Application.UnhandledException` does not fire for
`Frame.NavigationFailed`. The Frame raises its own event first and, if
no handler runs or `e.Handled` is left `false`, then it rethrows on the
dispatcher.
- Conversely, `Frame.NavigationFailed` only fires for navigation
failures — not for an exception thrown directly in `OnLaunched` before
any navigation happens.
The two events are complementary, so both need a handler to fully cover
the launch + navigation paths.
## Testing
- The local NuGet feed on my dev box currently can't restore
`Microsoft.NETCore.App.Runtime.win-x64 = 10.0.9` (the feed only has
`11.0.0-preview.1.26104.118`), which fails the project restore for every
WinUI project including this one. That's the same environment issue I
called out on #48414 — pipeline restore uses a different feed and is
fine.
- All three patterns added here are copy-paste analogues of code that
already exists in `Settings.UI` (`App.xaml.cs:96, 106-109`,
`ShellViewModel.cs:86, 136`), so namespace and signature drift risk is
minimal. The only behavioural difference is `e.Handled = true`, which is
the actual goal of this PR.
## Risk
- Low. Two new event handlers and one try/catch. No behaviour change on
the success path.
- Worst-case regression is that a real, repeatable XAML failure becomes
silent in the runner's eyes (no process crash) instead of loud — but
it's logged via `Logger.LogError` so the user can still find the trace
in `%LOCALAPPDATA%\Microsoft\PowerToys\Logs\`.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
ADO:
https://microsoft.visualstudio.com/DefaultCollection/OS/_workitems/edit/61258633/
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #46464
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary
Addresses the **root cause chain** behind the NullReferenceException
crash in Settings navigation. Crash dump analysis with WinDbg revealed
that `Frame.Navigate()` can throw native WinUI ABI exceptions that
propagate unhandled through multiple code paths.
### Changes (3 files)
**NavigationService.cs** — Defensive try-catch for all
`Frame.Navigate()` call sites:
- `Navigate()`: Wrap in try-catch, log via `Logger.LogError()`, return
`false` on failure
- `EnsurePageIsSelected()`: Add matching try-catch for consistency (also
calls `Frame.Navigate()` unprotected)
- Protects **all** navigation in the Settings app
**ShellViewModel.cs** — Fix the crash-causing `Frame_NavigationFailed`
handler:
- Replace `throw e.Exception` with `e.Handled = true` +
`Logger.LogError()`
- The original code threw `NullReferenceException` when `e.Exception`
was null (native WinUI errors don't always marshal to managed Exception
objects)
- Mark the event as handled to prevent framework error propagation
**ShellPage.xaml.cs** — Protect `async void SearchBox_QuerySubmitted`:
- Wrap entire method body in try-catch
- `async void` methods that throw after `await` produce unhandled
exceptions that crash the process
- Covers both search indexing (`Task.Run`) and navigation failures
### Crash Dump Evidence
Analysis of `PowerToys.Settings_2025_03_26_48636.dmp` with WinDbg:
- 4 stowed exception records found at `0x000001c60d3b9100`
- Exception chain: `SearchBox_QuerySubmitted` → `Frame.Navigate()` fails
at native ABI → `NavigationFailed` fires with null Exception → `throw
null` → `NullReferenceException` → `FailFastWithStowedExceptions`
- Root failure in `Microsoft.UI.Xaml.dll!DirectUI::Frame::Navigate`
### Review Notes
- `catch (Exception)` pattern matches 92.5% of Settings.UI codebase
convention
- `Logger.LogError()` with `using ManagedCommon` matches standard import
pattern
- No security concerns: logged page type names are not sensitive data
- Build verified locally (38/38 applicable tests pass; 111 COM-dependent
tests fail identically on main)
Co-authored-by: Tucker Burns <tuck.burns@gmail.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
When a modifier key (Ctrl/Alt/Shift) is remapped to a non-modifier key
using
Keyboard Manager, the injected key event is delivered to applications as
WM_SYSKEYDOWN instead of WM_KEYDOWN. This causes unexpected behavior —
for
example, remapping Left Alt to Backspace results in whole words being
deleted
instead of single characters, because applications interpret
WM_SYSKEYDOWN +
VK_BACK as Alt+Backspace.
The fix resets the modifier state with a suppress-flag key-up event
before
injecting the target key, consistent with the existing approach used for
the
Caps Lock remapping scenario.
## PR Checklist
- [ ] Closes: #47191
- [ ] Communication: I've discussed this with core contributors already.
If the work hasn't been agreed, this work might be rejected
- [x] Tests: Added/updated and all pass
- [ ] Localization: All end-user-facing strings can be localized
- [ ] Dev docs: Added/updated
- [ ] New binaries: Added on the required places
## Detailed Description of the Pull Request / Additional comments
The root cause is that SendInput is called inside the low-level keyboard
hook
callback before the original modifier event is suppressed. At that point
the
modifier state is still active, so the OS delivers the injected key as
WM_SYSKEYDOWN (system key with Alt context) rather than WM_KEYDOWN.
This is the same mechanism that was already fixed for the Ctrl/Alt/Shift
↔
Caps Lock case. This PR extends the fix to cover modifier → non-modifier
remaps.
## Validation Steps Performed
1. Remapped Left Alt → Backspace in Keyboard Manager
2. Opened a text editor, typed text, pressed the remapped key
3. Confirmed single characters are deleted instead of whole words
4. All 93 unit tests pass (KeyboardManager.Engine.UnitTests)
## Summary
Add `docs/superpowers/` to `.gitignore` so all locally generated
superpowers artifacts (specs, design docs, and plans) are not committed.
These files are produced by local AI tooling and are workspace-local
only; they should not land in the repository.
## Change
```gitignore
# Superpowers-generated docs (specs, design, plans) — local-only, not committed
docs/superpowers/
```
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Yu Leng <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Summary
Upgrades the centrally-managed Windows App SDK package versions to the
**2.2.0 stable** umbrella released on NuGet.
| Package | Before | After |
|---|---|---|
| `Microsoft.WindowsAppSDK` | 2.0.1 | **2.2.0** |
| `Microsoft.WindowsAppSDK.Foundation` | 2.0.20 | **2.1.0** |
| `Microsoft.WindowsAppSDK.AI` | 2.0.185 | **2.2.3** |
| `Microsoft.WindowsAppSDK.Runtime` | 2.0.1 | **2.2.0** |
Foundation/AI/Runtime versions match the dependency graph declared by
`Microsoft.WindowsAppSDK` `2.2.0`'s own nuspec (`Foundation=2.1.0`,
`AI=2.2.3`, `Runtime=[2.2.0]`), so transitive resolution is exact and no
version-conflict warnings are introduced.
Also bumps the CmdPal `ExtensionTemplate` sample's local
`Directory.Packages.props` so the template stays in sync with the main
repo.
## Files changed
- `Directory.Packages.props`
-
`src/modules/cmdpal/ExtensionTemplate/TemplateCmdPalExtension/Directory.Packages.props`
## Validation
Ran `tools/build/build-essentials.cmd` on a clean `origin/main`
worktree:
- `msbuild PowerToys.slnx /t:restore /p:RestorePackagesConfig=true` —
**Build succeeded, 0 warnings, 0 errors** (00:02:50)
- `src/runner/runner.vcxproj` (x64 Debug) — **Build succeeded, 0
warnings, 0 errors** (00:04:15)
- `src/settings-ui/Settings.UI/PowerToys.Settings.csproj` (x64 Debug) —
**Build succeeded, 0 warnings, 0 errors** (00:03:14)
Full module test suite has **not** been run yet — this PR only certifies
the build-essentials baseline. CI will exercise the wider build/test
matrix.
## Notes
- This is an atomic packaging-only change. No source code touched, no
behavior changes.
- If WinAppSDK 2.2.0 surfaces any runtime regression downstream, it can
be reverted as a single commit.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Power Display could put a monitor to sleep but never wake it back up.
Selecting **On** in the per-monitor power-state list was a hard-coded
no-op, so the DDC/CI wake command (VCP `0xD6` = `0x01`) was never sent.
This removes that guard so selecting **On** wakes the display, and
cleans up the dead code/comment left behind by the original
one-directional design.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #48428
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
`MonitorViewModel.HandlePowerStateSelectionChanged` early-returned when
the selected power state was **On** (`0x01`), so `SetPowerStateAsync`
was never called for On and the wake write never reached the monitor. As
a result Power Display's power control was one-directional: it could
send Standby/Suspend/Off but could never turn a monitor back on.
The guard dates back to the very first power-state commit and was paired
with a single-monitor assumption — *"the monitor must be on to see the
UI"*, so On was treated as the always-current state and skipped. A later
change made the selection reflect the monitor's real power state (so a
monitor in the list can legitimately be asleep), and multi-monitor
support means the flyout can be shown on monitor A while the user wants
to wake monitor B. Those changes invalidated the assumption, but the
action-side guard survived a subsequent refactor.
The lower layers already do the right thing:
`MonitorManager.SetPowerStateAsync` →
`DdcCiController.SetPowerStateAsync` → `SetVcpFeatureAsync(monitor,
0xD6, value)` passes the value through unchanged, so the fix is purely
removing the UI-layer guard. DDC/CI stays reachable while the panel is
in Standby/Suspend/Off(DPM), so writing `0x01` turns it back on (this is
the same mechanism Twinkle Tray uses). `Off (Hard)` / `0x05` may still
require a physical wake on some monitors, since that state can cut the
DDC command channel.
Cleanup included in this PR:
- Removed the now-unused `PowerStateItem.PowerStateOn` constant (its
only consumer was the deleted guard).
- Removed the dead `SetPowerState` `[RelayCommand]` (the generated
`SetPowerStateCommand` had zero references — the XAML wires
`SelectionChanged`, not a command).
- Updated the `SetPowerStateAsync` doc comment from the one-directional
framing to a neutral bidirectional description.
Net change: 2 files, +5 / −24.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
- **Build:** `MSBuild PowerDisplay.csproj -p:Platform=x64
-p:Configuration=Debug` (CoreCompile) — **0 errors / 0 warnings**.
- **Static check:** repo-wide grep confirms no remaining references to
`PowerStateOn` or `SetPowerStateCommand`; the power-state ListView binds
only `ItemsSource` + `SelectionChanged` (no `SelectedItem` binding), so
opening the flyout cannot spuriously re-fire a selection.
- **Manual (requires a DDC/CI monitor):** enable *Power state control*
for a monitor → open its flyout and select **Standby** or **Off (DPM)**
(screen blanks) → reopen the flyout and select **On** → the display
wakes.
No automated test was added: with the guard removed the handler is an
unconditional pass-through (identical in shape to
`HandleInputSourceSelectionChanged`), and it is an `async void` WinUI
event handler over real DDC/CI hardware, which is outside the
`PowerDisplay.Lib` unit-test seam.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Yu Leng <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Updated the DiskAnalyzer plugin link and author information to point to
the ValleySoft organization repository instead of my personal account.
## Summary of the Pull Request
Documentation-only change. Updates the DiskAnalyzer entry in
`thirdPartyRunPlugins.md`:
- Plugin URL: `thetsaw/PowerToys.Plugin` →
`valley-soft/powertoys-diskanalyzer`
- Author: `thetsaw` → `ValleySoft`
## PR Checklist
- [ ] Closes: N/A
- [x] **Communication:** This is a minor doc-only update to correct a
repo link — no prior discussion needed
- [x] **Tests:** N/A — documentation change only
- [x] **Localization:** N/A — no user-facing strings changed
- [x] **Dev docs:** Updated `doc/thirdPartyRunPlugins.md`
- [ ] **New binaries:** N/A
## Detailed Description of the Pull Request / Additional comments
The DiskAnalyzer PowerToys Run plugin was originally submitted under my
personal GitHub account (`thetsaw`). The project has since been moved to
the official **ValleySoft** organization at:
https://github.com/valley-soft/powertoys-diskanalyzer
## Validation Steps Performed
Verified all URLs are live and resolve correctly:
- https://github.com/valley-soft/powertoys-diskanalyzer✅
- https://github.com/valley-soft✅
## Summary
The `Check Spelling` workflow has been failing on PRs against `main`
(e.g. #48546) due to issues introduced by the recent ZoomIt webcam-blur
/ noise-cancellation change (#48266) plus two pre-existing duplicate
entries in `.github/actions/spell-check/excludes.txt`.
## What the bot reported
| Severity | Type | Location |
|---|---|---|
| ❌ | `forbidden-pattern` (Should be `a`) |
`src/modules/ZoomIt/ZoomIt/rnnoise/kiss_fft.h:79` — third-party kiss_fft
header contains `an fft` |
| ⚠️ | `large-file` (~30 MB) |
`src/modules/ZoomIt/ZoomIt/rnnoise/rnnoise_data_little.c` |
| ⚠️ | `binary-file` |
`src/modules/ZoomIt/ZoomIt/selfie_segmentation.onnx` |
| ⚠️ | `duplicate-pattern` ×2 | `excludes.txt` lines 115/116 duplicate
lines 108/109 (`FuzzyMatcher{Comparison,Diacritics}Tests.cs`) |
## Fix
`.github/actions/spell-check/excludes.txt`:
- **Drop 2 duplicate** `FuzzyMatcher*Tests.cs` lines.
- **Add 2 new exclusions** for the new third-party ZoomIt assets:
- `^src/modules/ZoomIt/ZoomIt/rnnoise/` — entire third-party
rnnoise/kiss_fft tree (covers both the `an fft` forbidden-pattern in
`kiss_fft.h` and the 30 MB `rnnoise_data_little.c` large-file).
- `^src/modules/ZoomIt/ZoomIt/selfie_segmentation\.onnx$` — the ML model
binary.
Net change: `-2` duplicates, `+2` new exclusions → file count unchanged
at 148 lines.
## Notes
- Third-party content under `rnnoise/` should not be spell-checked; this
matches how other vendored/third-party trees in the repo are handled
(e.g. `src/common/CalculatorEngineCommon/exprtk.hpp`,
`src/common/sysinternals/Eula/`).
- No source code changes; pure config.
- Unblocks #48546 and any other PR currently failing `Check Spelling` on
`main`.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
Clicking the clock dock band in the CmdPal Dock now opens the Windows
notification center (Action Center). A separate bell-icon-only dock band
is also exposed for users who prefer a dedicated notification center
shortcut.
Closes#46327
## Detail
- **Clock band left-click**: replaced the previous `NoOpCommand` on
`NowDockBand` with `OpenUrlCommand("ms-actioncenter:")`, dismissing the
Dock on invoke. The `ms-actioncenter:` URI is the correct shell
mechanism - `SendInput` Win+N was tested but dropped because it requires
foreground focus, which the Dock holds at click time.
- **Notification center band**: new `NotificationCenterDockBand`
(`ListItem`) in `TimeDateCommandsProvider.cs`, with a bell icon
(`\uEA8F`, Segoe Fluent Icons) and the same `ms-actioncenter:` command.
Exposed as a second `WrappedDockItem` from `GetDockBands()` under the id
`com.microsoft.cmdpal.timedate.notificationCenterBand`. Users can pin it
from the Dock's edit mode.
- **New resource strings**:
`timedate_show_notification_center_command_name` and
`timedate_notification_center_band_title` added to `Resources.resx` /
`Resources.Designer.cs`.
- **VS 2026 C++ build fixes** (pre-existing failures on `HEAD`): added
`_SILENCE_EXPERIMENTAL_COROUTINE_DEPRECATION_WARNINGS` to
`CalculatorEngineCommon.vcxproj`.
## Screenshots
<img width="339" height="991" alt="image"
src="https://github.com/user-attachments/assets/e0ef8c9a-ec1f-40fa-9620-1e83e6aeeb8d"
/>
## How tested
- Built `Microsoft.CmdPal.UI.csproj` (Debug x64) - 0 errors.
- Launched dev `Microsoft.CmdPal.UI.exe`, clicked the clock band -
notification center opened correctly.
- Right-click context menu on the clock band still shows "Copy time" and
"Copy date" unchanged.
- Pinned the notification center band via edit mode - bell icon renders
icon-only, click opens notification center.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This change adds the [RNNoise](https://github.com/xiph/rnnoise) filter
for noise cancellation (audio) and the [Google
mediapipe](https://github.com/google-ai-edge/mediapipe/tree/master)
`selfie_segmentation_cpu` model for webcam background detection and
blurring.
It also fixes an issue introduced with
ba68b88ca1 causing the ZoomIt shortcuts to
fail to register in the standalone version.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
The Settings UI has been extended with a Noise cancellation option, a
Background selection for the webcam and a Brightness slider.
The functionality for these is added to ZoomIt itself. Also, restored
the Mono checkbox which was accidentally masked by
b93fd97e80.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Mario Hewardt <marioh@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
## Summary of the Pull Request
Adds linked brightness control to PowerDisplay so multiple
brightness-capable monitors can be controlled from a single "All
Displays" slider.
This PR:
- Adds a linked brightness mode with one master brightness slider.
- Seeds the master slider from the linked display with the lowest
Windows DISPLAY number, falling back to monitor ID for determinism.
- Persists linked mode enabled/disabled state.
- Persists per-monitor exclusions by monitor ID.
- Keeps individual display cards available under an expandable section
while linked mode is enabled.
- Shows linked-state guidance in the link icon tooltip instead of a
separate info banner.
- Allows excluded displays to keep their own independent brightness
slider.
- Keeps profiles as per-monitor snapshots; applying a profile turns
linked brightness off before applying the profile values.
- Adds unit tests for linked-brightness selection/seed behavior and
settings compatibility.
## PR Checklist
- [x] Closes: #47319
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
**Screenshots**
| State | Light | Dark |
| --- | --- | --- |
| Linked mode off | <img width="519" height="817" alt="image"
src="https://github.com/user-attachments/assets/bdfae94b-b2e2-4ad3-a45c-7925bb9e5dcd"
/> | <img width="520" height="817" alt="image"
src="https://github.com/user-attachments/assets/69290a70-0375-480d-957c-c9e0af43d18e"
/> |
| Linked mode on | <img width="520" height="307" alt="image"
src="https://github.com/user-attachments/assets/a2b3572b-e51f-4bdc-9209-23ad2f96d27a"
/> | <img width="520" height="307" alt="image"
src="https://github.com/user-attachments/assets/8b14b665-b641-4256-a15b-eced82e62728"
/> |
| Linked mode on — individual displays expanded | <img width="520"
height="895" alt="image"
src="https://github.com/user-attachments/assets/0b40e60d-e78a-4814-baf6-00be7e283edd"
/> | <img width="520" height="895" alt="image"
src="https://github.com/user-attachments/assets/4f59bbfa-d6e5-4cb7-af84-cb484f922a7c"
/> |
The first version is intentionally scoped to brightness-only linked
control. Contrast, volume, color temperature, input source, and
LightSwitch-specific behavior remain independent.
Linked brightness is stored as global PowerDisplay settings:
- `linked_levels_active`
- `excluded_from_sync_monitor_ids`
Newly connected brightness-capable monitors are included by default,
because the exclusion list is the explicit exception. Hotplugging a
monitor does not immediately write brightness; linked hardware writes
happen only after the user changes the master slider.
Profiles remain per-monitor snapshots. This PR does not add
profile-level linked brightness configuration. If linked brightness is
active when a profile is applied, linked mode is turned off first, then
the saved per-monitor profile values are applied. That avoids leaving
the master linked slider active while hardware brightness has been
changed independently per monitor.
When linked mode is turned on, the master slider is seeded from the
linked brightness-capable display with the lowest Windows DISPLAY
number, falling back to monitor ID for determinism. Excluded displays
and displays without brightness support are ignored; if no linked target
remains, the master slider stays disabled. The seed only positions the
slider; it is never written to hardware, so the first user gesture is
the first broadcast.
## Validation Steps Performed
- Built `PowerDisplay.Lib.UnitTests` Debug x64:
```powershell
.\tools\build\build.ps1 -Platform x64 -Configuration Debug -Path src\modules\powerdisplay\PowerDisplay.Lib.UnitTests
```
- Ran `PowerDisplay.Lib.UnitTests` with `vstest.console.exe`
- Ran the XAML styling script:
```powershell
.\.pipelines\applyXamlStyling.ps1 -Main
```
- Result: the XAML styling script completed successfully and processed
`src/modules/powerdisplay/PowerDisplay/PowerDisplayXAML/MainWindow.xaml`.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This fixes a bug introduced by
`ba68b88ca1617e52647c6dde467c56f53ca2422a` in the hotkey processing
logic.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
A complex condition ended up being incorrectly broken into 2 conditions,
leading to a missed `else` execution. This led to the mishandling of
keyboard shortcuts especially during reassignment in the standalone mode
for ZoomIt.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
## Summary of the Pull Request
This PR fixes Shortcut Guide foreground app detection by resolving app
IDs from the window that was in the foreground before the Shortcut Guide
UI takes focus.
Based on review feedback, it also adds the missing XML `<param>`
documentation for `foregroundWindowHandle` in
`ManifestInterpreter.GetAllCurrentApplicationIds(...)` to satisfy
documentation/style requirements.
## PR Checklist
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
### Functional change
- Capture and reuse the foreground window handle taken before Shortcut
Guide UI activation.
- Use that captured handle for current-application ID resolution instead
of querying foreground window later, improving app-specific shortcut
matching reliability.
### Follow-up feedback fix
- Added missing XML parameter documentation:
-
`src/modules/ShortcutGuide/ShortcutGuide.Ui/Helpers/ManifestInterpreter.cs`
- Added `<param name="foregroundWindowHandle">...</param>`
## Validation Steps Performed
- Ran `parallel_validation` (Code Review: no issues; CodeQL: skipped as
trivial doc-only follow-up).
- Attempted local `dotnet build` for `ShortcutGuide.Ui.csproj`; blocked
by transient external package feed/network failure while restoring
`Microsoft.Build.CopyOnWrite/1.0.282`.
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
## Summary
Flips the default for the `Shortcut Guide` entry in `enabledModules`
from `true` to `false`. New PowerToys installs (no prior
`settings.json`) will start with Shortcut Guide disabled, matching how
other newer modules (PowerToys Run, MouseJump, AdvancedPaste,
MouseWithoutBorders, CropAndLock, QuickAccent, TextExtractor,
MousePointerCrosshairs, KeyboardManager) already ship off-by-default in
`EnabledModules.cs`.
## Why
Shortcut Guide has been on-by-default since the early days, but it is an
opt-in style utility (overlay launched on hotkey). It should not be
active for users who never asked for it on a fresh install.
## Changes
- `src/settings-ui/Settings.UI.Library/EnabledModules.cs` -- flip
`shortcutGuide` backing field from `= true` to bare declaration with the
file's `// defaulting to off` comment convention.
- `src/settings-ui/Settings.UI.UnitTests/ViewModelTests/General.cs` --
update the corresponding `AllModulesAreEnabledByDefault` assertion.
## Compatibility
Existing installs are unaffected: their `settings.json` already persists
the user's prior value (`true`), so anyone who has it on today keeps it
on. Only freshly created `EnabledModules` instances pick up the new
default.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
Visual polish for the Shortcut Guide UI, follow-up to #48383 and #48384.
- Fixes the Settings footer icon being clipped in the rail at startup.
Root cause: the icon `RowDefinition` in `CustomNavigationViewStyle.xaml`
was `*`, so the rail's `MinHeight` constraint compressed the 20px icon
down. Changing it to `Auto` lets the row size to its content. This also
removes the need for the `FakeSettingsButton` workaround.
- Replaces the laptop `FontIcon` used for the `Windows` nav entry with a
4-square Windows logo rendered as a `PathIcon`.
- Replaces the bitmap PowerToys app icon with a theme-aware vector
`PathIcon` (rounded square frame + menu bar + three dots) so it matches
the rest of the icons.
- Path data for both icons lives as `x:String` resources in `App.xaml`.
- Tunes the rail item `Row 0` height so the icon vertically aligns with
the selection pill center.
<img width="681" height="1405" alt="image"
src="https://github.com/user-attachments/assets/10787087-e32f-4018-b004-3f824648b962"
/>
## PR Checklist
- [x] **Closes:** part of the Shortcut Guide 0.100 polish set
- [x] **Communication:** internal only
- [x] **Tests:** manual verification
- [x] **Localization:** no new strings
- [x] **Dev docs:** N/A
## Validation Steps Performed
- Built locally and verified the Settings footer icon is no longer
clipped on first show.
- Verified the Windows nav entry now uses the Windows logo PathIcon and
renders correctly in light and dark.
- Verified the PowerToys entry now renders as a vector and follows the
theme foreground.
- Verified the selection pill aligns vertically with the icon center.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Transitions the telemetry PR detection workflow from testing phase to
ready status. All components are now fully functional and automatically
triggered on every new PR.
- Skips checks on draft PRs to avoid noise
- Prevents multiple concurrent runs per PR
- Safely requests `@chatasweetie` as reviewer on telemetry changes
- update commit messages
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
We have no idea why this event isn't flowing in 0.99. We fixed the other
"new" event, `CmdPal_ExtensionInvoked`, when we merged #47121. But this
event didn't show up.
So, as a blind experiment, we're removing the potentially long payload.
Just to see if something happens.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #47572
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
In the powerdisplay tool, Added a new button, that allows to copy the
current display configuration, to allow to share for troubleshooting, or
just sharing.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Fixes labels not associated with controls in Installed Apps pane.
Narrator only announces "space, checkbox, checked/unchecked" for
Extensions > Installed Apps page checkboxes instead of reading the label
too.
this is an a11y internal bug
The Adaptive Cards renderer (`AdaptiveCards.Rendering.WinUI3` v2.x)
renders `Input.Toggle` as a CheckBox whose `Content` is a TextBlock
containing just `" "`. Without an AutomationProperties.Name`, Narrator
reads the CheckBox.Content (a space character), making the settings
inaccessible to screen reader users.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Michael Jolley <mike@baldbeardedbuilder.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Fixes#48224
The Performance Monitor extension was still storing its settings in the
shared settings.json file. Since Command Palette built-in extensions now
use extension-specific sibling settings files, the extension's settings
could be overwritten when Command Palette personalization settings were
saved.
This change updates SettingsJsonPath() to store Performance Monitor
settings in an extension-specific settings file
(performanceMonitor.settings.json), ensuring the network speed unit
setting persists correctly.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #48224
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
The Performance Monitor extension had not been migrated to the newer
extension-specific settings file architecture. As a result, its settings
were stored in the shared settings.json file and could be lost when the
Command Palette host rewrote its configuration.
Following @zadjii-msft's guidance in the issue, this PR updates
SettingsManager.cs to store Performance Monitor settings in an
extension-specific settings file:
performanceMonitor.settings.json
instead of the shared:
settings.json
This aligns the extension with the current Command Palette settings
architecture and prevents the network speed unit setting from being
overwritten.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
* Changed Network Speed Unit to "Binary bytes per second" in Performance
Monitor settings.
* Verified the setting was successfully saved to the newly created
`performanceMonitor.settings.json` file.
* Modified core Command Palette personalization settings.
* Verified the Performance Monitor setting was preserved and not
overwritten.
* Restarted PowerToys and verified the setting persisted correctly.
**Note to reviewers:** I left the "Tests" box unchecked because this is
a single-line file path configuration change. I did not add an automated
test, but I have thoroughly verified the fix manually as described in
the Validation steps above.
## Summary of the Pull Request
Fixes#48053 — Remote Desktop extension now allows connecting to
arbitrary hostnames when navigated into the extension's list page.
Previously, `RemoteDesktopListPage` only displayed previously saved
connections. This converts it from `ListPage` to `DynamicListPage`,
adding search-driven behavior:
- Typing a valid hostname/IP that **doesn't** match an existing saved
connection shows a **"Connect to {hostname}"** item at the top of the
list
- Typing something that **exactly matches** a saved connection shows
only the normal results (no duplicate arbitrary-host item)
- Typing an invalid string (not a valid hostname/IP) shows no
arbitrary-host item
The hostname validation reuses the same logic as
`FallbackRemoteDesktopItem`: strip the port suffix (e.g. `myhost:3389` →
`myhost`), then check `Uri.CheckHostName` against `IPv4`, `IPv6`, `Dns`.
## PR Checklist
- [x] Closes: #48053
- [ ] **Communication:** I've discussed this with core contributors
already.
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
---------
Co-authored-by: root <root@io.bbq>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
Rework the confirmation dialog shown when enabling Power Display (and
its potentially-destructive sub-features) so it is shorter, friendlier,
and consistent across all entry points. The five separate prefix-driven
variants are now a single `PowerDisplayWarningDialog` user control
selected via an enum, sharing the title, learn-more link, and
Enable/Cancel buttons. The previous hand-rolled red warning text is
replaced with a Fluent `InfoBar Severity=""Warning""`.
## PR Checklist
- [ ] Closes: #xxx
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
## Detailed Description of the Pull Request / Additional comments
### Before
- `DangerousFeatureWarningDialog` took a resource-key prefix string and
probed up to five optional keys per variant (`_WarningHeader`,
`_WarningConfirm`, `_WarningList_Item1/2`, etc.).
- Each of the five flows (EnableModule, ColorTemperature, PowerState,
InputSource, MaxCompatibility) had a slightly different title (some
questions, some statements, mixed `Warning:` prefixes) and a hand-rolled
red `TextBlock` warning header with a `⚠️` emoji and
`SystemFillColorCriticalBrush`.
- ~30 fragmented `PowerDisplay_*_Warning*` resw keys.
### After
- New `PowerDisplayWarningDialog` selected via `PowerDisplayWarningKind`
enum (`EnableModule`, `ColorTemperature`, `PowerState`, `InputSource`,
`MaxCompatibility`).
- Shared chrome lives in the control:
- Single title `Before you continue` for every variant.
- `InfoBar Severity=""Warning""` replaces the hand-rolled red header.
- Learn-more `HyperlinkButton` pointing at
`aka.ms/powerToysOverview_PowerDisplay_Note` (URL is a `private const`
so translators don't see it).
- Consistent Enable / Cancel buttons.
- Per-variant content collapses to one InfoBar message + one body
paragraph in resw (12 keys total, down from ~30). Bullets are inlined as
`• ` + newlines with `xml:space=""preserve""`.
- `PowerDisplayViewModel.ConfirmDangerousFeatureAsync` and
`TryCommitDangerousChangeAsync` now take the enum instead of a magic
string.
### Files
- **Added:** `ViewModels/PowerDisplayWarningKind.cs`,
`SettingsXAML/Views/PowerDisplayWarningDialog.xaml{,.cs}`
- **Removed:**
`SettingsXAML/Views/DangerousFeatureWarningDialog.xaml{,.cs}`
- **Updated:** `Strings/en-us/Resources.resw`,
`ViewModels/PowerDisplayViewModel.cs`,
`SettingsXAML/Views/PowerDisplayPage.xaml.cs`
## Validation Steps Performed
- Built `PowerToys.Settings.csproj` (Debug arm64) — clean.
- Manually exercised the EnableModule and MaxCompatibility flows;
verified the new title, InfoBar, body paragraph, learn-more link, and
Enable/Cancel button behavior.
- Verified `aka.ms/powerToysOverview_PowerDisplay_Note` opens in the
default browser.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
Make the new WinUI 3 Keyboard Manager editor the default by flipping
`useNewEditor` from `false` to `true` everywhere a default is supplied.
## Behavior
- **New installs / new `settings.json`** → new editor enabled
- **Upgrades from a version before the `useNewEditor` key existed** →
new editor enabled (the key is missing, so the default kicks in)
- **Users who have explicitly toggled the setting** → unchanged (we only
change the default, not stored values)
- The "Go back to classic" button in the KBM settings page is untouched
## Changes
- `src/settings-ui/Settings.UI.Library/KeyboardManagerProperties.cs` —
`UseNewEditor` property initializer now `true`
- `src/modules/keyboardmanager/dll/dllmain.cpp` — `m_useNewEditor`
member init + `GetNamedBoolean` fallback now `true`; warn-log message
updated to match
-
`src/modules/cmdpal/ext/Microsoft.CmdPal.Ext.PowerToys/Modules/KeyboardManagerModuleCommandProvider.cs`
— both fallback paths in `IsUseNewEditorEnabled` (file missing /
unreadable) now return `true`, so the "Open New Editor" CmdPal command
surfaces by default
## Validation
Built locally on ARM64 Debug (exit code 0):
- `src/modules/keyboardmanager/dll`
- `src/modules/cmdpal/ext/Microsoft.CmdPal.Ext.PowerToys`
- `src/settings-ui/Settings.UI.Library`
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
Reword the Shortcut Guide module description and OOBE description so
they describe the feature without referring to `your apps`. The module
description now reads as a single sentence covering Windows and the
active app; the OOBE description is shortened to one paragraph and
refers to `various applications` instead of enumerating the bundled
apps.
## PR Checklist
- [ ] Closes: #xxx
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
## Detailed Description of the Pull Request / Additional comments
Two strings in
`src/settings-ui/Settings.UI/Strings/en-us/Resources.resw` changed:
- `ShortcutGuide.ModuleDescription` — now: `Shows an on-screen overlay
of keyboard shortcuts for Windows and the active application.`
- `Oobe_ShortcutGuide.Description` — collapsed to one sentence
describing Windows + various applications, no longer enumerating bundled
apps or mentioning future additions.
No code or behavioral changes.
## Validation Steps Performed
- Built Settings.UI (Debug arm64) – clean.
- Verified the Shortcut Guide module card in Settings UI shows the new
description and the OOBE Shortcut Guide page shows the new paragraph.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
## Summary
Fixes#46055 — Standardizes built-in fallback title/subtitle format so
scoring is consistent across all action fallbacks.
## Problem
`MainListPage.cs` scores fallback items by fuzzy-matching the query
against both Title and Subtitle, but with different weights:
- `nameScore = FuzzyScore(query, Title)`
- `descriptionScore = (FuzzyScore(query, Subtitle) - 4) / 2`
Fallbacks that embedded the raw query in Title got artificially higher
scores than those using Subtitle. This made ranking unpredictable.
## Fix
All "action" fallbacks now follow a consistent pattern:
- **Title** = static action description (no query text)
- **Subtitle** = raw query string (unquoted)
"Result" fallbacks (that found a specific matched item) are left
unchanged — they correctly show the matched item name in Title.
## Full Fallback Audit (example query: `notepad`)
| Fallback | Title | Subtitle | Status |
|---|---|---|---|
| WebSearch: Search | "Search the web with Edge" | `Search for notepad`
| **Changed** — was `Search for "notepad"` in subtitle |
| WebSearch: Open URL | "Open in Microsoft Edge" | `Open notepad.com` |
**Changed** — was `Open "notepad.com"` in title |
| Shell: Run | "Run" | `notepad` | Unchanged — already correct |
| Calculator | "3" (result) | `1+2` (query) | Unchanged — intentional
exception |
| Indexer: single result | "notepad.exe" | `C:\Windows\notepad.exe` |
Unchanged — result fallback |
| Indexer: multiple results | "File search" | `Search for notepad in
files` | **Changed** — was `Search for "notepad" in files` in title |
| Windows Settings: single | "Notepad settings" | `Settings > Apps` |
Unchanged — result fallback |
| Windows Settings: multiple | "Search Windows settings..." | `Search
for notepad` | **Changed** — was `Search for "notepad" in Windows
settings` in title |
| Remote Desktop: exact match | "MyPC" (connection) | "Connect to MyPC"
| Unchanged — result fallback |
| Remote Desktop: arbitrary host | "Remote Desktop" | `Connect to
notepad-host` | **Changed** — was `Connect to notepad-host` in title |
| TimeDate | "Monday, May 23" (result) | "Current date" | Unchanged —
result fallback |
| System | "Shut down" (result) | "Shuts down the computer" | Unchanged
— result fallback |
| PowerToys | "Color Picker" (static) | "Pick a color..." | Unchanged —
result fallback |
## Changes
- `FallbackExecuteSearchItem.cs` — Subtitle uses raw query instead of
`"Search for \"{query}\""` format
- `FallbackOpenURLItem.cs` — Title shows browser name (was query),
Subtitle shows raw query (was browser)
- `FallbackOpenFileItem.cs` — Multi-result: Title is static display
name, Subtitle is raw query
- `FallbackWindowsSettingsItem.cs` — Multi-result: Title is static
description, Subtitle is raw query
- `FallbackRemoteDesktopItem.cs` — Arbitrary host: Title is static
"Remote Desktop", Subtitle is raw query
---------
Co-authored-by: root <root@io.bbq>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
When an extension updates its `Subtitle` property asynchronously after
initial render, the `TextVisibilityStates` visual state group
transitions from `TitleOnly` → `TextVisible`. This transition sets
`SubtitleText.Visibility = Visible`, overriding the `CompactStates`
setter that had hidden it.
## Fix
Added `control.UpdateCompactState()` to `OnTextPropertyChanged` in
`DockItemControl.xaml.cs`. This re-applies the compact state after any
text property change. When `IsCompact` is `false`, `UpdateCompactState`
is a no-op — no behavior change for the non-compact path.
Fixes#47980
Co-authored-by: root <root@io.bbq>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
Fixes#47939
The Performance Monitor dock band displayed network stats as Receive →
Send, but Task Manager shows Send → Receive. This swaps the order to
match Task Manager.
## Changes
- `PerformanceWidgetsPage.cs`: Swap `_networkUpItem` (Send) before
`_networkDownItem` (Receive) in the band items array.
Co-authored-by: root <root@io.bbq>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
When a keyboard shortcut opens CmdPal to an extension while the palette
is already showing a dock-launched transient page, `GoHome(false)`
cannot restore the root page — the frame's back stack is empty because
the transient dock page was never pushed on top of root. The user ends
up with only the hotkey-target page in the frame with no way to navigate
back to the main list.
## Root Cause
In `ShellPage.SummonOnUiThread()`, the hotkey-to-page branch called
`GoHome(false)` before sending `ShowWindowMessage`. But when the active
page is a transient dock page, `_currentlyTransient` is still `true` and
the frame back stack is empty, so `GoHome` can't re-establish the root
page as the frame base.
## Fix
Added `ResetToHome()` to `ShellViewModel`, mirroring the pattern already
used in `WindowHiddenMessage` handling:
1. Clears `_currentlyTransient`
2. Calls `_rootPageService.GoHome()` to reset extension state
3. Sends `PerformCommandMessage` for `_rootPage` — navigating
MainListPage into the frame as the base
In `ShellPage.SummonOnUiThread()`, the `GoHome(false)` call in the
`isPage` branch is replaced with `ViewModel.ResetToHome()`. The root
page is then cleanly in the frame before the hotkey target's
`PerformCommandMessage` navigates on top of it.
Fixes#47994
Co-authored-by: root <root@io.bbq>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
Reorder the Pin to Dock dialog content so the configuration controls
(monitor selector, dock section, label options) appear at the top and
the live preview is shown below them. The user now configures the pin
first and sees the resulting preview directly underneath, instead of
staring at the preview and having to scan past it to find the controls.
<img width="515" height="440" alt="image"
src="https://github.com/user-attachments/assets/0d1d0543-2b30-48f5-a1aa-676a165870f5"
/>
## PR Checklist
- [ ] Closes: #xxx
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
## Detailed Description of the Pull Request / Additional comments
XAML-only change to
`src/modules/cmdpal/Microsoft.CmdPal.UI/Dock/PinToDockDialogContent.xaml`.
The new visual order inside the `ScrollViewer`/`StackPanel` is:
1. Monitor selector (still `Visibility=""Collapsed""` by default; shown
when more than one monitor is available)
2. Dock section `Segmented` (Start / Center / End)
3. Label options (`Show title` / `Show subtitle` checkboxes)
4. Divider `Rectangle`
5. Preview `Border`
No logic, bindings, `x:Name` identifiers, event handlers, or `x:Uid`
keys are changed.
## Validation Steps Performed
- Built `Microsoft.CmdPal.UI` (Debug arm64) — clean.
- Verified the Pin to Dock dialog renders with controls on top and the
preview underneath; segmented selection, label-option checkboxes, and
the multi-monitor combo still behave as before.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
Fixes#47821
The GPU Performance Monitor widget crashes with
`IndexOutOfRangeException` on systems where GPU performance counters
fail to enumerate (common on Intel Arc and hybrid GPU configurations).
The dock band shows `???` and opening the flyout causes an error.
## Root Cause
`GPUStats.CreateGPUImageUrl()` accessed `_stats[index]` without bounds
checking. When `GetGPUPerfCounters()` finds no matching counter
instances, `_stats` remains empty but callers still pass index 0.
`GetGPUName()`, `GetGPUUsage()`, and `GetGPUTemperature()` already have
proper guards (`if (_stats.Count <= index) return ...`) — this fix adds
the same pattern to the one remaining unguarded method.
## Changes
- `GPUStats.cs`: Add bounds check to `CreateGPUImageUrl()` — return
empty string if index out of range
Co-authored-by: root <root@io.bbq>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Addenda to #47187
that fix only works if the _hwnd is already set. Actually it's crazy it
ever worked.
Tested by disconnecting and reconnecting RDP a couple times, which
pretty consistently reproduces the problem.
## Summary
Fixes#48170 — ShortcutGuide v2 crashes on launch when the bundled
`Manifests` directory is absent from the install path.
### Root Cause
The `Assets\ShortcutGuide\Manifests\*.yml` files were never reaching the
build output directory during the CI solution-level build (`msbuild
PowerToys.slnx /t:Build -graph`). The `CopyToOutputDirectory` metadata
on `<Content>` items does not reliably copy files to a shared
`OutputPath` in this build configuration. As a result, the WiX installer
generator found no yml files to package, and the installed product was
missing the Manifests directory entirely.
At runtime, `PowerToysShortcutsPopulator.Populate()` threw an unhandled
`FileNotFoundException` causing a crash loop.
### Fix (3 layers)
1. **Code resilience** (`Program.cs`, `PowerToysShortcutsPopulator.cs`):
- Wrap `Populate()` in try/catch so a missing manifest degrades
gracefully instead of crashing
- Add `File.Exists` guard before `File.ReadAllText`
2. **Build output** (`ShortcutGuide.Ui.csproj`):
- Add explicit `CopyManifestsToOutputDir` MSBuild target
(`AfterTargets="Build"`) that copies yml files to
`$(OutDir)Assets\ShortcutGuide\Manifests\` — same pattern as the
existing `CopyPRIFileToOutputDir` target
- Keep `<Content Include>` with `CopyToOutputDirectory` as a fallback
for publish scenarios
3. **Installer packaging** (`generateAllFileComponents.ps1`,
`ShortcutGuide.wxs`):
- Add `*.yml` to the file inclusion list
- Add `Generate-FileList` / `Generate-FileComponents` calls for
`ShortcutGuideManifestsFiles`
- Add WiX directory definition and `RemoveFolder` component for the
Manifests directory
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Converts the "Show details" context menu command into a toggle that
switches between "Show details" and "Hide details" with appropriate
icons, and fixes the icon not rendering in the context menu.
Address internal a11y bug.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
## Summary of the Pull Request
Adds **DiskAnalyzer** to the General plugins table in
`doc/thirdPartyRunPlugins.md`.
- **Plugin:**
[Community.PowerToys.Run.Plugin.DiskAnalyzer](https://github.com/thetsaw/PowerToys.Plugin)
- - **Author:** thetsaw
- - **Keyword:** `ds`
- - **License:** MIT
- - **Platforms:** x64 and ARM64
### What it does
Scan any folder or drive to find the largest files and subfolders, view
drive usage with visual progress bars, and navigate your filesystem all
from PowerToys Run.
## PR Checklist
- [x] Plugin has been publicly available
- [ ] - [x] MIT licensed
- [ ] - [x] Releases include x64 and ARM64 zips
- [ ] - [x] plugin.json is correctly formatted
- [ ] - [x] README includes install instructions
## Detailed Description
This is a documentation-only change adding one row to the third-party
plugins table. No source code, binaries, or build files are modified.
## Summary of the Pull Request
This updates PowerToys Settings to remove the obsolete “V2” suffix from
the Shortcut Guide module name. The UI now consistently shows **Shortcut
Guide**.
## PR Checklist
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
- **Settings navigation label**
- Updated `Shell_ShortcutGuide.Content` to `Shortcut Guide`.
- **Module title**
- Updated `ShortcutGuide.ModuleTitle` to `Shortcut Guide`.
- **OOBE title**
- Updated `Oobe_ShortcutGuide.Title` to `Shortcut Guide`.
```xml
<data name="Shell_ShortcutGuide.Content" xml:space="preserve">
<value>Shortcut Guide</value>
</data>
```
## Validation Steps Performed
- N/A for behavior-level validation in this description (change is
limited to localized display strings).
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
## Summary of the Pull Request
Both Power Display and Grab and Move have matured beyond their initial
release phase. This removes the "NEW" `InfoBadge` from their navigation
items in Settings, the two parent navigation groups (Windowing &
Layouts, Input / Output) that surfaced the badge when collapsed, and
clears the `IsNew` flag for Power Display in the OOBE shell.
<img width="1867" height="973" alt="image"
src="https://github.com/user-attachments/assets/533f271c-c70f-414f-a76a-43fd9ffbbd44"
/>
<img width="497" height="575" alt="image"
src="https://github.com/user-attachments/assets/fe1e97c3-c806-4f42-a836-76e042630d61"
/>
<img width="1619" height="1027" alt="image"
src="https://github.com/user-attachments/assets/f5db715b-bc69-4505-803a-18a9b2716280"
/>
## PR Checklist
- [x] Closes: #48153
- [x] **Communication:** Tracked by the linked issue
- [x] **Tests:** Markup-only change; Settings.UI builds clean with WinUI
markup compiler (no XAML errors)
- [x] **Localization:** No end-user-facing strings changed
- [ ] **Dev docs:** N/A
- [ ] **New binaries:** N/A
- [ ] **Documentation updated:** N/A
## Detailed Description of the Pull Request / Additional comments
Files touched:
- `src/settings-ui/Settings.UI/SettingsXAML/Views/ShellPage.xaml` —
removed four `<InfoBadge Style="{StaticResource NewInfoBadge}" />`
blocks on `GrabAndMoveNavigationItem`, `PowerDisplayNavigationItem`, and
on the two parent group headers `WindowingAndLayoutsNavigationItem` and
`InputOutputNavigationItem` (the parent badges existed only to surface a
NEW child when the group was collapsed; with no NEW children left in
those groups, the parent badges are now stale).
- `src/settings-ui/Settings.UI/OOBE/ViewModel/OobeShellViewModel.cs` —
flipped `(PowerToysModules.PowerDisplay, true)` to
`(PowerToysModules.PowerDisplay, false)`. Grab and Move was already
`false`.
No other modules or strings affected.
## Validation Steps Performed
- Built `src\settings-ui\Settings.UI\PowerToys.Settings.csproj`
(Release|x64) with MSBuild from VS 18 Enterprise;
`PowerToys.Settings.dll` produced with 0 errors related to this change.
WinUI markup compiler would have aborted before producing the DLL if the
XAML had syntax issues.
- Diff inspected: only the five intended deletions/edits, no collateral
changes.
- Visual run-time verification of the Settings navigation pane is
recommended before merge.
Co-authored-by: Yu Leng <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Cooperative shutdowns of `PowerDisplay.exe` — Runner's `TerminateApp`
NamedPipe message, the `Terminate` named event, tray-quit, Runner-exit
detection, and PowerToys upgrades — all call `Environment.Exit(0)`
immediately. If DDC/CI discovery is mid-flight, that path skips the
`try/finally` that owns `CrashDetectionScope`, leaving `discovery.lock`
on disk. Phase 0 at the next `PowerDisplay.exe` startup then treats this
orphan as evidence of a real crash and auto-disables the module,
surfacing the "PowerDisplay has crashed" InfoBar in Settings UI.
This PR adds an `AppDomain.ProcessExit` safety-net inside
`CrashDetectionScope`. ProcessExit fires for `Environment.Exit` but
**not** for `FailFast` / BSOD / external `TerminateProcess` — exactly
the partition we need: cooperative exit → best-effort delete the lock;
involuntary kill → leave the lock for Phase 0 to detect (original design
intent preserved).
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #48169
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
<!-- no user-facing strings changed -->
- [x] **Dev docs:** Added/updated <!-- inline XML doc on
CrashDetectionScope explains the ProcessExit partition -->
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
### Root cause
`CrashDetectionScope.Begin()` writes `discovery.lock` before DDC/CI
capability fetch and `Dispose()` deletes it when the `using` block
exits. The lock is intentionally designed to survive any code path that
cannot run user-mode cleanup (BSOD, kernel OOM, `TerminateProcess`), so
that the next `PowerDisplay.exe` start can see it and run Phase 0 (write
`crash_detected.flag`, set `enabled.PowerDisplay=false` in global
`settings.json`, signal `AutoDisablePowerDisplayEvent`).
The bug is that several **cooperative** shutdown paths route to
`Environment.Exit(0)` immediately:
| Path | Code |
|---|---|
| Runner's `TerminateApp` NamedPipe | `App.xaml.cs::OnNamedPipeMessage`
→ `Shutdown()` → `Environment.Exit(0)` |
| `Terminate` named event | `App.xaml.cs::OnLaunched` →
`RegisterEvent(..., () => Environment.Exit(0), "Terminate")` |
| Tray-quit | `TrayIconService` callback → `Environment.Exit(0)` |
| Runner-exit detection | `RunnerHelper.WaitForPowerToysRunner` callback
→ `Environment.Exit(0)` |
`Environment.Exit` calls `ExitProcess` under the hood, which terminates
all threads abruptly. Background `Task.WhenAll` doing DDC capability
fetch is killed mid-flight; the `finally` block that calls
`scope.Dispose()` never runs; `discovery.lock` orphans; Phase 0 next
time false-positives.
Concrete repro from logs:
- `15:08:42.510` lock written
- `15:08:42.79` probe monitor #1
- `15:08:46.92` probe monitor #2 (started, not finished — typical probe
takes ~5s)
- `15:08:49.03` `TerminateApp` received → `Environment.Exit(0)` → no
`Dispose` log line
- `15:10:10.03` next startup: Phase 0 sees orphan lock with `pid:17712,
startedAt:2026-05-28T07:08:42Z` → writes `crash_detected.flag` →
auto-disables
### Fix
`CrashDetectionScope.Begin()` now also subscribes to
`AppDomain.CurrentDomain.ProcessExit`. The handler does a best-effort
`File.Delete(_lockPath)` (swallowing exceptions, as required for
ProcessExit handlers). `Dispose()` unsubscribes before deleting. An
`Interlocked.Exchange` guards the race between Dispose and ProcessExit
so only one of the two performs the delete.
ProcessExit's semantics match the cooperative/involuntary partition
exactly:
| Shutdown path | ProcessExit fires? | Behavior after this PR |
|---|---|---|
| `Environment.Exit(code)` (all 4 paths above) | yes | lock deleted by
handler |
| `Environment.FailFast` | no | lock survives → Phase 0 catches it
(correct: explicit FailFast = real failure) |
| BSOD / external `TerminateProcess` / kernel OOM | no | lock survives →
Phase 0 catches it (correct: original design) |
| Discovery completes normally / throws | n/a | `try/finally` calls
`Dispose()` as before; handler unsubscribed first |
### Testability
A new `IProcessExitHook` interface abstracts the subscription so unit
tests can simulate ProcessExit without terminating the test runner.
Production code uses the default `AppDomainProcessExitHook` singleton;
tests inject a fake whose `RaiseExit()` invokes subscribed handlers
synchronously.
### Files touched
-
`src/modules/powerdisplay/PowerDisplay.Lib/Services/IProcessExitHook.cs`
*(new)* — interface + production singleton
-
`src/modules/powerdisplay/PowerDisplay.Lib/Services/CrashDetectionScope.cs`
— subscribe in `Begin`, unsubscribe in `Dispose`, add `OnProcessExit`
handler, expanded class doc
-
`src/modules/powerdisplay/PowerDisplay.Lib.UnitTests/CrashDetectionScopeTests.cs`
*(new)* — 10 unit tests
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
### Automated
10 new unit tests in `CrashDetectionScopeTests`, all passing:
```
Passed Begin_WritesLockFileAtomically
Passed Begin_SubscribesToProcessExit
Passed Dispose_UnsubscribesFromProcessExit
Passed Dispose_DeletesLockFile
Passed ProcessExitFired_BeforeDispose_DeletesLock (core scenario)
Passed ProcessExitFired_AfterDispose_DoesNothing
Passed Dispose_AfterProcessExit_DoesNotThrow
Passed ProcessExitFired_LockFileMissing_DoesNotThrow
Passed Dispose_IsIdempotent
Passed MultipleScopes_DoNotShareState
```
Full `PowerDisplay.Lib.UnitTests` suite: **129 / 132 passing**. The 3
failures (`DetectOrphanAndDisable_RunsFullSequenceWhenOrphanPresent`,
`DetectOrphanAndDisable_HandlesUnknownVersionAsOrphan`,
`DetectOrphanAndDisable_LeavesLockIntactOnSignalFailure`) are
**pre-existing on `main`** — they fail with `REGDB_E_CLASSNOTREG` from
`Constants.AutoDisablePowerDisplayEvent()` (WinRT activation factory not
COM-registered in the test environment). Verified by stashing this PR's
changes and re-running the same 3 tests on baseline `main` — same
failures, same cause, unrelated to this change.
### Manual
1. Reproduced the original false-positive on `main`:
- Enable PowerDisplay → open Settings UI → quickly toggle PowerDisplay
off
- Observe `discovery.lock` left in
`%LOCALAPPDATA%\Microsoft\PowerToys\PowerDisplay\`
- Re-enable PowerDisplay → Phase 0 writes `crash_detected.flag` →
InfoBar appears
2. Repeated the same steps with this branch:
- Toggling PowerDisplay off cleanly deletes `discovery.lock`
(ProcessExit handler ran)
- Re-enabling PowerDisplay shows no InfoBar, no `crash_detected.flag`
created
3. BSOD path is unchanged (verified by inspecting the conditional logic
— `AppDomain.ProcessExit` does not fire for involuntary terminations;
the lock survives just as before).
---------
Co-authored-by: Yu Leng <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary of the Pull Request
Renames the OOBE welcome/overview hyperlink label from **“Documentation
on Microsoft Learn”** to **“Documentation”** for brevity and
consistency.
Scope is limited to the localized string resource used by the OOBE
overview page.
## PR Checklist
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
- **Resource update (OOBE Overview)**
- Updated `Oobe_Overview_DescriptionLinkText.Text` in
`src/settings-ui/Settings.UI/Strings/en-us/Resources.resw`.
```xml
<data name="Oobe_Overview_DescriptionLinkText.Text" xml:space="preserve">
<value>Documentation</value>
</data>
```
## Validation Steps Performed
- Confirmed the OOBE overview string key now resolves to
**“Documentation”**.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
## Summary of the Pull Request
Return a friendly calculator error when Mages evaluates an expression to
a complex number instead of letting decimal conversion throw.
This fixes the PowerToys Run Calculator result for expressions such as
`sqrt(-1)` by detecting `System.Numerics.Complex` results before decimal
conversion and showing a localized error message instead.
Fixes#43937
## PR Checklist
- [x] Closes: #43937
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [x] **Dev docs:** Added/updated
- [x] **New binaries:** Added on the required places
- [x] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [x] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [x] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [x] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [x] **Documentation updated:** Not required for this bug fix.
## Detailed Description of the Pull Request / Additional comments
The Calculator plugin previously passed complex results from Mages into
`Convert.ToDecimal`, which caused an exception for expressions like
`sqrt(-1)`.
This PR updates the calculator result transformation logic to detect
`System.Numerics.Complex` and return a localized user-facing error
message: `Complex numbers are not supported`.
It also updates calculator query tests to cover both direct keyword and
global query behavior.
## Validation Steps Performed
- Added unit test coverage for `=sqrt(-1)` returning `Complex numbers
are not supported`.
- Added unit test coverage for global query `sqrt(-1)` returning no
result instead of surfacing an unhandled exception.
- Ran `git diff --check`.
- Attempted local build/test with the PowerToys build scripts, but local
validation was blocked by Visual Studio/VC tooling configuration issues
unrelated to this change: `PlatformToolsetVersion` resolves to an empty
value during restore/build.
This removes our last git submodule dependency!
We were using `expected-lite` in one place, which was being compiled out
_anyway_ in favor of using `std::expected`.
## Summary
Migrate `deps/spdlog` from a git submodule to **vcpkg manifest mode**
with an overlay port pinned to the **exact same commit**
(`gabime/spdlog@616866fc`). Replaces the polyfill shim added in #47910
with a proper port-level patch.
This is the follow-up to PR #47928, which I closed after @zadjii-msft /
@DHowett clarified that the intended direction was a single combined
"move to vcpkg **and** apply a patch file" (one change, not two stepping
stones).
## Guidance honored
Per @zadjii-msft (offline):
- ✅ Convert each submodule to vcpkg **one at a time** — this PR is
**spdlog only**. `deps/expected-lite` stays a submodule (separate PR
next).
- ✅ Atomic commit per dep (multiple commits on the branch for review
traceability; squash on merge gives the requested single commit).
- ✅ **Don't bump the version.** Only variable changed: submodule →
vcpkg. Same commit (`616866fc`, v1.8.5 + 38) the submodule pointed at.
Per @DHowett
([review](https://github.com/microsoft/PowerToys/pull/48039#pullrequestreview-4338835150)):
- ✅ No vcpkg submodule — vswhere-first detection via a Terminal-style
`steps-install-vcpkg.yml` template; three-tier `VcpkgRoot` fallback (env
var → VS-shipped → runtime clone pinned to manifest baseline).
## Design
- **Repo-root manifest**: `vcpkg.json` declares only `spdlog`, with
`builtin-baseline` pinned. `vcpkg-configuration.json` registers
`deps/vcpkg-overlays/` as overlay-ports.
- **Overlay port** `deps/vcpkg-overlays/spdlog/`: `vcpkg_from_github(REF
616866fc...)` with bundled fmt preserved (`-DSPDLOG_FMT_EXTERNAL=OFF`);
the MSVC 14.51 fix from #47910 carried as a proper vcpkg patch on
`include/spdlog/fmt/bundled/format.h`.
- **vcpkg integration is global** (set in `Cpp.Build.props`, imported
via `ForceImportBeforeCppProps` for every `.vcxproj`). An earlier
attempt to make vcpkg per-project-opt-in via `deps/spdlog.props` failed
because ~85 PowerToys `.vcxproj` files import `spdlog.props` AFTER
`Microsoft.Cpp.targets`, by which point `vcpkg.props`' `ClCompile` hook
is dead-on-arrival. The trade-off (every C++ project invokes `vcpkg
install` once at build time, ~0.5 s on cache hits, manifest declares
only spdlog so install set is fixed) is documented in the expanded
`Cpp.Build.props` comment.
- **`deps/spdlog.props`** is now a thin shim that only sets the
historical `SPDLOG_*` preprocessor defines for source-compat.
- **`Cpp.Build.targets`** is a new file imported via
`ForceImportAfterCppTargets` to load `vcpkg.targets` after
`Microsoft.Cpp.targets`. A fail-fast `<Target>` errors with a clear
message if `vcpkg.props` can't be found at the resolved `VcpkgRoot`.
- **Removes** `deps/spdlog-msvc-fix/` polyfill, in-tree wrapper
`src/logging/`, spdlog submodule, the single `<ProjectReference>` in
`logger.vcxproj`, plus 3 `.slnf` refs and 2 `.slnx` refs
(`PowerToys.slnx` + `installer/PowerToysSetup.slnx`), plus 3 hard-coded
`..\deps\spdlog\include` entries in `<AdditionalIncludeDirectories>`.
- **CI**: new reusable `.pipelines/v2/templates/steps-install-vcpkg.yml`
(vswhere-first, manifest-baseline-pinned fallback clone, respects
`useVSPreview`). Gated `Cache@2` for `%LOCALAPPDATA%\vcpkg\archives`
keyed on overlay-port contents. Same vcpkg detection added to
`tools\build\build-essentials.ps1` for local devs.
## Verification
Local build matrix (all 4 configs of `logger.vcxproj` and a
representative late-import consumer):
| Config | Result | Notes |
|--------|--------|-------|
| Release \| x64 | ✅ | vcpkg install ~21 s, `logger.lib` produced |
| Debug \| x64 | ✅ | **Validates patch fixes the actual MSVC 14.51 bug**
(`_ITERATOR_DEBUG_LEVEL > 0` → `_SECURE_SCL`) |
| Release \| ARM64 | ✅ | vcpkg cross-installs `arm64-windows-static`
spdlog in ~16 s |
| Debug \| ARM64 | ✅ | **Previously DISABLED for the in-tree spdlog**
(per `<Build Solution="Debug\|ARM64" Project="false" />` in
`PowerToysSetup.slnx`); this migration FIXES that latent gap |
| FancyZonesLib (Release \| x64) | ✅ | Late-import-pattern consumer;
previously broke in v2 |
Full PowerToys CI (x64 + arm64 + CmdPal SDK + all GitHub Actions checks)
green.
**Consumer audit**: 72 `.vcxproj` files reference `logger.vcxproj`; all
72 also import `deps/spdlog.props`. No transitive-link breakage.
## Out of scope (intentional)
- `deps/expected-lite` migration — next PR per "one-at-a-time" rule.
- Remote vcpkg binary cache (Azure Artifacts NuGet feed). Local pipeline
`Cache@2` works for now, but a remote feed survives across pipelines and
is the long-term answer. Happy to split this into a follow-up.
## Notes for review
- Patch in the overlay port is identical content to PR #47928's patch
but regenerated with LF line endings (vcpkg's `vcpkg_apply_patches` is
strict; no `--ignore-whitespace`).
- Once PowerToys eventually bumps spdlog past v1.14 (which ships fmt
10.2 and drops the affected code path), the overlay port can be deleted
and we can use upstream vcpkg's `spdlog` directly.
- Re. official-release pipelines and terrapin / less-restricted network
isolation: VS-shipped vcpkg is the primary path (no network); the
fallback clone is only exercised when VS doesn't ship vcpkg. Happy to
wire terrapin into the fallback as a follow-up if the official build
template needs it.
Closes the work tracked in #47928 (which was closed unmerged).
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Dustin L. Howett <dustin@howett.net>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Some focussed refactoring / simplifying / cleanup / delinting on the
Mouse Without Borders codebase (see [#44508 - [Mouse Without Borders] -
de-linting
codebase](https://github.com/microsoft/PowerToys/issues/44508)) now that
the Common class has been broken down.
This PR does some cleaning up on the ```Logger``` class:
* Uplifting coding style (string interpolation, pattern matching,
```var```, etc)
* Rationalising and simplifying code
* Relocating e.g. IO and UI side effects (writing to disk, displaying
dialog boxes) outside of Logger class
* Removing dead code, tightening visibility of existing code
* Added / updated tests to try to cover as much of the refactoring as
possible to prevent regressions
I've split the changes into lots of small commits - it might be easier
to review the individual commits rather than the whole PR in one go.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
### Run manual tests from [Test Checklist
Template](5bc7201ae2/doc/releases/tests-checklist-template.md (mouse-without-borders)):
* Install PowerToys on two PCs in the same local network:
- [x] Verify that PowerToys is properly installed on both PCs.
- [x] Configure Windows Firewall Rules
- ```netsh advfirewall firewall add rule
name="PowerToys.MouseWithoutBorders - mc" dir=in action=allow
program="C:\src\mc\PowerToys\x64\Debug\PowerToys.exe" enable=yes
remoteip=any profile=any protocol=tcp```
* Setup Connection:
- [x] Open MWB's settings on the first PC and click the "New Key"
button. Verify that a new security key is generated.
- [x] Copy the generated security key and paste it in the corresponding
input field in the settings of MWB on the second PC. Also enter the name
of the first PC in the required field.
- [x] Press "Connect" and verify that the machine layout now includes
two PC tiles, each displaying their respective PC names.
* Verify Connection Status:
- [x] Ensure that the border of the remote PC turns green, indicating a
successful connection.
- [x] Enter an incorrect security key and verify that the border of the
remote PC turns red, indicating a failed connection.
* Test Remote Mouse/Keyboard Control:
- [x] With the PCs connected, test the mouse/keyboard control from one
PC to another. Verify that the mouse/keyboard inputs are correctly
registered on the other PC.
- [ ] Test remote mouse/keyboard control across all four PCs, if
available. Verify that inputs are correctly registered on each connected
PC when the mouse is active there.
- unable to test - only 2 machines available
* Test Remote Control with Elevated Apps:
- note - the main PowerToys.exe must be running as a **non**-admin for
these tests
- [x] Open an elevated app on one of the PCs. Verify that without "Use
Service" enabled, PowerToys does not control the elevated app.
- [x] Enable "Use Service" in MWB's settings (need to run PowerToys.exe
as admin to enable "Use Service", then restart PowerToys.exe as
non-admin). Verify that PowerToys can now control the elevated app
remotely. Verify that MWB processes are running as LocalSystem, while
the MWB helper process is running non-elevated.
- ```get-process -Name "PowerToys.MouseWithoutBorders*" -IncludeUserName
| format-table Id, ProcessName, UserName```
- [x] Process: ```PowerToys.MouseWithoutBorders.exe``` - running as
```SYSTEM```
- [x] Process: ```PowerToys.MouseWithoutBorders.Helper.exe``` - running
as current user
- ```get-service -Name "PowerToys.*" | ft Status, Name, UserName;
get-ciminstance -Class "Win32_Service" -Filter "Name like 'PowerToys%'"
| ft ProcessId, Name```
- [ ] Service: ```PowerToys.MWB.Service``` - running as ```Local
System```
- [x] Toggle "Use Service" again, verify that each time you do that, the
MWB processes are restarted.
- [ ] Run PowerToys elevated on one of the machines, verify that you can
control elevated apps remotely now on that machine.
* Test Module Enable Status:
- [ ] For all combinations of "Use Service"/"Run PowerToys as admin",
try enabling/disabling MWB module and verify that it's indeed being
toggled using task manager.
* Test Disconnection/Reconnection:
- [ ] Disconnect one of the PCs from network. Verify that the machine
layout updates to reflect the disconnection.
- [ ] Do the same, but now by exiting PowerToys.
- [ ] Start PowerToys again, verify that the PCs are reconnected.
* Test Various Local Network Conditions:
- [ ] Test MWB performance under various network conditions (e.g., low
bandwidth, high latency). Verify that the tool maintains a stable
connection and functions correctly.
* Clipboard Sharing:
- [ ] Copy some text on one PC and verify that the same text can be
pasted on another PC.
- [ ] Use the screenshot key and Win+Shift+S to take a screenshot on one
PC and verify that the screenshot can be pasted on another PC.
- [ ] Copy a file in Windows Explorer and verify that the file can be
pasted on another PC. Make sure the file size is below 100MB.
- [ ] Try to copy multiple files and directories and verify that it's
not possible (only the first selected file is being copied).
* Drag and Drop:
- [ ] Drag a file from Windows Explorer on one PC, cross the screen
border onto another PC, and release it there. Verify that the file is
copied to the other PC. Make sure the file size is below 100MB.
- [ ] While dragging the file, verify that a corresponding icon is
displayed under the mouse cursor.
- [ ] Without moving the mouse from one PC to the target PC, press
CTRL+ALT+F1/2/3/4 hotkey to switch to the target PC directly and verify
that file sharing/dropping is not working.
* Lock and Unlock with "Use Service" Enabled:
- [ ] Enable "Use Service" in MWB's settings.
- [ ] Lock a remote PC using Win+L, move the mouse to it remotely, and
try to unlock it. Verify that you can unlock the remote PC.
- [ ] Disable "Use Service" in MWB's settings, lock the remote PC, move
the mouse to it remotely, and try to unlock it. Verify that you can't
unlock the remote PC.
* Test Settings:
- [ ] Change the rest of available settings on MWB page and verify that
each setting works as described.
### Group Policy Tests
See https://learn.microsoft.com/en-us/windows/powertoys/grouppolicy
- [ ] Install *.admx / *.adml and check settings behave as expected
- [ ] I'll expand the list of settings here when I get this far :-)
- [ ] HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys
- [x] ConfigureEnabledUtilityMouseWithoutBorders
- [x] ```[missing]``` - "Activation -> Enable Mouse Without Borders"
enabled, with GPO warning hidden
- ```reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v
ConfigureEnabledUtilityMouseWithoutBorders /f```
- [x] ```0``` - "Activation -> Enable Mouse Without Borders" set to
"off" and disabled, with GPO warning visible
- ```reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v
ConfigureEnabledUtilityMouseWithoutBorders /t REG_DWORD /d 0 /f```
- [x] ```1``` - "Activation -> Enable Mouse Without Borders" set to "on"
and disabled, with GPO warning visible
- ```reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v
ConfigureEnabledUtilityMouseWithoutBorders /t REG_DWORD /d 1 /f```
- [ ] MwbClipboardSharingEnabled
- [ ] MwbFileTransferEnabled
- [ ] MwbUseOriginalUserInterface
- [ ] MwbDisallowBlockingScreensaver
- [ ] MwbSameSubnetOnly
- [ ] MwbValidateRemoteIp
- [x] MwbDisableUserDefinedIpMappingRules
- [x] ```[missing]``` - "Advanced Settings -> IP address mapping"
enabled, with GPO warning hidden
- ```reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v
MwbDisableUserDefinedIpMappingRules /f```
- [x] ```0``` - "Advanced Settings -> IP address mapping" enabled, with
GPO warning hidden
- ```reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v
MwbDisableUserDefinedIpMappingRules /t REG_DWORD /d 0 /f```
- [x] ```1``` - "Advanced Settings -> IP address mapping" disabled, with
GPO warning visible
- ```reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v
MwbDisableUserDefinedIpMappingRules /t REG_DWORD /d 1 /f```
- [x] MwbPolicyDefinedIpMappingRules
- [x] ```[missing]``` - "Advanced Settings -> IP address mapping"
enabled, with GPO warning and GPO values hidden
- ```reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v
MwbPolicyDefinedIpMappingRules /f```
- [x] ```[empty value]``` - "Advanced Settings -> IP address mapping"
enabled, with GPO warning hidden and GPO values hidden
- ```reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v
MwbPolicyDefinedIpMappingRules /t REG_MULTI_SZ /d "" /f```
- [x] ```[non-empty value]``` - "Advanced Settings -> IP address
mapping" enabled, with GPO warning visible and GPO values visible
- ```reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v
MwbPolicyDefinedIpMappingRules /t REG_MULTI_SZ /d "aaa 10.0.0.1\0bbb
10.0.0.2" /f```
Reopens the change from #46743 (which appears to be broken) on a fresh
branch.
Original author: @daverayment
## Summary
GitHub newcomers can be confused by the current duplicate resolution
message, as it doesn't clearly point to the original referenced issue -
see
https://github.com/microsoft/PowerToys/issues/46347#issuecomment-4103681050.
They may not realise that the #12345 in the duplicate comment is the
relevant link.
This small wording update to the duplicate resolution message tightens
up wording slightly and includes reference to the prior `/dup #nnn`
comment so newcomers don't miss it.
### Before
> Hi! We've identified this issue as a duplicate of another one that
already exists on this Issue Tracker. This specific instance is being
closed in favor of tracking the concern over on the referenced thread.
Thanks for your report!
### After
> We've identified this issue as a duplicate of an existing one and are
closing this thread so discussion stays in one place.<br/><br/>Please
see the comment above for the link to the original tracking issue, and
feel free to subscribe there for updates.
## Validation Steps Performed
N/A - bot reply text change only.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
On the Command Palette Performance Monitor extension's Network widget
page, the **Send** and **Receive** list items both used the generic
`NetworkIcon` (`\uEC05`), making them visually indistinguishable at a
glance.
This PR gives each direction its own glyph:
- Send → up arrow `\uE74A`
- Receive → down arrow `\uE74B`
The redundant `↑`/`↓` characters are removed from the Send/Receive
subtitles since the icons now carry that meaning.
Before vs after:
<img width="918" height="122" alt="image"
src="https://github.com/user-attachments/assets/4af3a2fc-d5a7-4fb5-98c6-f1889c7e80f2"
/>
## PR Checklist
- [x] **Closes:** N/A (no existing issue found)
- [x] **Communication:** I've discussed this with collaborators
- [x] **Tests:** Manually verified
- [x] **Localization:** Updated en-US resw (other locales still contain
the arrow characters and can be translated/updated by the loc pipeline)
## Detailed Description of the Pull Request / Additional comments
Files changed:
- `Icons.cs` – added `NetworkUpIcon` and `NetworkDownIcon`
- `PerformanceWidgetsPage.cs` – set `Icon` on `_networkUpItem` and
`_networkDownItem`
- `Strings/en-US/Resources.resw` – `Send ↑` → `Send`, `Receive ↓` →
`Receive`
## Validation Steps Performed
Local visual verification in Command Palette.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
`ToJsonFromXmlOrCsvAsync` in `AdvancedPaste/Helpers/JsonHelper.cs`
documents that it never throws and returns an empty string on any
failure. The clipboard read at the top of the method
(`clipboardData.GetTextAsync()`) was not wrapped, so a transient
clipboard failure could surface as an exception to callers, contrary to
the documented contract.
This PR:
- Wraps `GetTextAsync()` in a try/catch and returns `string.Empty` on
failure, matching the pattern already used by the JSON/XML/CSV parsing
branches further down in the same method.
- Updates the matching unit test to decode input bytes as UTF-8
(`Encoding.UTF8.GetString(input)`) and consume the awaited task via
`GetAwaiter().GetResult()`, for consistency with sibling tests elsewhere
in the solution.
## Validation
- Local build of `AdvancedPaste.sln`. (Note: my machine has a
pre-existing NuGet SDK resolver issue unrelated to this change — the
same baseline fails on `main` for me. CI should be the source of truth.)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
Adding information about using the Command Palette Visual Studio
solution filter based on
https://github.com/microsoft/PowerToys/issues/47997#issuecomment-4524045763.
## PR Checklist
- [ ] Closes: #47997
## Detailed Description of the Pull Request / Additional comments
I found this really useful and couldn't see a reference to it anywhere
else in the devdocs. Not sure if this is the best way to describe the
process, but I think adding this information somewhere in the debugging
doc would really help newcomers to CmdPal development!
## Summary of the Pull Request
Two crash-correlation aids for the kernel-side DDC/CI BSOD mitigated by
#47734:
1. Log EDID hardware ID (manufacturer + product code, e.g. `DELD1A8`)
during Phase 0 monitor classification, before any DDC/CI capability
fetch enters the BSOD risk window.
2. Show a confirmation dialog before turning the Power Display module on
from the Settings page, so the user understands the BSOD risk before the
first capability fetch runs.
## PR Checklist
- [ ] Closes: #xxx
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
### 1. Phase 0 EdidId logging
`MonitorIdentity.EdidIdFromDevicePath` parses the EDID hardware ID
segment from a DevicePath of the form
``\?\DISPLAY#DELD1A8#5&abc&0&UID12345#{guid}`` and returns ``DELD1A8``.
The 3-letter PNP manufacturer code + 4-hex product code is identical for
every physical unit of the same model, so it identifies the *model*
without leaking per-unit identifiers.
`MonitorManager` logs the EdidId on the existing Phase 0 classification
line. Phase 0 uses `QueryDisplayConfig`, which reads OS-cached EDID and
cannot BSOD, so this line is guaranteed on disk before the crash-prone
Phase 2 capability fetch starts. If a machine crashes during
enumeration, the recovered log identifies every attached model
(including same-model duplicates), which makes it possible to correlate
crash reports to specific monitor models even when the user can't tell
us which monitor caused the crash.
### 2. Enable-module confirmation dialog
`PowerDisplayViewModel.IsEnabled` setter is refactored to follow the
same two-phase pattern already used by `MaxCompatibilityMode`:
- `false → true` does not commit immediately; it kicks off
`ConfirmAndEnableModuleAsync`, which awaits the existing
`DangerousFeatureWarningDialog` (resource prefix
`PowerDisplay_EnableModule`) and either commits or reverts the
ToggleSwitch via `OnPropertyChanged`.
- `true → false` commits unconditionally — we never block a user who
wants to turn the module off.
- App-startup loads via `InitializeEnabledValue()` /
`RefreshEnabledState()` assign the `_isEnabled` field directly,
bypassing the setter, so the dialog never fires on settings restore or
GPO refresh.
- GPO-configured state still short-circuits before any dialog logic.
The dialog reuses the existing `DangerousFeatureWarningDialog` injected
by `PowerDisplayPage.xaml.cs`. The 5 new `PowerDisplay_EnableModule_*`
strings explain that the BSOD is in Windows (not Power Display), that
Power Display will auto-disable itself after a detected crash, and that
the user has to re-enable + dismiss the warning each time.
## Validation Steps Performed
- Built `src/settings-ui` and `src/modules/powerdisplay` locally.
- Unit tests: added `EdidIdFromDevicePath_*` cases to
`MonitorIdentityTests`, all green.
- Settings UI manual: toggling Power Display ON now shows the warning
dialog. Pressing Cancel reverts the ToggleSwitch visually; pressing
Enable commits and the module starts. Toggling OFF does not prompt.
Restarting Settings UI with PowerDisplay enabled does not prompt.
GPO-disabled state still locks the toggle.
- Log inspection: `MonitorManager` Phase 0 log now shows `EdidId=...`
for each path before any capability fetch.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary of the Pull Request
Two crash-correlation aids for the kernel-side DDC/CI BSOD mitigated by
#47734:
1. Log EDID hardware ID (manufacturer + product code, e.g. `DELD1A8`)
during Phase 0 monitor classification, before any DDC/CI capability
fetch enters the BSOD risk window.
2. Show a confirmation dialog before turning the Power Display module on
from the Settings page, so the user understands the BSOD risk before the
first capability fetch runs.
## PR Checklist
- [ ] Closes: #xxx
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
### 1. Phase 0 EdidId logging
`MonitorIdentity.EdidIdFromDevicePath` parses the EDID hardware ID
segment from a DevicePath of the form
``\?\DISPLAY#DELD1A8#5&abc&0&UID12345#{guid}`` and returns ``DELD1A8``.
The 3-letter PNP manufacturer code + 4-hex product code is identical for
every physical unit of the same model, so it identifies the *model*
without leaking per-unit identifiers.
`MonitorManager` logs the EdidId on the existing Phase 0 classification
line. Phase 0 uses `QueryDisplayConfig`, which reads OS-cached EDID and
cannot BSOD, so this line is guaranteed on disk before the crash-prone
Phase 2 capability fetch starts. If a machine crashes during
enumeration, the recovered log identifies every attached model
(including same-model duplicates), which makes it possible to correlate
crash reports to specific monitor models even when the user can't tell
us which monitor caused the crash.
### 2. Enable-module confirmation dialog
`PowerDisplayViewModel.IsEnabled` setter is refactored to follow the
same two-phase pattern already used by `MaxCompatibilityMode`:
- `false → true` does not commit immediately; it kicks off
`ConfirmAndEnableModuleAsync`, which awaits the existing
`DangerousFeatureWarningDialog` (resource prefix
`PowerDisplay_EnableModule`) and either commits or reverts the
ToggleSwitch via `OnPropertyChanged`.
- `true → false` commits unconditionally — we never block a user who
wants to turn the module off.
- App-startup loads via `InitializeEnabledValue()` /
`RefreshEnabledState()` assign the `_isEnabled` field directly,
bypassing the setter, so the dialog never fires on settings restore or
GPO refresh.
- GPO-configured state still short-circuits before any dialog logic.
The dialog reuses the existing `DangerousFeatureWarningDialog` injected
by `PowerDisplayPage.xaml.cs`. The 5 new `PowerDisplay_EnableModule_*`
strings explain that the BSOD is in Windows (not Power Display), that
Power Display will auto-disable itself after a detected crash, and that
the user has to re-enable + dismiss the warning each time.
## Validation Steps Performed
- Built `src/settings-ui` and `src/modules/powerdisplay` locally.
- Unit tests: added `EdidIdFromDevicePath_*` cases to
`MonitorIdentityTests`, all green.
- Settings UI manual: toggling Power Display ON now shows the warning
dialog. Pressing Cancel reverts the ToggleSwitch visually; pressing
Enable commits and the module starts. Toggling OFF does not prompt.
Restarting Settings UI with PowerDisplay enabled does not prompt.
GPO-disabled state still locks the toggle.
- Log inspection: `MonitorManager` Phase 0 log now shows `EdidId=...`
for each path before any capability fetch.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary of the Pull Request
The File Locksmith IPC layer reads and writes raw UTF-16 (WCHAR) bytes
to `last-run.log`, but all three stream opens were using the default
text mode. On Windows, the CRT translates `0x0A` bytes to `0x0D 0x0A` on
write and collapses `0x0D 0x0A` back to `0x0A` on read. Because each
WCHAR is 2 bytes, any code unit whose little-endian byte pair contains
`0x0A` in the low position (e.g. `U+010A`, `U+0A0D`) is silently
corrupted. The fix opens all three streams in binary mode and adds an
explicit open-failure guard.
```cpp
// IPC.cpp — Writer::start()
// Before
m_stream = std::ofstream(path);
// After
m_stream = std::ofstream(path, std::ios::binary);
// + is_open() guard returning E_FAIL on failure
// NativeMethods.cpp — StartAsElevated() writer
// Before
std::ofstream stream(paths_file());
// After
std::ofstream stream(paths_file(), std::ios::binary);
// NativeMethods.cpp — ReadPathsFromFile() reader
// Before
std::ifstream stream(paths_file());
// After
std::ifstream stream(paths_file(), std::ios::binary);
```
## PR Checklist
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
Three targeted changes across two files:
1. **`FileLocksmithLib/IPC.cpp` — `Writer::start()`**: switched
`std::ofstream` from text to binary mode and added an `is_open()` check
that returns `E_FAIL` immediately when the file cannot be opened
(previously the try/catch did not catch a silent open failure because
`std::ofstream` does not throw by default).
2. **`FileLocksmithLibInterop/NativeMethods.cpp` —
`StartAsElevated()`**: switched `std::ofstream` from text to binary
mode. This is the elevated-restart writer path; without this fix,
Unicode corruption persisted when File Locksmith relaunched as
administrator.
3. **`FileLocksmithLibInterop/NativeMethods.cpp` —
`ReadPathsFromFile()`**: switched `std::ifstream` from text to binary
mode. This is the symmetric reader-side bug — even with both writers
corrected, the CRT text-mode reader could collapse a `0x0D 0x0A` byte
pair (a valid UTF-16 LE code unit, e.g. U+0A0D GURMUKHI EK ONKAR) into a
single byte, desynchronising the 2-bytes-at-a-time read loop and
corrupting all subsequent path data.
No behaviour change for purely ASCII paths. Paths containing Unicode
code points whose little-endian UTF-16 byte pair spans `0x0D 0x0A` were
silently corrupted in all three code paths before this fix.
## Validation Steps Performed
- Code review: no issues flagged.
- Full diff reviewed: all three stream opens (`ofstream` writer in
`IPC.cpp`, `ofstream` writer in `NativeMethods.cpp`, `ifstream` reader
in `NativeMethods.cpp`) now use `std::ios::binary`, making write and
read paths byte-exact and symmetric.
- Mechanically correct: `std::ios::binary` suppresses Windows CRT
`\n`↔`\r\n` translation; the delimiter `L'\n'` (LE bytes `0x0A 0x00`) is
unambiguous in binary mode and is handled correctly by the existing read
loop.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: MuyuanMS <116717757+MuyuanMS@users.noreply.github.com>
Co-authored-by: Muyuan Li (from Dev Box) <muyuanli@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Problem
Since #47119 (`Refresh check-spelling 0.0.26`, merged 2026-04-23)
refreshed the check-spelling tooling and rewrote
`.github/actions/spell-check/expect.txt` (938 lines / 633 deletions),
the check-spelling bot has been leaving a noisy advisory comment on
**every PR**:
> #### These words are not needed and should be removed
> ABlocked AClient AColumn ACR ADate ADifferent AHybrid ALarger
AModifier ANull AOklab APeriod ARandom ARemapped ASingle ASUS bck …
The same ~150-word list is appended verbatim to every PR the bot looks
at (verified against #48058, #48102, #48104 — the list is identical).
These tokens are residual orphans in `expect.txt` from before the 0.0.26
refresh and no longer match anything in source.
## Fix
Removes exactly the 147 orphan tokens that the bot has consistently
flagged as `now absent` from `.github/actions/spell-check/expect.txt`.
The removed tokens are exclusively the ones the bot itself identified.
All uppercase Win32 / DirectWrite identifiers that are still used in
source (`DWRITE`, `LWIN`, `VCENTER`, `VREDRAW`, etc.) are **preserved**.
## Verification
- Diff is a single file, deletions only: `expect.txt` shrinks from 2343
→ 2196 lines.
- Each of the 4 uppercase Win32 tokens (`DWRITE` line 514, `LWIN` 1074,
`VCENTER` 2105, `VREDRAW` 2144 in the original) remains in the file.
- The check-spelling job on this PR should now post a clean report (no
`should be removed` block).
## Background — which PR introduced the drift
| PR | Date | What it changed |
|----|------|-----------------|
| **#47119** | 2026-04-23 | Refreshed check-spelling to 0.0.26; rewrote
`expect.txt` with 938 line-changes (633 deletions, 305 additions). The
duplicated lowercase/uppercase entries and many obsolete tokens
originate here. |
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <Copilot@users.noreply.github.com>
## Summary
Fixes#46767
Items pinned to the End section of the dock did not animate on startup,
while Start and Center items did. The EndListView had an explicit empty
`ItemContainerTransitions` collection that suppressed all container
transitions. Removing it allows the default WinUI entrance animations to
play, matching Start and Center behavior.
## Changes
- `DockControl.xaml`: Remove empty `TransitionCollection` override from
EndListView
---------
Co-authored-by: root <root@io.bbq>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
Fixes the **stable** signed release pipeline failure (Dart build
[`147621162`](https://microsoft.visualstudio.com/Dart/_build/results?buildId=147621162))
at the *"Verify all binaries are signed and versioned"* task:
```
Not Signed: + …\extractedMachineMsi\File\BaseApplicationsFiles_File_PowerAccent.Common.dll
```
## Root cause
PR #47211 (*"[Quick Accent] Move language data to PowerAccent.Common
library, refactor"*) introduced the new managed library:
- `src/modules/poweraccent/PowerAccent.Common/PowerAccent.Common.csproj`
`PowerAccent.Common.dll` is referenced by both `PowerAccent.Core` (ships
in the installer root) and `PowerToys.Settings` (ships in WinUI3Apps;
deduplicated against root by `generateAllFileComponents.ps1`). The DLL
is harvested into the MSI's `BaseApplicationsFiles` component group, but
the PR did not update `.pipelines/ESRPSigning_core.json`, so ESRP never
signs it and `versionAndSignCheck.ps1` correctly fails the build.
This is the same kind of omission that PR #48050 fixed for
`YamlDotNet.dll` introduced by #40834 — a new managed library shipping
in the MSI without a matching signing config entry.
## Fix
One additive line in `.pipelines/ESRPSigning_core.json`, placing
`"PowerAccent.Common.dll"` inside the existing alphabetized PowerAccent
block (next to `PowerAccent.Core.dll`).
```diff
"PowerAccent.Core.dll",
+ "PowerAccent.Common.dll",
"PowerToys.PowerAccent.dll",
```
## Validation
- `git diff` shows exactly one additive line.
- File still parses as valid JSON (`ConvertFrom-Json` round-trip OK).
- Audited the full file list of PR #47211: `PowerAccent.Common.dll` is
the only new shippable assembly it added (the other new project,
`PowerAccent.Common.UnitTests`, is a test project and is not included in
the installer).
- Dedup logic in
`installer/PowerToysSetupVNext/generateAllFileComponents.ps1` keeps only
the root copy when WinUI3Apps and root copies are byte-identical, so a
single root-level entry is sufficient.
## Follow-up
After merge to `main`, cherry-pick / merge into `stable` to unblock the
0.100 release pipeline. This is the third (and hopefully final) PR in
the 0.100 release-pipeline unblock sequence, after #48050 (sign
`YamlDotNet.dll`) and #48054 (remove duplicate
`QuickAccent_SelectedLanguage_Greek_Polytonic` resource).
Co-authored-by: Copilot <Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
* Fix wrong Shortcut for Shortcut Guide V2 (previously always showed
default)
* Fix outdated OOBE description
* Fix process not stopping when exiting via ESC or close button
* Fixed some missing modules
* Removed regex capability and was able to improve the start up time
through this
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Okay I'll admit this is a clanker fix.
There's currently a crash when you navigate to an individual extension
page, that only repro's in Release/AOT. And because of
release&trimming&AOT reasons, that's very very difficult to diagnose.
But the clanker added a shitload of logging, and was able to figure out
that:
We were binding to this `Screenshots` collection. Problem is that we
can't safely bind to an `IReadOnlyList` in trimmed scenarios. C#/AOT is
a wonderful world of horrors.
Fixing this is as simple as swapping it for a `ObservableCollection`.
When we were docked on a screen other than the primary display, then
clicking on a dock item that was a `IPage` would result in the palette
window just not showing up at all.
The fix is to make sure that we use the actual position of the current
monitor in the calculation of the final position of the palette HWND.
## Summary
Adds **77 explicit `AutomationProperties.AutomationId`** declarations (4
→ 81, ~20x) to Command Palette XAML so UI-testing tools (WinAppDriver,
FlaUI, winappCli, Appium) can address controls deterministically instead
of falling back to runtime slugs that change every session. Also covers
the `DataTemplate`-generated long tail (search results, file results,
every extension item, every monitor in Dock settings) by binding
`AutomationId` to existing stable model identifiers via `{x:Bind}`.
Headline: a one-line addition to the four CmdPal `ListItem`
`DataTemplate`s now exposes each instance's underlying `Command.Id`
(e.g. `com.microsoft.cmdpal.builtin.calculator`) as its `AutomationId`.
This is the same pattern as web's `<li data-testid={item.id}>`.
## Why
CmdPal today ships with only **4** explicit
`AutomationProperties.AutomationId` declarations across **44** XAML
files (~303 interactive controls). UI tests are forced to fall back to:
- runtime-generated slugs like `itm-12-9dda` that change every CmdPal
restart, or
- regex-parsing the text output of `winappCli ui inspect`, or
- walking the UIA tree client-side and matching by `Name` (localized,
ambiguous when several controls share a label).
## What changed
### Source changes
- **`Microsoft.CmdPal.UI/ExtViews/ListItemsView.xaml`** — bind
`AutomationProperties.AutomationId="{x:Bind Command.Id, Mode=OneWay}"`
on the root of all 4 `ListItem` `DataTemplate`s (single-row, small-grid,
medium-grid, gallery). Covers **every** runtime list item across all
built-in and third-party providers.
- **`Microsoft.CmdPal.UI/Settings/GeneralPage.xaml`** — 14 IDs on
activation hotkey controls, auto-go-home combo, behaviour toggles,
about-section hyperlinks.
- **`Microsoft.CmdPal.UI/Settings/AppearancePage.xaml`** — 19 IDs on
theme/backdrop/colorization, background image controls, 5 sliders,
behaviour toggles.
- **`Microsoft.CmdPal.UI/Settings/DockSettingsPage.xaml`** — 14 IDs on
enable toggle, theme/colorization/backdrop, background image controls,
plus per-monitor data-bound ID using `DisplayName`.
- **`Microsoft.CmdPal.UI/Settings/ExtensionsPage.xaml`** — 4 IDs on
banner/store hyperlinks plus the per-provider `SettingsCard` (data-bound
to the provider's `Id`, e.g. `com.microsoft.cmdpal.builtin.calculator`).
- **`Microsoft.CmdPal.UI/Settings/ExtensionPage.xaml`** — 5 IDs on
provider enable toggle, alias text/activation, fallback rank link.
- **`Microsoft.CmdPal.UI/Settings/ExtensionGalleryItemPage.xaml`** — 5
IDs on install/cancel/copy-command buttons and author/repo/uninstall
links.
- **`Microsoft.CmdPal.UI/Settings/InternalPage.xaml`** — 7 IDs on the
dev-only "Throw exception" and folder/log-opening buttons.
- **`Microsoft.CmdPal.UI/Pages/ShellPage.xaml`** — 1 data-bound ID on
the `CommandTemplate` button (binds to `CommandViewModel.Id`).
- **`Microsoft.CmdPal.UI.ViewModels/ProviderSettingsViewModel.cs`** —
single-line addition exposing the underlying `CommandProviderWrapper.Id`
so the ExtensionsPage template can bind to it.
### Naming convention applied
`CmdPal_<Page>_<Semantic>` PascalCase, with the existing well-known IDs
left untouched to avoid breaking the `modules/cmdpal/*` checklist tests
already referencing them. `Id` / `TestId` suffixes deliberately omitted
(the attribute is already `AutomationId`); control-type suffixes
(`Toggle` / `Button` / `ComboBox`) omitted because the type lives on the
UIA `type` field already.
### Files NOT touched (deferred)
About 5–7 secondary files (`SettingsWindow.xaml`,
`ExtensionGalleryPage.xaml`, `DockControl.xaml`, `DevRibbon.xaml`, deep
style/viewer XAML) — their interactive controls already carry `x:Name`,
which WinUI auto-promotes to `AutomationId` at runtime, so practical
testability is mostly already there. Can be tightened up in a follow-up
PR.
## Risk
- ✅ Zero runtime cost (`AutomationProperties.AutomationId` is metadata
only)
- ✅ Does not affect localization (`AutomationId` is non-localized by
design)
- ✅ Does not affect user-facing accessibility (screen readers consume
`Name` / `AutomationProperties.Name`, untouched)
- ✅ Does not rename any existing ID; `modules/cmdpal/*` tests
referencing `MainSearchBox` / `PrimaryCommandButton` / `ItemsList` /
etc. remain valid
- ✅ All 51 CmdPal XAML files parse as valid XML (PowerShell `[xml]`
round-trip)
- ✅ All `x:Bind` paths verified against the relevant ViewModel types
(`CommandViewModel.Id`, `DockMonitorConfigViewModel.DisplayName`,
`ProviderSettingsViewModel.Id`)
## Validation requested before merge
XAML compilation was attempted locally but blocked by a missing native
NuGet package (`Microsoft.Windows.ImplementationLibrary`) — needs
`tools\build\build-essentials.cmd` to fully restore first. **Reviewer
please run a clean local build of `Microsoft.CmdPal.UI` (or rely on CI)
to confirm the XAML compiler is happy.**
Once built, a quick smoke check:
```powershell
# After CmdPal restart with the new bits installed:
winapp ui search 'CmdPal_' -w <hwnd> --json # should list all the new IDs
winapp ui invoke 'CmdPal_AppearancePage_OpenCommandPalette' -w <hwnd>
winapp ui invoke 'com.microsoft.cmdpal.builtin.calculator' -w <hwnd> # ListItem template binding
```
## Why this matters beyond our tools
This is the same pattern Microsoft's accessibility and WinUI teams
already recommend for any XAML app intended to be automated. It's the
WinUI equivalent of adding `data-testid` in a web app — universally
accepted as low-risk, high-leverage. WinAppDriver, FlaUI, Appium and any
future automation framework all benefit from the same change.
## Summary
Fixes the **stable** signed release pipeline failure (Dart build
[`147590319`](https://microsoft.visualstudio.com/Dart/_build/results?buildId=147590319))
at the *"Verify all binaries are signed and versioned"* task on both
`Build Release_x64` and `Build Release_arm64`:
```
Not Signed: + …\extractedMachineMsi\File\WinUI3ApplicationsFiles_File_YamlDotNet.dll
```
## Root cause
PR #40834 (*Shortcut Guide V2*) added a `YamlDotNet` `PackageReference`
to:
- `src/modules/ShortcutGuide/ShortcutGuide.Ui/ShortcutGuide.Ui.csproj`
-
`src/modules/ShortcutGuide/ShortcutGuide.IndexYmlGenerator/ShortcutGuide.IndexYmlGenerator.csproj`
Both projects publish into `WinUI3Apps\`, so `YamlDotNet.dll` is
harvested into the MSI by
`installer/PowerToysSetupVNext/generateAllFileComponents.ps1`. The PR
updated `ESRPSigning_core.json` for its own new binaries but missed this
3rd-party transitive dependency, so ESRP never signs it and
`.pipelines/versionAndSignCheck.ps1` correctly fails the build.
## Fix
One additive line to `.pipelines/ESRPSigning_core.json`, placing
`WinUI3Apps\YamlDotNet.dll` next to the other 3rd-party `WinUI3Apps\`
entries (`Google.Apis.*`, `Google.GenAI.dll`, `ReverseMarkdown.dll`,
`SharpCompress.dll`, …).
## Validation
- `git diff` shows exactly one additive line.
- File still parses as valid JSON (`ConvertFrom-Json` round-trip OK).
- Both ShortcutGuide csprojs target
`$(Platform)\$(Configuration)\WinUI3Apps`, so a single
`WinUI3Apps\YamlDotNet.dll` entry covers all uses.
## Follow-up
After merge to `main`, cherry-pick / merge into `stable` so build
`147590319` can be re-queued and the 0.100 release pipeline can proceed.
Co-authored-by: Copilot <Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Adds a built-in monitor blacklist that skips known-bad monitor models at
the DDC/CI discovery stage — before PowerDisplay sends any capabilities
request to the firmware. Matches by EdidId (the PnP manufacturer +
product code from EDID). Two entries pre-populated from existing crash
reports:
| EdidId | Reported in | Notes |
|-----------|-------------|------------------------------------------------------------------------|
| `LTM2C02` | #47556 | Counterfeit-EDID LG 27MR400 (PnP claims Litemax
40" 2011, actual hw is LG 27" 2024) |
| `GSM7714` | #47968 | LG UltraWide HDR WFHD |
Also logs `[EdidId=…] [FriendlyName=…] [DevicePath=…]` immediately
before each `GetCapabilitiesString*` syscall in `DdcCiController`. If
the kernel call BSODs (`win32kfull` stack-cookie overrun), that is the
last log line that survives — adding a new blacklist entry then takes
one PR to `BuiltInMonitorBlacklist.json` instead of a memory-dump
triage.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Mitigates: #47556
- [x] Mitigates: #47968
- [x] **Communication:** This is the "Add blacklist and prevent the API
call on broken monitor" mitigation outlined in [#47556
(comment)](https://github.com/microsoft/PowerToys/issues/47556#issuecomment-4505498427).
The underlying `win32kfull!DdcciGetCapabilitiesStringFromMonitor` stack
overrun is tracked separately by the Windows team.
- [x] **Tests:** 6 new MSTest unit tests under
`PowerDisplay.Lib.UnitTests`. All 120 PowerDisplay tests pass on x64
Debug.
- [ ] **Localization:** N/A — this PR ships no end-user-facing strings
(no UI surface).
- [ ] **Dev docs:** N/A.
- [ ] **New binaries:** N/A. Data ships as an `<EmbeddedResource>`
inside the existing `PowerDisplay.Models.dll`; no new .dll, no installer
change.
- [ ] **Documentation updated:** N/A.
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
### Threat model
Some retail monitor firmwares ship non-conformant DDC/CI capabilities
strings — typically oversized, not NUL-terminated, or otherwise
malformed. When PowerDisplay calls `GetCapabilitiesStringLength` /
`CapabilitiesRequestAndCapabilitiesReply` on these monitors, the request
flows into
`win32kfull!CPhysicalMonitorHandle::DdcciGetCapabilitiesStringFromMonitor`,
which copies the reply into a stack buffer without bounding the length.
The kernel detects its own stack cookie corruption on the epilogue check
and `__fastfail`s with `BUGCHECK 0x139 / 2
(STACK_COOKIE_CHECK_FAILURE)`.
The kernel-side overrun is a Windows defect, not PowerDisplay's, but
PowerDisplay is currently the most widely deployed consumer of this API
on hot-plug. Until the Windows team fixes the kernel, the only safe
mitigation in user space is to **never call** the capabilities API on
monitor models known to trigger it.
### Architecture
| File | Role |
|---|---|
| `PowerDisplay.Models/MonitorBlacklistEntry.cs` | POCO: `{ edidId,
comments }` |
| `PowerDisplay.Models/BuiltInMonitorBlacklist.json` | Data file
(embedded resource) |
| `PowerDisplay.Models/BuiltInMonitorBlacklist.cs` | Lazy-loaded reader,
AOT-safe (source-gen `JsonSerializerContext`); silent fallback to empty
list on any IO/parse failure |
| `PowerDisplay.Lib/Services/MonitorBlacklistService.cs` |
`IsBlocked(monitorId)` — extracts EdidId via
`MonitorIdentity.EdidIdFromMonitorId`, checks a `HashSet<string>` with
`OrdinalIgnoreCase` |
| `PowerDisplay/Helpers/MonitorManager.cs` | Filters QueryDisplayConfig
inventory by EdidId **before** any controller (DDC/CI or WMI) is
dispatched; logs each skip with `[MonitorBlacklist] Skipping ...` |
| `PowerDisplay.Lib/Drivers/DDC/DdcCiController.cs` | Logs EdidId +
FriendlyName + DevicePath immediately before the first capabilities
syscall per-monitor |
Matching is **model-level granularity** (EdidId, e.g. `GSM7714`) rather
than device-level (full DevicePath). One entry covers every physical
port and every machine with the same monitor model.
### Adding new entries
Once the kernel overrun is fixed this list can shrink. Until then, when
a new BSOD surfaces:
1. User reports BSOD, attaches PowerDisplay log
2. The last line before the crash now reads `DDC: probing capabilities
[EdidId=XXXXXX] [FriendlyName='...'] [DevicePath=...]`
3. Add `{ "edidId": "XXXXXX", "comments": "See #issue" }` to
`BuiltInMonitorBlacklist.json`
4. Submit PR, ship in next release
### Scoped out (deliberate)
A user-customized blacklist surface (Settings UI dialog) was prototyped
and hit multiple WinUI 3 dialog parse / measure crashes inside a
`ContentDialog`. The custom-list code path was reverted in favor of
"built-in only" for v1 reliability. UI can be re-added later on top of
this foundation if needed — the data model and service already support
it.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
1. **Unit tests:** `dotnet test` on `PowerDisplay.Lib.UnitTests` →
**120/120 pass** (including 6 new tests for loader + service: built-in
JSON loads, EdidIds are normalized to upper-case, no blank entries,
`Lazy<>` cache returns same instance, `IsBlocked` returns `false` for
empty built-in list and for unidentifiable monitor IDs).
2. **Clean x64 Debug build** via `tools\build\build-essentials.cmd` +
per-project `tools\build\build.cmd`:
- `PowerDisplay.Models` — 0 warning, 0 error
- `PowerDisplay.Lib` — 0 warning, 0 error
- `PowerDisplay` (app) — 0 warning, 0 error
3. **Smoke test (manual):** launched PowerDisplay, confirmed every
connected monitor produces a `DDC: probing capabilities [EdidId=…]
[FriendlyName=…] [DevicePath=…]` log line right before its caps request.
4. **Empty-list case:** `BuiltInMonitorBlacklist.json` with no entries →
`IsBlocked` returns `false` for any input (verified via unit test).
5. **Non-empty case (manual):** temporarily added a connected monitor's
EdidId to the built-in JSON → that monitor disappears from
`MonitorManager.Monitors` and `[MonitorBlacklist] Skipping ...` log line
appears; removed the entry → monitor reappears, all per-monitor settings
intact.
---------
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
## Summary
Fixes the **"Build PowerToys main project"** failure on every PR/CI
build off current `main` (e.g. Dart build
[`147597426`](https://microsoft.visualstudio.com/Dart/_build/results?buildId=147597426)):
```
WINAPPSDKGENERATEPROJECTPRIFILE: Error PRI175: Processing Resources failed with error: Duplicate Entry.
WINAPPSDKGENERATEPROJECTPRIFILE: Error PRI277: Conflicting values for resource
'Resources/QuickAccent_SelectedLanguage_Greek_Polytonic'
```
## Root cause
`src/settings-ui/Settings.UI/Strings/en-us/Resources.resw` contained two
`<data name="QuickAccent_SelectedLanguage_Greek_Polytonic">` entries:
- Line 3597 — original, added by #47021 (*"[PowerAccent] adding greek
polytonic"*), placed in the alphabetized QuickAccent block.
- Line 6175 — duplicate, appended at the file tail by #47211 (*"[Quick
Accent] Move language data to PowerAccent.Common library, refactor"*).
The two entries are byte-identical (same value `Greek Polytonic`, same
`xml:space="preserve"`). The WinAppSDK PRI generator (`MakePri`) rejects
duplicates, so every build off current `main` fails before reaching the
compile step.
## Fix
Remove the tail duplicate (3-line block right before `</root>`). Keeps
the original entry in its alphabetized location.
## Validation
- `git diff` shows exactly 3 deleted lines.
- `[xml](Get-Content … -Raw)` round-trip succeeds — file is still
well-formed XML.
- `Select-String` count of
`QuickAccent_SelectedLanguage_Greek_Polytonic` in the file is now **1**
(was 2).
- Only `en-us` has this key (other localized `.resw` files are populated
later via Touchdown), so no other file needs touching.
## Note
Discovered while investigating a CI failure unrelated to my other PR
#48050 (signing of `WinUI3Apps\YamlDotNet.dll`). Both fixes are needed
for the 0.100 release pipeline; this PR unblocks PR builds off `main`,
and #48050 unblocks the signed release pipeline once both are merged to
`main` and the next `main → stable` sync happens.
Co-authored-by: Copilot <Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Language data for Quick Accent was previously defined in
**PowerAccent.Core/Languages.cs**, internal to the Quick Accent
application itself. The Settings application had no access to the list
and had to maintain a parallel, manually-synchronised list of the
language names and groups, and there was no single place to look up the
complete set of languages.
This PR resolves this and extracts the language data into a new
**PowerAccent.Common** project with no external or UI dependencies,
making it the single source of truth for both the character popup and
Settings UI.
The implicit and non-obvious ordering of the old **Languages.cs** has
been replaced with explicit ordering of the language groups and
languages list.
A new unit test project for the application has also been added.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #47159
- [x] Closes: #30000
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
The following changes and additions have been made:
New project **PowerAccent.Common** contains:
- **Language.cs** - an enum of Quick Accent's pseudo-ISO identifiers for
each of the supported languages
- **LetterKey.cs** - mirrors the LetterKey enum defined in the
KeyboardListener.idl, and must be kept in sync with that. This exposes
the VK_* data to the Settings UI without it having to reference the
PowerAccentKeyboardService project
- **LanguageGroup.cs** - classifies languages as `Language` (for spoken
languages), `Special` (for sets like Currency and International Phonetic
Alphabet), or `UserDefined` (reserved for future work)
- **LanguageInfo.cs** - a record which combines a language's identity,
group, resource identifier, and character mappings
- **CharacterMappings.cs** - a new version of the old **Languages.cs**,
providing:
- `All` - the canonical registry of every `LanguageInfo` entry
- `DisplayOrder` - the explicit within-group ordering for languages, for
the default popup ordering, i.e. when the user has not got
frequency-based ordering enabled. This is a culturally-neutral
alphabetical ordering by our pseudo-ISO language IDs, and close to the
previous order, minimising any impact to users' muscle memory
- `GroupDisplayOrder` - the explicit ordering of language groups for
both the popup and the Settings UI
- `LanguageLookup` - new _O(1)_ `Language` to `LanguageInfo` dictionary
- `GetCharacters(LetterKey, Language[])` - a deduplicating character
collector and sorter
A significant improvement over the old **Languages.cs** is that language
ordering is now explicit and in one place. Previously, popup ordering
was an implicit side-effect of a large Union chain across all language
mappings, with the enum, the language mapping declarations and the union
all carrying different orderings. This was a source of confusion and
made adding new languages fragile.
The original **Languages.cs** has been deleted. There's now a thin
`CharacterMappings` adapter that casts the `LetterKey` to the managed
equivalent by numeric value. This is another effort to decouple the
Settings UI and Quick Accent and only share the required elements.
In Settings, the `PowerAccentViewModel` class has been updated. It now
derives the language list directly from `CharacterMappings.All`; the
`InitializeLanguages()` call handles localisation, sorting and grouping
in a single place using `GroupDisplayOrder`.
A new unit test project covers `CharacterMappings`, the `LetterKey`
IDL-to-managed code bridge and general language declaration checks. The
application is now much more robust against changes which alter the
declared order, introduce empty/null elements, and so on. It is now
impossible to add a new language and forget a constituent part (the enum
entry, its place in the display order, the character mappings
themselves) without a test failing.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
See new unit test project for comprehensive tests.
Manually confirmed:
- Triggering Quick Accent with no language selected does not report an
error
- Language order is consistent in the popup, no matter what order the
languages are selected in Settings
- The order of languages in Settings is consistent, alphabetically by
localised name
- All declared languages are present in Settings and no resource IDs
were missed
---------
Co-authored-by: Muyuan Li (from Dev Box) <muyuanli@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
Addresses three critical issues with the PowerToys update experience
that cause user fragmentation across old versions.
### Changes
**1. Fix relaunch after update (Fixes#42004, #43011, #44071)**
- Stage 1 now passes the PowerToys install directory to Stage 2 as an
argument
- After successful install, Stage 2 relaunches `PowerToys.exe` with
`-report_update_success`
- Users will see a 'successfully updated' toast and PT resumes
automatically
**2. Config backup/restore (Fixes#46179)**
- `BackupConfigFiles()` snapshots all JSON configs to `ConfigBackup/`
before update begins
- `RestoreCorruptedConfigs()` checks for null-byte corruption after
install and auto-restores
- Protects Workspaces, FancyZones, Keyboard Manager, and all other
module settings
**3. Enable auto-download by default**
- New installations default `AutoDownloadUpdates` to `true` (was
`false`)
- Existing users' preferences are preserved — this only affects
first-run defaults
- The runner already defaulted to `true`; this aligns the C# settings
model
### Why this matters
The current updater kills all PowerToys processes, runs the installer,
then **exits without relaunching**. Users lose keyboard remappings,
FancyZones layouts, and Awake settings with no indication why. Combined
with auto-download being off by default, most users are multiple
versions behind.
### Testing
- Verified update flow: Stage 1 → Stage 2 → PT relaunches with success
toast
- Config backup creates mirror of all JSON settings before update
- Corruption detection catches null-byte pattern from #46179
- Graceful fallback: if install dir not provided (old Stage 1), logs
warning but doesn't crash
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Muyuan Li (from Dev Box) <muyuanli@microsoft.com>
Co-authored-by: Niels Laute <niels.laute@live.nl>
## Summary of the Pull Request
Shortcut Guide was rendering raw numeric key codes in key visuals for
some shortcuts (notably generated PowerToys shortcuts), showing numbers
where key characters/names were expected. This change normalizes numeric
key handling so display output matches actual key labels.
## PR Checklist
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
- **Scope**
- Updated `ShortcutDescriptionToKeysConverter` in `ShortcutGuide.Ui`
only.
- **Behavior change**
- Numeric key codes are no longer passed through as raw integers by
default.
- Arrow keys (`37/38/39/40`) remain numeric to preserve existing glyph
rendering behavior.
- All other numeric key codes are converted to display names via
`Helper.GetKeyName(...)`.
- **Result**
- Shortcut Guide key caps now show expected characters/key names instead
of numeric values for manifest-provided numeric keys.
```csharp
if (int.TryParse(key, out int keyCode))
{
switch (keyCode)
{
case 38:
case 40:
case 37:
case 39:
shortcutList.Add(keyCode); // keep glyph path
break;
default:
shortcutList.Add(Helper.GetKeyName((uint)keyCode)); // show key label
break;
}
}
```
## Validation Steps Performed
No additional validation details are included in this description.
> [!WARNING]
>
> <details>
> <summary>Firewall rules blocked me from connecting to one or more
addresses (expand for details)</summary>
>
> #### I tried to connect to the following addresses, but was blocked by
firewall rules:
>
> - `o3svsblobprodcus318.vsblob.vsassets.io`
> - Triggering command: `/usr/bin/dotnet dotnet build
/home/REDACTED/work/PowerToys/PowerToys/src/modules/ShortcutGuide/ShortcutGuide.Ui/ShortcutGuide.Ui.csproj
-v minimal` (dns block)
>
> If you need me to access, download, or install something from one of
these locations, you can either:
>
> - Configure [Actions setup
steps](https://gh.io/copilot/actions-setup-steps) to set up my
environment, which run before the firewall is enabled
> - Add the appropriate URLs or hosts to the custom allowlist in this
repository's [Copilot coding agent
settings](https://github.com/microsoft/PowerToys/settings/copilot/coding_agent)
(admins only)
>
> </details>
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: niels9001 <9866362+niels9001@users.noreply.github.com>
Co-authored-by: Noraa Junker <noraa.junker@outlook.com>
This PR:
- Adds a MaxWidth to the SCOOBE and OOBE pages, inline with Fluent
design guidance
- Updates the imagery for PowerToys
- Tweaks some small nits in the General settings page: re-ordering,
adding icons, replacing a ToggleSwitch with a CheckBox
<img width="1774" height="1325" alt="image"
src="https://github.com/user-attachments/assets/d825047a-27be-4e8b-a6ce-7f1a71f39dfe"
/>
The PowerDisplay flyout had no keyboard close path: pressing Tab kept
focus inside the window so it never deactivated, and there was no
KeyDown / KeyboardAccelerator wired up. Handle Escape on RootGrid to
hide the window, matching the behavior of other PowerToys flyouts.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #48016
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Corrects four label names in the \VALID_LABELS\ allow-list of the
\uto-label-issues.yml\ workflow to match existing repository labels
exactly.
## Root Cause
The GitHub Actions \ddLabels\ API creates a brand-new label when the
name doesn't exactly match an existing one. The hardcoded list had
typos/mismatches:
| Workflow had | Repo actually has |
|---|---|
| \Product-Power Display\ | \Product-PowerDisplay\ |
| \Product-ColorPicker\ | \Product-Color Picker\ |
| \Product-Command Not Found\ | \Product-CommandNotFound\ |
| \Product-Hosts\ | \Product-Hosts File Editor\ |
## Changes
- Fixed all 4 label strings in \VALID_LABELS\ array
- Deleted the spurious \Product-Power Display\ label that was created by
the mismatch
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Carry per-monitor user preferences from the pre-#47712 Id format onto
the current DevicePath-based Ids by matching on EdidId. Without this,
every upgrade silently resets Enable* toggles (input source, color
temperature, power state) for monitors users had already opted in on,
because the direct-Id lookup in ApplyPreservedUserSettings can never
match the old "DDC_DELD1A8_1" / "WMI_BOE0900_2" keys.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Currently, if the user clicks on a dock item which is a Page command,
then we'll attempt to show the cmdpal where the user clicked on a dock
item. This works great. However, if the user right-clicks a dock item to
invoke the context menu, then from that menu clicks on a Page command,
then nothing happens - we don't show the cmdpal window.
Similarly - IInvokableCommand's that return a CommandResult.Confirm - we
never show the cmdpal window so that the confirmation ContentDialog is
shown to the user.
Yes in the long run, these will make more sense to have a better UI for
the "dock flyout" (see #45861). But until then, this fixes these
scenarios.
Closes#45963
very relevant for #47989
## Summary of the Pull Request
This PR introduces real-time settings synchronisation for Image Resizer.
External changes to `settings.json` (via the Settings application or
manual edits to the file) are detected and reloaded immediately without
requiring a restart.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #36943
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
### Reload updates
The reload detection is via an `IFileSystemWatcher` (as file system
operations are abstracted in Image Resizer), which monitors the
`settings.json` file for creation and changes. There is a half second
debounce for changes, as the settings file can rapidly change when the
user is editing the preset name field.
Hot reloading of the properties required refactoring `ReloadCore`, which
replaces the `Sizes` preset collection and updates the Custom and AI
presets, in addition to the application-wide properties like compression
options and the fallback encoder choice.
I changed the combo box data binding from the `SelectedSize` object to
the int `SelectedSizeIndex`. This was required to resolve a specific WPF
issue where reloading the `Sizes` collection would cause issues with
restoring the current combo box selection to the prior value. Binding to
the index decouples the selection state from the object lifecycle during
the reload process.
Selection preservation is based on the preset ID (for user presets) and
preset type (for Custom and AI presets). This ensures that matches are
robust even if the user is in the process of renaming an entry in the
Settings application. If the preset cannot be matched (for example, if
the user deletes the item or changes the ID manually in the file), the
Custom preset is selected.
Selection range checks are maintained from the old code, and additional
checks have been added to ensure that Custom and AI presets will be
present even if they're deleted from the settings file.
The AI preset check from before has been inlined; this guarantees that
the AI resize option will not display if the facility is unavailable on
the current PC, even if it's present in the settings file.
The reload routine is dispatched to the UI thread, as changes involve
updates to the combo box.
### ID recovery
Preset IDs are key to preserving the combo box selection between
reloads, and a couple of changes were necessary to ensure round-tripping
changes were robust.
1. IDs are not reused. The old code could reuse IDs under certain
circumstances, for example if a preset was deleted and re-added via
Settings.
2. The ID Recovery Helper routine sorted the supplied presets by ID
before performing duplicate conflict resolution. This is not required
and it is more natural to assume that the order in the settings file and
the client UI is the source of truth.
New ID assignment is now based on a monotonically increasing ID (seeded
at application start) rather than `Current Maximum ID + 1`. This means
that IDs cannot be reused in the same Settings application session. This
makes the matching process in the client application more reliable.
A small update was made to the ID Recovery Helper to use `HashSet.Add()`
instead of splitting up the check and addition steps (`Add` will return
false if the value already exists), which saves a massive one line of
code.
There were comments about the ID Recovery Helper resolving "empty" or
"invalid" entries; this was inaccurate, as IDs are ints, which must by
definition always have a valid value. The routine only guards against
duplicates, so the comments have been updated to reflect this.
### Miscellaneous
The `Default` Settings property getter previously called `Reload` every
time it was accessed. This is fine when the file is only read at
application startup, but I changed this to lazily instantiate and call
`Reload` a single time.
I refactored duplicate code related to settings file/folder strings, and
also the creation of the Custom and AI size instances.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing:
1. Add new preset in the Settings application. The new entry is
reflected in the client application as it is running.
2. Delete new preset. The entry is removed in the client application
list.
3. Edit an existing preset. The property change is reflected in the
client application.
4. Add new preset in the Settings application. Select the new preset in
the client application. Edit the properties of the new preset in the
Settings application and confirm that the updates appear in the client
application.
5. Add new preset in the Settings application. Select the new preset in
the client application. Delete the new preset in Settings. Confirm that
the current preset is removed and the selection changes to the default
in the client application.
6. Change one or more application-wide properties in the settings file
which are represented in the client application, too, e.g. "Make
pictures smaller but not larger" (`imageresizer_shrinkOnly`) or
"Overwrite files" (`imageresizer_replace`). Upon saving, confirm the
checkbox changes immediately in the client application.
7. Edit the `settings.json` file manually by e.g. adding a new Size
preset or editing the width or height property of an existing preset.
Upon saving, the change(s) should be reflected in the client
application.
8. Make a change to an existing or new preset which affects the resize
operation itself, e.g. the dimensions or the "Make pictures smaller but
not larger" setting. Proceed with the resize operation and confirm that
the new changes have been applied.
14 new unit tests have been added to `SetingsTests.cs` to exercise the
`Settings` and `IDRecoveryHelper` functionality.
---------
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Summary
Adds the four Google.* DLLs shipped by AdvancedPaste (via
`Microsoft.SemanticKernel.Connectors.Google` for Gemini support) to the
ESRP sign list.
## Problem
The `Verify all binaries are signed and versioned` pipeline step
(`.pipelines/versionAndSignCheck.ps1`) was failing with:
```
Not Signed: + ...\extractedMachineMsi\File\WinUI3ApplicationsFiles_File_Google.Apis.Auth.dll
Not Signed: + ...\extractedMachineMsi\File\WinUI3ApplicationsFiles_File_Google.Apis.Core.dll
Not Signed: + ...\extractedMachineMsi\File\WinUI3ApplicationsFiles_File_Google.Apis.dll
Not Signed: + ...\extractedMachineMsi\File\WinUI3ApplicationsFiles_File_Google.GenAI.dll
```
These DLLs are transitive NuGet dependencies of
`Microsoft.SemanticKernel.Connectors.Google` (referenced by
`src/modules/AdvancedPaste/AdvancedPaste/AdvancedPaste.csproj`) and
deploy to `WinUI3Apps\`, but were never added to
`.pipelines/ESRPSigning_core.json`.
## Fix
Added the four DLLs to the second `SignBatch` (`CP-231522`, the
third-party / OSS-library identity) — same batch used for other
connector DLLs like `OpenAI.dll`, `OllamaSharp.dll` and
`Microsoft.SemanticKernel.Connectors.Ollama.dll`.
## Validation
- `ConvertFrom-Json` on the modified file confirms valid JSON.
- Sign-list entries match the actual deploy paths flagged by
`versionAndSignCheck.ps1`.
- The next ESRP signing run will pick them up; the verify step should
pass.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary
Mitigation for issue #47556 — `KERNEL_SECURITY_CHECK_FAILURE` BSOD
originating in `win32kfull!DdcciGetCapabilitiesStringFromMonitor` when
PowerDisplay calls DDC/CI capability APIs against monitors with
malformed capability strings.
After a detected crash, PowerDisplay auto-disables itself via
`settings.json`, shows an error InfoBar at the top of the PowerDisplay
settings page (page is locked except the Ignore button), so users can
avoid getting stuck in an infinite reboot loop after a crash. And the
user must explicitly dismiss the warning before re-enabling the module.
The actual kernel-side fix is the Windows team's responsibility — this
PR only prevents users from BSOD-ing repeatedly on the same monitor
without warning.
settings page:
<img width="1743" height="1475" alt="image"
src="https://github.com/user-attachments/assets/8cf1b72f-c51a-4955-82d7-213cae49fd4e"
/>
## Mechanism
1. `CrashDetectionScope` IDisposable wraps Phase 2 capability fetch in
`DdcCiController.DiscoverMonitorsAsync`, writing `discovery.lock`
(`WriteThrough` + `Flush(flushToDisk: true)`) before, deleting it on
Dispose.
2. If the process is killed externally (BSOD, FailFast), the lock
survives.
3. On next PowerDisplay.exe startup (Phase 0), `CrashRecovery` detects
the orphan lock and runs a strict fail-fast sequence: write
`crash_detected.flag` → set `enabled.PowerDisplay=false` in global
`settings.json` → signal the new `POWER_DISPLAY_AUTO_DISABLE_EVENT` →
delete the lock (commit point).
4. The runner-loaded `PowerDisplayModuleInterface.dll` runs a one-shot
listener thread that wakes on the event and calls `disable()` to sync
`m_enabled`.
5. `PowerDisplayViewModel` reads the flag at construction and binds
`IsCrashLockActive` to lock the page.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #47556
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Yu Leng <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This allows users to drag files & URLS to the dock, to immediately
create a bookmark, and pin that bookmark to the dock.
It also updates the bookmark provider's dock bands. If you bookmark a
folder, then pin that to the dock, when you click it on the dock, we'll
default to the "browse" experience, which will open the list of files in
cmdpal, rather than open in explorer.
Had to make miscellaneous changes to make this all a bit faster:
* DirectoryPage didn't load icons smartly, like we do for bookmarks
* I added a different "observable" collection for dock top-level items,
because it caused a flippin CollectionChanged cascade any time a single
provider had more than one item pinned in the dock. Each item from each
provider would cause us to recreate all the dock view models (???) crazy
* I alas had to make `IBookmarksManager` public, so that the UI could
use it. I hate it, but I couldn't figure out a better way. Bookmarks are
a pretty built-in part, so it's _fine i guess_
re: #45584
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This PR checks if future PRs has added or refines telemetry events, if
so, the bot will add a message to the PR about the needed steps
depending on the PR.
**NOTE**: This PR is submitting a test version, which is only manually
triggered, once tested and confirmed then will move to it being
automatic
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
## Summary of the Pull Request
This PR fixes several issues around the popup selection window's size
and position, selection-related issues which result in flashing or
glitching, and includes more reliable detection of the Shift key.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #44332
- [x] Closes: #44980
- [x] Closes: #35094
- [x] Closes: #40498
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
This PR includes fixes for the Quick Accent's selection window position,
its width measurement, and letter selection-related issues. In addition,
glitches such as the window flashing the selection colour and the window
appearing blank should be reduced or eliminated entirely.
### Popup width bug
When opening Quick Accent from a letter with many mappings, it would
appear too wide for the display. Even though letters could be selected,
they may be entirely off-screen:
<img width="1578" height="134" alt="image"
src="https://github.com/user-attachments/assets/cfcb2ddb-3cf3-47d5-9386-133a2fc70550"
/>
This was because of this flaw in `GetDisplayMaxWidth`, which is used
directly by the popup to set the maximum width of the characters area:
```csharp
// In Selector.xaml.cs
private void SetWindowsSize()
{
this.characters.MaxWidth = _powerAccent.GetDisplayMaxWidth();
}
...
// In PowerAccent.cs
public double GetDisplayMaxWidth()
{
return WindowsFunctions.GetActiveDisplay().Size.Width - ScreenMinPadding;
}
```
`GetActiveDisplay` uses the `GetMonitorInfo` API, which exposes the
working area of the display. It returns its values in _raw unscaled
pixel_ values:
```csharp
public static (Point Location, Size Size, double Dpi) GetActiveDisplay()
{
...
var res = PInvoke.MonitorFromWindow(guiInfo.hwndActive, MONITOR_FROM_FLAGS.MONITOR_DEFAULTTONEAREST);
MONITORINFO monitorInfo = default;
monitorInfo.cbSize = (uint)Marshal.SizeOf(monitorInfo);
PInvoke.GetMonitorInfo(res, ref monitorInfo);
...
return (location, monitorInfo.rcWork.Size, dpi);
}
```
However, the `MaxWidth` property must be a _pre-scaled_ value, i.e. in
logical WPF units not physical pixels. The fix is straightforward:
```csharp
public double GetDisplayMaxWidth()
{
var activeDisplay = WindowsFunctions.GetActiveDisplay();
return (activeDisplay.Size.Width / activeDisplay.Dpi) - ScreenMinPadding;
}
```
### Popup positioning bug
This is related to a subtle DPI issue in `GetActiveDisplay()`:
```csharp
public static (Point Location, Size Size, double Dpi) GetActiveDisplay()
{
GUITHREADINFO guiInfo = default;
guiInfo.cbSize = (uint)Marshal.SizeOf(guiInfo);
PInvoke.GetGUIThreadInfo(0, ref guiInfo);
var res = PInvoke.MonitorFromWindow(guiInfo.hwndActive, MONITOR_FROM_FLAGS.MONITOR_DEFAULTTONEAREST);
MONITORINFO monitorInfo = default;
monitorInfo.cbSize = (uint)Marshal.SizeOf(monitorInfo);
PInvoke.GetMonitorInfo(res, ref monitorInfo);
double dpi = PInvoke.GetDpiForWindow(guiInfo.hwndActive) / 96d;
var location = new Point(monitorInfo.rcWork.left, monitorInfo.rcWork.top);
return (location, monitorInfo.rcWork.Size, dpi);
}
```
Here, the application window's DPI is returned. Unfortunately, the
window may report a value which is different from the monitor's own DPI
value. This will consistently happen if the application is not
Per-Monitor DPI-Aware, and the monitor is not at 100% Scale. The effects
are that the Quick Accent popup can appear misaligned or even off-screen
entirely. Quick Accent can still be used, but the user may not be able
to see what they are selecting.
As Quick Accent is using monitor coordinates for setting its location,
the solution is to use the monitor's own DPI value. The fix is to add
this in place of the `GetDpiForWindow` line:
```csharp
uint dpiRaw = 96; // Safe default
if (PInvoke.GetDpiForMonitor(res, MONITOR_DPI_TYPE.MDT_EFFECTIVE_DPI, out uint dpiX, out _) == 0)
{
dpiRaw = dpiX;
}
double dpi = dpiRaw / 96d;
```
### Selection bugs
After dismissing the Quick Accent window, the `_selectedIndex` state was
not properly reset. The next time the window opened, it could attempt to
scroll to or highlight an index that was out-of-bounds for the new
character set. This could result in glitching, such as the window
flashing the selection colour or the initial selection being incorrect.
In this fix, I:
1. Explicitly set `_selectedIndex` to `-1` when the UI hides.
2. Reset the `SelectedIndex` inside Selector.xaml.cs before updating the
`ItemsSource`.
### Shift key activation
In certain cases, a quick press of Shift could fail to move back through
the character list. In this fix, I:
1. Added a native fallback usign GetAsyncKeyState(VK_SHIFT).
2. Updated `ProcessNextChar()` to evaluate `shiftPressed ||
WindowsFunctions.IsShiftState()`.
3. Updated the multiple `if`s in `ProcessNextChar` to be an if/else
structure, to prevent bugs when more than one trigger key is pressed.
### Support added for multi-codepoint graphemes
The current code loops through each `char` of a mapping, calling
`SendInput` multiple times for multi-char sequences. This will fail for
multi-codepoint graphemes, i.e. where the mapping 'letter' is more than
one UTF-16 codepoint. Those characters may appear as `[]`. The amended
`Insert()` in `WindowsFunctions` appends all characters before calling
`SendInput`.
### Miscelleneous
- Added an `OnDpiChanged` handler for the Selector control, so changing
the DPI of the screen should be picked up automatically. (It's
questionable whether this is essential, as the DPI would have to change
while the control was displayed, but it's worth having for robustness.)
- Now using `SetWindowPos` instead of setting the `Left` and `Top` of
the popup control. Also now initialising the popup offscreen to attempt
to reduce flicker and the occurrence of blank window flashes.
- Changed the `Focusable` property of the characters `ListBox` to
`False`, to attempt to reduce flicker and the window flashing the
selector colour.
- Removed `Width` and added `MinWidth` to the letter control in
Selector.xaml. This allows for wider letters or longer multi-letter
mappings.
- Changed the `VirtualizingStackPanel` to a regular `StackPanel`. We do
not have mappings with enough entries for a virtual control to be
necessary, and using StackPanel seemed to have a positive effect on the
appearance of blank window glitches.
- Added `TextTrimming`, `TextWrapping` and `MaxHeight` to the unicode
description `TextBlock`. This helps support extremely long unicode
descriptions. Again, this will enable us to support longer
multi-character mappings in the future.
- Added CsWin32 to the PowerAccent.UI project, to support the
`SetWindowPos` call.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
See separate doc for full test details:
https://docs.google.com/document/d/19uClcUiv7RUDRlbFhazG-Cmu46oNmrAVoJf9bHSjSJU/edit?usp=sharing
---------
Co-authored-by: Muyuan Li (from Dev Box) <muyuanli@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Niels Laute <niels.laute@live.nl>
Adds Greek Polytonic characters set to power accent, based on
https://github.com/microsoft/PowerToys/pull/29709
### PR Checklist
- [x] Closes#46941
- [x] Communication: I've discussed this with core contributors already.
- [ ] Tests: Not sure if there are specific tests for this
- [ ] Documentation updated: Power accent docs
### Detailed Description of the Pull Request / Additional comments
Added all greek polytonic letters to their corresponding english letter
(some duplicated)
(if you wondered about GRC -> ISO 639-3)
### Validation Steps Performed
Compiled and Observed Power Accent
---------
Co-authored-by: Niels Laute <niels.laute@live.nl>
Co-authored-by: Dave Rayment <dave.rayment@gmail.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
reply:Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
reply:We've identified this issue as a duplicate of an existing one and are closing this thread so discussion stays in one place.<br/><br/>Please see the comment above for the link to the original tracking issue, and feel free to subscribe there for updates.
Thank you for contributing to PowerToys. We've detected that this PR might include a new or modified telemetry event. After this PR is merged, please follow these next steps:
- [ ] Reach out to Jessica (${REVIEWER_MENTION}) to follow up on the next steps: https://aka.ms/pt-telemetry-process
Thank you for contributing to PowerToys. We've detected that this PR might include a new or modified telemetry event. Please ensure the following before merging:
- [ ] Add your telemetry events to [DATA_AND_PRIVACY](https://github.com/microsoft/PowerToys/blob/main/DATA_AND_PRIVACY.md).md within this PR.
- [ ] Reach out to Jessica (${REVIEWER_MENTION}) to follow up on the next steps: https://aka.ms/pt-telemetry-process`;
11.**Tests** — Adapt for WinUI 3 runtime, async patterns
### Key Principles
### Migration Contract: Prohibited Patterns
- **Do NOT overwrite `App.xaml` / `App.xaml.cs`** — WinUI 3 has different application lifecycle boilerplate. Merge your resources and initialization code into the generated WinUI 3 App class.
- **Do NOT create Exe→WinExe `ProjectReference`** — Extract shared code to a Library project. This causes phantom build artifacts.
- **Use `Lazy<T>` for resource-dependent statics** — `ResourceLoader` is not available at class-load time in all contexts.
These rules capture human judgment and must be applied consistently across every file. Do NOT deviate.
**Architecture prohibitions:**
- **Do NOT overwrite `App.xaml` / `App.xaml.cs`** — WinUI 3 has different lifecycle boilerplate. Merge resources and init code into the generated WinUI 3 App class.
- **Do NOT create Exe→WinExe `ProjectReference`** — Extract shared code to a Library project. Causes phantom build artifacts.
- **Do NOT instantiate services directly** — Use DI and CommunityToolkit.Mvvm patterns.
- **Do NOT create a `Window` subclass for every dialog or sub-page** — use `ContentDialog` for in-app dialogs and `Frame`/`Page` navigation for sub-views. Separate `Window` classes are reserved for distinct top-level surfaces (e.g., FancyZones editor, OOBE).
- **Do NOT omit `WindowsPackageType=None` and `WindowsAppSDKSelfContained=true`** — Both are mandatory in the csproj for every WinUI 3 module in PowerToys. Without them the app crashes at startup with `COMException: ClassFactory cannot supply requested class` because the WinUI 3 runtime DLLs are not found.
**XAML prohibitions:**
- **Do NOT use `{DynamicResource}`** — Replace with `{ThemeResource}` (theme-reactive) or `{StaticResource}`.
- **Do NOT use `{Binding}` in `Setter.Value`** — Not supported in WinUI 3. Use `{StaticResource}`.
- **Do NOT use `{x:Static}`** — Replace with `{x:Bind}`, `x:Uid`, or code-behind.
- **Do NOT use `{x:Type}`** — Not supported. Use `x:DataType` for DataTemplate, or code-behind.
- **Do NOT use `clr-namespace:`** — Replace with `using:` in all xmlns declarations.
- **Do NOT use `Style.Triggers` / `DataTrigger` / `EventTrigger`** — Replace with `VisualStateManager`.
- **Do NOT use `MultiBinding`** — Replace with `x:Bind` function binding or computed ViewModel property.
- **Do NOT use `Visibility="Hidden"`** — WinUI only has `Visible` and `Collapsed`. Use `Opacity="0"` if layout must be preserved.
- **Do NOT use `IsDefault` / `IsCancel`** — Use `AccentButtonStyle` for primary button; handle Enter/Escape in code-behind.
- **Do NOT omit `BasedOn` when overriding default styles** — Without it, your style replaces the entire default. Always use `BasedOn="{StaticResource DefaultButtonStyle}"` etc.
- **Do NOT omit `XamlControlsResources` as first merged dictionary** — It provides default Fluent styles. Without it, controls have no visual appearance.
**Code-behind prohibitions:**
- **Do NOT use `Application.Current.Dispatcher`** — Store `DispatcherQueue` in a static field explicitly.
- **Do NOT use `Window.Current`** — Not supported. Use a custom `App.Window` static property.
- **Do NOT put `DataContext`, `Resources`, or `VisualStateManager` on `Window`** — WinUI 3 `Window` is NOT a `DependencyObject`. Use a root `Page`/`UserControl`/`Grid`.
- **Do NOT use tunneling/preview events** (`PreviewMouseDown`, `PreviewKeyDown`) — WinUI has no tunneling. Use bubbling equivalents with `Handled` property or `AddHandler(handledEventsToo: true)`.
**Resource prohibitions:**
- **Do NOT use `Properties.Resources.MyString`** — Replace with `ResourceLoaderInstance.ResourceLoader.GetString("MyString")`.
- **Do NOT initialize `ResourceLoader`-dependent values as static fields** — Wrap in `Lazy<T>` or null-coalescing property.
- **Do NOT use `pack://` URIs** — Replace with `ms-appx:///` scheme.
These WPF controls have no direct counterpart and require a different control or third-party package:
| WPF Control | WinUI 3 Replacement | Notes |
|-------------|---------------------|-------|
| `DataGrid` | [`WinUI.TableView`](https://github.com/w-ahmad/WinUI.TableView) | Community library; the Toolkit `DataGrid` is no longer maintained. Legacy code may still pin v7 `CommunityToolkit.WinUI.UI.Controls.DataGrid` 7.1.2 |
| `Ribbon` | `CommandBar` / `NavigationView`, or [Toolkit Labs Ribbon](https://github.com/CommunityToolkit/Labs-Windows/tree/main/components/Ribbon) | No first-party Ribbon in WinUI; Labs component is experimental/partial |
| `Menu` / `MenuItem` | `MenuBar` / `MenuBarItem` / `MenuFlyout` | `MenuBar` for classic menu, `MenuFlyout` for context |
| `ContextMenu` | `MenuFlyout` | Assign to `ContextFlyout` property |
| `FlowDocument` | `RichTextBlock` | Partial replacement only |
| `RichTextBox` | `RichEditBox` | Rich text editing |
| `GroupBox` | `Expander` (built-in) or `HeaderedContentControl` (Toolkit) | See [Layout & Header Controls from CommunityToolkit.WinUI](#layout--header-controls-from-communitytoolkitwinui) below |
| `Label` | `TextBlock` | WPF `Label` is a `ContentControl`; use `TextBlock` + `AccessKey` |
| `TreeView` | `TreeView` (native) | Available natively, but data binding model differs significantly |
| `MessageBox` | `ContentDialog` | Must set `XamlRoot` before `ShowAsync()` |
| `MediaElement` | `MediaPlayerElement` | Different API |
| `AccessText` | Not available | Use `AccessKey` property on target control |
### Layout & Header Controls from CommunityToolkit.WinUI
These WPF controls have no built-in WinUI 3 equivalent — install the corresponding CommunityToolkit package. **The NuGet package id and the XAML namespace differ intentionally**: package names end in `.Primitives` / `.HeaderedControls`, but the registered XAML namespace is the shorter `CommunityToolkit.WinUI.Controls` (confirmed in the [official Microsoft Q&A](https://learn.microsoft.com/en-us/answers/questions/5746230/why-does-communitytoolkit-uwp-controls-primitive-u)).
| `RoutedUICommand` / `CommandBinding` | `ICommand` / `[RelayCommand]` from CommunityToolkit.Mvvm. WinUI also has `StandardUICommand` / `XamlUICommand` for platform commands. |
| `AdornerLayer` / `Adorner` | Depends on use case: `TeachingTip`/`InfoBar` (validation), `Popup` (overlays), `PlaceholderText` (watermarks), Canvas overlay (decorations) |
| `Visibility.Hidden` | `Opacity="0"` with `Visibility="Visible"` (preserves layout space) |
| `Window.Resources` / `Window.DataContext` | Move to root `Grid.Resources` / root `Page`/`UserControl` — WinUI `Window` is NOT a DependencyObject |
| Tunneling events (`Preview*`) | Use bubbling equivalents + `Handled` property or `AddHandler(handledEventsToo: true)` |
### Critical API Replacements
| WPF | WinUI 3 | Notes |
|-----|---------|-------|
| `Dispatcher.Invoke()` | `DispatcherQueue.TryEnqueue()` | Different return type (`bool`) |
| `Dispatcher.Invoke()` | `DispatcherQueue.TryEnqueue()` | Different return type (`bool`), async by default |
| `Dispatcher.CheckAccess()` | `DispatcherQueue.HasThreadAccess` | Property vs method |
| `Application.Current.Dispatcher` | Store `DispatcherQueue` in static field | See [Threading](./references/threading-and-windowing.md) |
| `Window.Current` | Custom `App.Window` static property | Not supported in Windows App SDK |
| Function binding | No | Yes (replaces `MultiBinding`) |
| Performance | Reflection-based | Compiled, no reflection |
| `MultiBinding` support | No (not in WinUI) | Use function binding |
## Detailed Reference Docs
@@ -151,6 +287,8 @@ Read only the section relevant to your current task:
| JPEG quality value wrong after migration | WPF: int 1-100; WinRT: float 0.0-1.0 |
| MSIX packaging fails in PreBuildEvent | Move to PostBuildEvent; artifacts not ready at PreBuild time |
| RC file icon path with forward slashes | Use double-backslash escaping: `..\\ui\\Assets\\icon.ico` |
| `COMException: ClassFactory cannot supply requested class` at startup | Missing `<WindowsPackageType>None</WindowsPackageType>` and/or `<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>` in csproj. Without these, the app tries to locate the Windows App SDK framework package (not installed) instead of using bundled runtime DLLs. **Both properties are mandatory for every WinUI 3 module in PowerToys.** |
| `CombinedGeometry` not available in WinUI 3 | WinUI 3 `UIElement.Clip` only accepts `RectangleGeometry`. For overlay hole effects (exclude region), use a `Path` element with `GeometryGroup FillRule="EvenOdd"` containing two `RectangleGeometry` children — the EvenOdd rule creates a transparent hole where geometries overlap. |
## Troubleshooting
@@ -163,3 +301,4 @@ Read only the section relevant to your current task:
| NuGet restore failures | Run `build-essentials.cmd` after adding `Microsoft.WindowsAppSDK` package |
| `Parallel.ForEach` compilation error | Migrate to `Parallel.ForEachAsync` for async imaging operations |
| Signing check fails on leaked artifacts | Run `generateAllFileComponents.ps1`; verify only `WinUI3Apps\\` paths in signing config |
| `COMException` / `ClassFactory` error at app launch | Ensure csproj has `<WindowsPackageType>None</WindowsPackageType>` and `<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>`. These are required for all unpackaged WinUI 3 apps in PowerToys — without them the WinUI 3 COM runtime cannot be found. |
| `ListBox` | `ListView` (or `ItemsView`) | **Deprecated in WinUI 3 — do not use.** Prefer `ListView`, or `ItemsView` (WinUI 1.5+) for modern collection scenarios |
| `AccessText` | Not available | Use `AccessKey` property on target control |
### WPF-UI (Lepo) to Native WinUI 3
@@ -109,6 +112,43 @@ Last parameter changes from `CultureInfo` to `string` (BCP-47 language tag). All
| `DataGrid` | [`WinUI.TableView`](https://github.com/w-ahmad/WinUI.TableView) | Community library; the Toolkit `DataGrid` is no longer maintained. PowerToys legacy modules may still pin v7 `CommunityToolkit.WinUI.UI.Controls.DataGrid` 7.1.2 — prefer `WinUI.TableView` for new work. |
| `Ribbon` | `CommandBar` / `NavigationView`, or [Toolkit Labs Ribbon](https://github.com/CommunityToolkit/Labs-Windows/tree/main/components/Ribbon) | No first-party Ribbon in WinUI; the Labs component is experimental and partial |
| `Menu` / `MenuItem` | `MenuBar` / `MenuBarItem` / `MenuFlyoutItem` | `MenuBar` for classic menu, `MenuFlyout` for context |
| `ContextMenu` | `MenuFlyout` | Assign to `ContextFlyout` property |
| `FlowDocument` | `RichTextBlock` | Partial replacement only |
| `RichTextBox` | `RichEditBox` | Rich text editing |
| `GroupBox` | `Expander` (built-in) or `HeaderedContentControl` (Toolkit) | See [Layout & Header Controls from CommunityToolkit.WinUI](#layout--header-controls-from-communitytoolkitwinui) below |
| `Label` | `TextBlock` | WPF `Label` is a `ContentControl`; use `TextBlock` + `AccessKey` |
| `TreeView` | `TreeView` (native) | Available natively, but data binding model differs significantly |
| `MediaElement` | `MediaPlayerElement` | Different API |
## Layout & Header Controls from CommunityToolkit.WinUI
These WPF layout/header controls have no built-in WinUI 3 equivalent — install the corresponding CommunityToolkit package. **The NuGet package id and the XAML namespace differ intentionally**: package names end in `.Primitives` / `.HeaderedControls`, but both packages register their controls in the shorter `CommunityToolkit.WinUI.Controls` XAML namespace (confirmed in the [official Microsoft Q&A](https://learn.microsoft.com/en-us/answers/questions/5746230/why-does-communitytoolkit-uwp-controls-primitive-u): *"all controls live under `CommunityToolkit.WinUI.Controls` … This is intentional"*).
Other primitives in `Primitives`: `ConstrainedBox`, `SwitchPresenter`, `WrapLayout`, `StaggeredPanel`. Other Headered controls in `HeaderedControls`: `HeaderedItemsControl`, `HeaderedTreeView`.
## NuGet Package Migration
@@ -124,6 +164,11 @@ Last parameter changes from `CultureInfo` to `string` (BCP-47 language tag). All
| (none) | `CommunityToolkit.WinUI.UI.Controls.DataGrid` | Legacy v7 — only if migrating existing `DataGrid` code; prefer [`WinUI.TableView`](https://github.com/w-ahmad/WinUI.TableView) for new work |
| (none) | `Microsoft.Web.WebView2` | If using WebView |
## Project File Changes
@@ -167,8 +212,9 @@ Last parameter changes from `CultureInfo` to `string` (BCP-47 language tag). All
- **CRITICAL: Add `WindowsPackageType=None`** — marks the app as unpackaged (no MSIX). Without this, the build produces an MSIX-style package that won't run as a standalone PowerToys module.
-**CRITICAL: Add `WindowsAppSDKSelfContained=true`** — bundles the WindowsAppSDK runtime DLLs (e.g. `Microsoft.UI.Xaml.dll`) into the output directory. Without this, the app throws `COMException: ClassFactory cannot supply requested class` at startup because the WinUI 3 COM classes cannot be found.
- Add `SelfContained=true` (usually via `Common.SelfContained.props`)
- Add `DISABLE_XAML_GENERATED_MAIN` if using custom `Program.cs` entry point
- Set `ProjectPriFileName` to match your module's assembly name
- Move icon from `Resources/` to `Assets/<Module>/`
@@ -127,6 +127,74 @@ If the module uses the `WPF-UI` library, replace all Lepo controls with native W
</Window>
```
#### Recommended: Use WindowEx from WinUIEx
> **Tip:** Prefer `WinUIEx.WindowEx` over bare `Window`. It restores many WPF-like window properties directly in XAML, avoiding boilerplate code-behind for common windowing tasks.
```xml
<!-- WinUI 3 with WindowEx (preferred in PowerToys) -->
<winuiex:WindowEx
xmlns:winuiex="using:WinUIEx"
x:Class="MyApp.MainWindow"
MinWidth="480"
MinHeight="320"
IsShownInSwitchers="True"
IsTitleBarVisible="True">
<Window.SystemBackdrop>
<MicaBackdrop/>
</Window.SystemBackdrop>
<Grid>
...
</Grid>
</winuiex:WindowEx>
```
Properties available on `WindowEx` that mirror WPF `Window`:
NuGet: `WinUIEx` — already referenced by most PowerToys modules.
#### Recommended: Page-in-Window Architecture
> **Tip:** WinUI 3 `Window` is NOT a `FrameworkElement` — it does not support `Resources`, `DataContext`, `x:Bind`, or `VisualStateManager` directly. Place a `Page` as the Window's root content to regain these WPF-like capabilities.
```xml
<!-- WinUI 3 — Window contains a Page for full FrameworkElement support -->
<winuiex:WindowExx:Class="MyApp.MainWindow"
xmlns:winuiex="using:WinUIEx"
xmlns:views="using:MyApp.Views">
<views:MainPagex:Name="mainPage"/>
</winuiex:WindowEx>
```
```xml
<!-- MainPage.xaml — has full FrameworkElement capabilities -->
> **Tip:** The `CommunityToolkit.WinUI` package provides many controls and helpers familiar to WPF developers that are missing from WinUI 3 out of the box. Before writing custom replacements, check whether CommunityToolkit already provides what you need.
Key packages (XAML namespace is `using:CommunityToolkit.WinUI.Controls` for the `Controls.*` family):
- **`CommunityToolkit.WinUI.UI.Controls.DataGrid`** — legacy v7 `DataGrid` (no longer maintained); prefer [`WinUI.TableView`](https://github.com/w-ahmad/WinUI.TableView) for new work
- **`CommunityToolkit.WinUI.Converters`** — Common value converters (`BoolToVisibilityConverter`, `StringFormatConverter`, etc.)
- **`CommunityToolkit.WinUI.Behaviors`** — XAML behaviors for animations and interactions
- **`CommunityToolkit.WinUI.Extensions`** — Extension methods for WinUI types
### Common Control Replacements
```xml
@@ -187,11 +269,135 @@ If the module uses the `WPF-UI` library, replace all Lepo controls with native W
<!-- Handle Enter/Escape keys in code-behind if needed -->
These WPF features demand design changes, not find-and-replace. Read this section BEFORE attempting to migrate any file that uses these patterns.
### MultiBinding → x:Bind Function Binding
WinUI does not support `MultiBinding`. Replace with `x:Bind` function binding (most direct replacement), a computed ViewModel property, or multiple simple bindings.
WinUI does not support routed commands or `CommandBinding`. Replace with standard `ICommand` pattern:
```csharp
// CommunityToolkit.Mvvm
[RelayCommand(CanExecute = nameof(CanSave))]
privatevoidSave(){/* save logic */}
privateboolCanSave()=>IsDirty;
```
WinUI 3 also provides `StandardUICommand` and `XamlUICommand` for pre-defined platform commands (Cut, Copy, Paste, Delete) with built-in icons and keyboard accelerators.
### Tunneling / Preview Events
WinUI has no tunneling event model. `PreviewMouseDown`, `PreviewKeyDown`, etc. do not exist.
- Replace with the bubbling equivalent (`PointerPressed`, `KeyDown`)
- If you relied on tunneling to intercept events before children, restructure using the `Handled` property
- For must-handle scenarios, use `AddHandler` with `handledEventsToo: true`:
> **Warning:** In WinUI 3, always use `BasedOn` when overriding default control styles. Without it, your style **replaces the entire default style** rather than extending it.
```xml
<!-- WRONG — replaces entire default style, control may lose all visual appearance -->
@@ -249,11 +452,42 @@ WPF `Triggers`, `DataTriggers`, and `EventTriggers` are not supported.
| `Disabled` | `Disabled` |
| `Pressed` | `Pressed` |
## Visibility.Hidden — No Equivalent
WinUI only has `Visible` and `Collapsed`. There is no `Hidden`.
| WPF | WinUI 3 | Behavior |
|-----|---------|----------|
| `Visibility.Visible` | `Visibility.Visible` | Rendered and occupies layout space |
| `Visibility.Hidden` | **Not available** | Use `Opacity="0"` with `Visibility="Visible"` to hide but keep layout |
| `Visibility.Collapsed` | `Visibility.Collapsed` | Not rendered, no layout space |
## Resource Dictionary Changes
### Window.Resources → Grid.Resources
### XamlControlsResources Must Be First
WinUI 3 `Window` is NOT a `DependencyObject` — no `Window.Resources`, `DataContext`, or `VisualStateManager`.
> **Warning:** `XamlControlsResources` must be the **first** merged dictionary in `App.xaml`. It provides the default Fluent styles. Omitting it gives you controls with no visual appearance. Resource paths use `ms-appx:///` instead of relative paths.
### Window.Resources → Grid.Resources (or use Page)
WinUI 3 `Window` is NOT a `FrameworkElement` — no `Window.Resources`, `DataContext`, or `VisualStateManager`.
**Preferred approach:** Use the [Page-in-Window architecture](#recommended-page-in-window-architecture) described above. A `Page` inside the `Window` gives you full `FrameworkElement` capabilities (Resources, DataContext, x:Bind, VisualStateManager).
**Fallback** (for simple windows without a Page):
```xml
<!-- WPF -->
@@ -317,19 +551,25 @@ Both are available. Prefer `{x:Bind}` for compile-time safety and performance.
| Performance | Reflection-based | Compiled |
| Function binding | No | Yes |
### WPF-Specific Binding Features to Remove
### Binding Differences from WPF
These WPF binding patterns behave differently in WinUI 3 — review on a case-by-case basis rather than mechanically removing.
```xml
<!--These WPF-only features must be removed or rewritten-->
<!--UpdateSourceTrigger: limited support in WinUI 3-->
| `{x:Static prefix:Resources.Key}` | `x:Uid="Key"` (with `.resw`) | Resource string — most common WPF case; mechanical `{x:Bind}` will NOT compile here |
| `MouseRightButtonUp` | `PointerReleased` + check `IsRightButtonPressed` | No direct WinUI event; use `RightTapped` only for context-menu-open semantics |
<!-- Fail fast with an actionable message instead of opaque C1083 spdlog/spdlog.h errors. -->
<Target Name="PowerToysEnsureVcpkgAvailable"
BeforeTargets="PrepareForBuild"
Condition="'$(MSBuildProjectExtension)' == '.vcxproj' and '$(VcpkgEnabled)' == 'true' and !Exists('$(VcpkgRoot)\scripts\buildsystems\msbuild\vcpkg.props')">
<Error Text="PowerToys requires the 'vcpkg' Visual Studio component, but it was not found.%0A%0AOpen the Visual Studio Installer, click Modify on your VS install, search for 'vcpkg', enable 'C++ vcpkg package manager', and click Modify. (Visual Studio will also prompt you to install missing .vsconfig components when you open PowerToys.slnx.)%0A%0AIf you have vcpkg installed elsewhere, set the VCPKG_ROOT environment variable to its root before building.%0A%0ASearched: '$(VcpkgRoot)\scripts\buildsystems\msbuild\vcpkg.props'" />
Condition="'$(MSBuildProjectExtension)' == '.vcxproj' and '$(VcpkgEnabled)' == 'true' and Exists('$(VcpkgRoot)\scripts\buildsystems\msbuild\vcpkg.targets')" />
<!-- Package Microsoft.Win32.SystemEvents added as a hack for being able to exclude the runtime assets so they don't conflict with 8.0.1. This is a dependency of System.Drawing.Common but the 8.0.1 version wasn't published to nuget. -->
<!-- Package System.CodeDom added as a hack for being able to exclude the runtime assets so they don't conflict with 8.0.1. This is a dependency of System.Management but the 8.0.1 version wasn't published to nuget. -->
<!-- Package System.Diagnostics.EventLog added as a hack for being able to exclude the runtime assets so they don't conflict with 8.0.1. This is a dependency of System.Data.OleDb but the 8.0.1 version wasn't published to nuget. -->
<!-- Package System.Diagnostics.PerformanceCounter added as a hack for being able to exclude the runtime assets so they don't conflict with 8.0.11. -->
"description":"Very fast, header-only/compiled, C++ logging library. PowerToys overlay pinned to gabime/spdlog@616866fc (the exact submodule commit before this migration), with a single-hunk patch that works around MSVC 14.51 removing stdext::checked_array_iterator (STL4043).",
@@ -97,6 +97,10 @@ The Shell Process Debugging Tool is a Visual Studio extension that helps debug m
- Check Event Viewer for application crashes related to `PowerToys.Settings.exe`
- Crash dumps can be obtained from Event Viewer
### Debugging Command Palette
Command Palette can be easily debugged using the solution filter in `src/modules/cmdpal/Command Palette.slnf`. This will open Command Palette as its own Visual Studio solution that can be run and debugged directly in Visual Studio without the need for the Shell Process Debugging Tool.
@@ -42,4 +42,4 @@ In the PR that adds a new plugin, reference a new issue to track the work for fu
- [ ] Add the resource folder to https://github.com/microsoft/PowerToys/blob/21247c0bb09a1bee3d14d6efa53d0c247f7236af/installer/PowerToysSetup/Product.wxs#L825
- [ ] Add the resource files under the section https://github.com/microsoft/PowerToys/blob/21247c0bb09a1bee3d14d6efa53d0c247f7236af/installer/PowerToysSetup/Product.wxs#L882
- [ ] Your plugin's executable file (DLL) has to have correct version informations after building it. (This version information will be shown on the settings page.)
- [ ] Your plugin's executable file (DLL) has to have correct version information after building it. (This version information will be shown on the settings page.)
Shortcut Guide is a PowerToy that displays an overlay of available keyboard shortcuts when the Windows key is pressed and held. It provides a visual reference for Windows key combinations, helping users discover and utilize built-in Windows shortcuts.
Shortcut Guide is a PowerToy that displays an overlay of available keyboard shortcuts when a user-set keyboard shortcut is pressed. It helps users discover and remember keyboard shortcuts for Windows and apps.
> [!NOTE]
> The spec for the manifest files is in development and will be linked here once available.
## Usage
- Press and hold the Windows key to display the overlay of available shortcuts
- Press the hotkey again to dismiss the overlay
- The overlay displays Windows shortcuts with their corresponding actions
- Press the user-defined hotkey to display the overlay
- Press the hotkey again or press ESC to dismiss the overlay
## Build and Debug Instructions
@@ -25,67 +27,89 @@ Shortcut Guide is a PowerToy that displays an overlay of available keyboard shor
4. The executable is named PowerToys.ShortcutGuide.exe
### Debug
1. Right-click the ShortcutGuide project and select 'Set as Startup Project'
1. Right-click the ShortcutGuide.Ui project and select 'Set as Startup Project'
2. Right-click the project again and select 'Debug'
## Code Structure
> [!NOTE]
> When run in debug mode, the window behaves differently than in release mode. It will not automatically close when loosing focus, it will be displayed on top of all other windows, and it is not hidden from the taskbar.
## Project Structure
### Core Files
The Shortcut Guide module consists of the following 4 projects:
Contains DLL boilerplate code. Implements the PowertoyModuleIface, including enable/disable functionality and GPO policy handling. Captures hotkey events and starts the PowerToys.ShortcutGuide.exe process to display the shortcut guide window.
Contains the module interface code. It initializes the settings values and the keyboard event listener. Defines the OverlayWindow class, which manages the overall logic and event handling for the PowerToys Shortcut Guide.
This is the main UI project for the Shortcut Guide module. Upon startup it does the following tasks:
Contains the code for loading the SVGs, creating and rendering of the overlay window. Manages and displays overlay windows with SVG graphics through two main classes:
- D2DOverlaySVG: Handles loading, resizing, and manipulation of SVG graphics
- D2DOverlayWindow: Manages the display and behavior of the overlay window
1. Copies the built-in manifest files to the users manifest directory (overwriting existing files).
2. Generate the `index.yml` manifest file.
3. Populate the PowerToys shortcut manifest with the user-defined shortcuts.
State machine that handles the keyboard events. It's responsible for deciding when to show the overlay, when to suppress the Start menu (if the overlay is displayed long enough), etc. Handles state transitions and synchronization to ensure the overlay is shown or hidden appropriately based on user interactions.
Handles the timing and interpolation of animations. Calculates the current value of an animation based on elapsed time and a specified easing function.
This function checks if the current window is excluded from the Shortcut Guide overlay. It returns `true` if the current window is excluded otherwise it returns `false`.
Waits for a named event and executes a specified action when the event is triggered. Uses a separate thread to handle event waiting and action execution.
This function retrieves the positions of the taskbar buttons for a given monitor. It returns an array of `TasklistButton` structures (max 10), which contain the position and size of each button.
The entry point for the PowerToys Shortcut Guide application. Handles initialization, ensures single instance execution, manages parent process termination, creates and displays the overlay window, and runs the main event loop.
`size` will contain the resulting array size.
It determines the positions through Windows `FindWindowEx` function.
For the primary taskbar it searches for:
* A window called "Shell_TrayWnd"
* that contains a window called "ReBarWindow32"
* that contains a window called "MSTaskSwWClass"
* that contains a window called "MSTaskListWClass"
For any secondary taskbar it searches for:
* A window called "Shell_SecondaryTrayWnd"
* that contains a window called "WorkerW"
* that contains a window called "MSTaskListWClass"
It then enumerates all the button elements inside "MSTaskListWClass" while skipping such with a same name (which implies the user does not use combining taskbar buttons)
If this method fails, which it will for newer versions of Windows, it falls back to searching for:
* A window called "Shell_TrayWnd" or "Shell_SecondaryTrayWnd"
* that contains a window called "Windows.UI.Composition.DesktopWindowContentBridge"
* that contains a window called "Windows.UI.Input.InputSite.WindowClass"
* the first child element
It then enumerates all the button elements inside the selected while skipping such with a same name (which implies the user does not use combining taskbar buttons) and such that do not start with "Appid:" (which are not actual taskbar buttons related to apps, but others like the widgets or the search button).
@@ -11,7 +11,7 @@ Welcome to the PowerToys developer documentation. This documentation provides in
- Desktop Development with C++
- WinUI application development
- .NET desktop development
- Windows 10 SDK (10.0.22621.0)
- Windows 11 SDK (10.0.22621.0)
- Windows 11 SDK (10.0.26100.3916)
1. .NET 8 SDK
1. Enable long paths in Windows (see [Enable Long Paths](https://docs.microsoft.com/windows/win32/fileio/maximum-file-path-limitation#enabling-long-paths-in-windows-10-version-1607-and-later) for details)
The list below is the set of utilities we're considering and the rough priority order of the utilities. If you have feedback on the order of the utilities, please use the issues for each one to provide that feedback. Note that new features for existing utilities (dock / undock zone layouts for FancyZones) are tracked in the backlog for each utility.
## On deck
* Maximize to new desktop widget - The MTND widget shows a pop-up button when a user hovers over the maximize / restore button on any window. Clicking it creates a new desktop, sends the app to that desktop and maximizes the app on the new desktop.
The build ID can be found in `Core\Constants.cs` in the `BuildId` variable - it is a unique identifier for the current builds that allows better diagnostics (we can look up the build ID from the logs) and offers a way to triage Awake-specific issues faster independent of the PowerToys version. The build ID does not carry any significance beyond that within the PowerToys code base.
The build ID moniker is made up of two components - a reference to a [Halo](https://en.wikipedia.org/wiki/Halo_(franchise)) character, and the date when the work on the specific build started in the format of `MMDDYYYY`.
- [#32544](https://github.com/microsoft/PowerToys/issues/32544) Fixed an issue where Awake settings became non-functional after the PC wakes from sleep. Added `WM_POWERBROADCAST` handling to detect system resume events (`PBT_APMRESUMEAUTOMATIC`, `PBT_APMRESUMESUSPEND`) and re-apply `SetThreadExecutionState` to restore the awake state.
- [#36150](https://github.com/microsoft/PowerToys/issues/36150) Fixed an issue where Awake would not prevent sleep when AC power is connected. Added `PBT_APMPOWERSTATUSCHANGE` handling to re-apply `SetThreadExecutionState` when the power source changes (AC/battery transitions).
- Fixed an issue where toggling "Keep screen on" during an active timed session would disrupt the countdown timer. The display setting now updates directly without restarting the timer, preserving the exact remaining time.
- [#41918](https://github.com/microsoft/PowerToys/issues/41918) Fixed `WM_COMMAND` message processing flaw in `TrayHelper.WndProc` that incorrectly compared enum values against enum count. Added proper bounds checking for custom tray time entries.
- Investigated [#44134](https://github.com/microsoft/PowerToys/issues/44134) - documented that `ES_DISPLAY_REQUIRED` (used when "Keep display on" is enabled) blocks Task Scheduler idle detection, preventing scheduled maintenance tasks like SSD TRIM. Workaround: disable "Keep display on" or manually run `Optimize-Volume -DriveLetter C -ReTrim`. Additional investigation needed for potential "idle window" feature.
- [#41738](https://github.com/microsoft/PowerToys/issues/41738) Fixed `--display-on` CLI flag default from `true` to `false` to align with documentation and PowerToys settings behavior. This is a breaking change for scripts relying on the undocumented default.
- [#41674](https://github.com/microsoft/PowerToys/issues/41674) Fixed silent failure when `SetThreadExecutionState` fails. The monitor thread now handles the return value, logs an error, and reverts to passive mode with updated tray icon.
- [#38770](https://github.com/microsoft/PowerToys/issues/38770) Fixed tray icon failing to appear after Windows updates. Increased retry attempts and delays for icon Add operations (10 attempts, up to ~15.5 seconds total) while keeping existing fast retry behavior for Update/Delete operations.
- [#40501](https://github.com/microsoft/PowerToys/issues/40501) Fixed tray icon not disappearing when Awake is disabled. The `SetShellIcon` function was incorrectly requiring an icon for Delete operations, causing the `NIM_DELETE` message to never be sent.
- [#40659](https://github.com/microsoft/PowerToys/issues/40659) Fixed potential stack overflow crash in EXPIRABLE mode. Added early return after SaveSettings when correcting past expiration times, matching the pattern used by other mode handlers to prevent reentrant execution.
- [#35250](https://github.com/microsoft/PowerToys/issues/35250) Updates the icon retry policy, making sure that the icon consistently and correctly renders in the tray.
- [#35848](https://github.com/microsoft/PowerToys/issues/35848) Fixed a bug where custom tray time shortcuts for longer than 24 hours would be parsed as zero hours/zero minutes.
- [#34716](https://github.com/microsoft/PowerToys/issues/34716) Properly recover the state icon in the tray after an `explorer.exe` crash.
- Added configuration safeguards to make sure that invalid values for timed keep-awake times do not result in exceptions.
- Updated the tray initialization logic, making sure we wait for it to be properly created before setting icons.
- Expanded logging capabilities to track invoking functions.
- Added command validation logic to make sure that incorrect command line arguments display an error.
- Display state now shown in the tray tooltip.
- When timed mode is used, changing the display setting will no longer reset the timer.
- Updating the initialization logic to make sure that settings are respected for proper group policy and single-instance detection.
- [#34148](https://github.com/microsoft/PowerToys/issues/34148) Fixed a bug from the previous release that incorrectly synchronized threads for shell icon creation and initialized parent PID when it was not parented.
- [#33630](https://github.com/microsoft/PowerToys/issues/33630) When in the UI and you select `0` as hours and `0` as minutes in `TIMED` awake mode, the UI becomes non-responsive whenever you try to get back to timed after it rolls back to `PASSIVE`.
- [#12714](https://github.com/microsoft/PowerToys/issues/12714) Adds the option to keep track of Awake state through tray tooltip.
- [#11996](https://github.com/microsoft/PowerToys/issues/11996) Adds custom icons support for mode changes in Awake.
- Removes the dependency on `System.Windows.Forms` and instead uses native Windows APIs to create the tray icon.
- Removes redundant/unused code that impacted application performance.
- Updates dependent packages to their latest versions (`Microsoft.Windows.CsWinRT` and `System.Reactive`).
### `ATRIOX_04132023` (April 13, 2023)
- Moves from using `Task.Run` to spin up threads to actually using a blocking queue that properly sets thread parameters on the same thread.
- Moves back to using native Windows APIs through P/Invoke instead of using a package.
- Move away from custom logging and to built-in logging that is consistent with the rest of PowerToys.
- Updates `System.CommandLine` and `System.Reactive` to the latest preview versions of the package.
### `LIBRARIAN_03202022` (March 20, 2022)
- Changed the tray context menu to be following OS conventions instead of the style offered by Windows Forms. This introduces better support for DPI scaling and theming in the future.
- Custom times in the tray can now be configured in the `settings.json` file for awake, through the `tray_times` property. The property values are representative of a `Dictionary<string, int>` and can be in the form of `"YOUR_NAME": LENGTH_IN_SECONDS`:
```json
{
"properties":{
"awake_keep_display_on":true,
"awake_mode":2,
"awake_hours":0,
"awake_minutes":3,
"tray_times":{
"Custom length":1800,
"Another custom length":3600
}
},
"name":"Awake",
"version":"1.0"
}
```
- Proper Awake background window closure was implemented to ensure that the process collects the correct handle instead of the empty one that was previously done through `System.Diagnostics.Process.GetCurrentProcess().CloseMainWindow()`. This likely can help with the Awake process that is left hanging after PowerToys itself closes.
This spec provides an extension to the existing [WinGet manifest schema](https://github.com/microsoft/winget-pkgs/blob/master/doc/manifest/README.md) in form of an additional yaml file, that describes keyboard shortcuts the application provides.
These yaml files are saved on a per-user base and so called manifest interpreters can then display these manifests in a human-friendly version.
### 1.1 What this spec is not about
This spec does not provide a way to back up or save user-defined keyboard shortcuts.
## 2 Save location of manifests
### 2.1 WinGet
These files are saved online along with the other manifest files in the [WinGet Package repository](https://github.com/microsoft/winget-pkgs).
### 2.2 Locally
All manifests and one index file are saved locally under `%LocalAppData%/Microsoft/WinGet/KeyboardShortcuts`. All apps are allowed to add their manifest files there. In addition Package Managers (like WinGet) and manifest interpreters (like PowerToys Shortcut Guide) can control and add other manifests themselves.
#### 2.2.1 Downloading manifests
When WinGet or other package managers download a package, they should also download the corresponding keyboard shortcuts manifest file and save it in the local directory, given such a file exists in the WinGet repository.
The downloader is also responsible for updating the local `index.yaml` file, which contains all the information about the different manifest files that are saved in the same directory.
#### 2.2.2 Updating manifests
When a manifest interpreter starts, it should download the latest version of the manifests from the WinGet repository and save them in the local directory. If a manifest interpreter is not able to download the manifests or they do not exist, it should use the locally saved manifests.
The updater is also responsible for updating the local `index.yaml` file, which contains all the information about the different manifest files that are saved in the same directory.
> Note: WinGet must provide a way to update the keyboard shortcuts manifests given a package id.
### 2.3 File names
The file name of a keyboard shortcuts file is the WinGet package identifier, plus the locale of the strings of the file and at last the `.KBSC.yaml` file extension.
For example the package "test.bar" saves its manifest with `en-US` strings in `test.bar.en-US.KBSC.yaml`.
#### 2.3.1 No winget package available
If an application has no corresponding WinGet package its name starts with a plus (`+`) symbol.
### 2.4 Reserved namespaces
Every name starting with `+WindowsNT` is reserved for the Windows OS and its components.
## 3 File syntax
All relevant files are written in [YAML](https://yaml.org/spec).
> Note: A JSON schema will be provided as soon as the spec reaches a further step
WindowFilter: # The filter of window processes to which the shortcuts apply to
BackgroundProcess: # Optionally allows applying WindowFilter to background processes
Shortcuts: # List of sections with keyboard shortcuts
- SectionName: # Name of the category of shortcuts
Properties: # List of shortcuts in the category
- Name: # Name of the shortcut
Description: # Optional description of the shortcut
AdditionalInfo: # Optional additional information about the shortcut
Recommended: # Optionally determines if the shortcut is displayed in a designated recommended area
Shortcut: # An array of shortcuts that need to be pressed
- Win: # Determines if the Windows Key is part of the shortcut
Ctrl: # Determines if the Ctrl Key is part of the shortcut
Shift: # Determines if the Shift Key is part of the shortcut
Alt: # Determines if the Alt Key is part of the shortcut
Keys: # Array of keys that need to be pressed
```
Per Application/Package one or more Keyboard manifests can be declared. Every manifest must have a different locale and the same `PackageName`, `WindowFilter` and `BackgroundProcess` fields.
<details>
<summary><b>PackageName</b> - The package unique identifier</summary>
Package identifier (see 2.1 for more information on the package identifier).
</details>
<details>
<summary><b>WindowFilter</b> - The filter of window processes to which the shortcuts apply to</summary>
This field declares for which process name the shortcuts should be shown (To rephrase: For which processes the shortcut will have an effect if pressed). The value can be either an exact process executable name, for example `explorer.exe` or `chrome.exe`, or a single asterisk (`*`) to apply to any process. No other wildcard patterns are supported by this specification.
</details>
<details>
<summary><b>BackgroundProcess</b> - Optionally allows applying WindowFilter to background processes.</summary>
**Optional field**
Defaults to `False`. Determines if WindowFilter should apply to background processes as well (Rephrased: When the process is running, the shortcuts will apply).
</details>
<details>
<summary><b>Shortcuts</b> - List of sections with keyboard shortcuts</summary>
List of different section (also called categories) of shortcuts.
</details>
<details>
<summary><b>SectionName</b> - Name of the category of shortcuts</summary>
Name of the section of shortcuts.
**Special sections**:
Special sections start with an identifier enclosed between `<` and `>`. This declares the category as a special display. If the interpreter of the manifest file can't understand the content this section should be left out.
</details>
<details>
<summary><b>Properties</b> - List of shortcuts in the category</summary>
</details>
<details>
<summary><b>Name</b> - Name of the shortcut</summary>
Name of the shortcut. This is the name that will be displayed in the interpreter.
</details>
<details>
<summary><b>Description</b> - Optional description of the shortcut</summary>
Optional description of the shortcut. This is the description that will be displayed by the interpreter.
</details>
<details>
<summary><b>AdditionalInfo</b> - Optional additional information about the shortcut</summary>
Array of additional information about the shortcut. This is the additional information that will be displayed by the interpreter and are not part of this manifest.
**Example**:
For example, if the shortcut is only available on a certain Windows version, this information could be added here.
```yaml
AdditionalInfo:
- MinWindowsVersion: "10.0.19041.0"
```
</details>
<details>
<summary><b>Shortcut</b> - An array of shortcuts that need to be pressed</summary>
An array of shortcuts that need to be pressed. This allows defining sequential shortcuts that need to be pressed in order to trigger the action.
</details>
<details>
<summary><b>Win</b> - Determines if the Windows Key is part of the shortcut</summary>
Refers to the left Windows Key on the keyboard.
</details>
<details>
<summary><b>Ctrl</b> - Determines if the Ctrl Key is part of the shortcut</summary>
Refers to the left Ctrl Key on the keyboard.
</details>
<details>
<summary><b>Shift</b> - Determines if the Shift Key is part of the shortcut</summary>
Refers to the left Shift Key on the keyboard.
</details>
<details>
<summary><b>Alt</b> - Determines if the Alt Key is part of the shortcut</summary>
Refers to the left Alt Key on the keyboard.
</details>
<details>
<summary><b>Recommended</b> - Optionally determines if the shortcut is displayed in a designated recommended area</summary>
**Optional field**
Defaults to `False`. Determines if the shortcut should be displayed in a designated recommended area. This is a visual hint for the user that this shortcut is important.
</details>
<details>
<summary><b>Keys</b> - Array of keys that need to be pressed</summary>
A string array of all the keys that need to be pressed. If a number is supplied, it should be read as a [KeyCode](https://learn.microsoft.com/windows/win32/inputdev/virtual-key-codes) and displayed accordingly (based on the Keyboard Layout of the user).
**Literal digit keys**:
Because a bare number is interpreted as a virtual-key code, a literal digit key must be authored using the `<N>` notation (the digit enclosed between `<` and `>`), where `N` is `0`–`9`. For example, `<9>` represents the literal `9` key (as in the "switch to the last tab" shortcut), not the virtual-key code `9` (which is `Tab`). The interpreter strips the brackets and displays just the digit.
This applies only to a single literal digit. A range such as `1 - 8` is a free-form label, not a key, and is supplied verbatim (the brackets would only be trimmed from the ends, so `<1> - <8>` would not render as intended).
**Special keys**:
Special keys are enclosed between `<` and `>` and correspond to a key that should be displayed in a certain way. If the interpreter of the manifest file can't understand the content, the brackets should be left out.
By convention these tokens are written as double-quoted strings in the YAML (for example `"<Enter>"` and `"<9>"`), matching the quoting used for punctuation key values. YAML treats the quoted and unquoted forms identically, so quoting is for consistency rather than a strict requirement for bracketed tokens.
|Name|Description|
|----|-----------|
|`<Office>`| Corresponds to the Office key on some Windows keyboards |
|`<Copilot>`| Corresponds to the Copilot key on some Windows keyboards |
|`<Left>`| Corresponds to the left arrow key |
|`<Right>`| Corresponds to the right arrow key |
|`<Up>`| Corresponds to the up arrow key |
|`<Down>`| Corresponds to the down arrow key |
|`<Enter>`| Corresponds to the Enter key |
|`<Space>`| Corresponds to the Space key |
|`<Tab>`| Corresponds to the Tab key |
|`<Backspace>`| Corresponds to the Backspace key |
|`<Delete>`| Corresponds to the Delete key |
|`<Insert>`| Corresponds to the Insert key |
|`<Home>`| Corresponds to the Home key |
|`<End>`| Corresponds to the End key |
|`<PrtScr>`| Corresponds to the Print Screen key |
|`<Pause>`| Corresponds to the pause key |
|`<PageUp>`| Corresponds to the Page Up key |
|`<PageDown>`| Corresponds to the Page Down key |
|`<Escape>`| Corresponds to the Escape key |
|`<Arrow>`| Corresponds to either the left, right, up or down arrow key |
|`<ArrowLR>`| Corresponds to either the left or right arrow key |
|`<ArrowUD>`| Corresponds to either the up or down arrow key |
|`<Underlined letter>`| Corresponds to any letter that is _underlined_ in the UI |
</details>
#### 3.2.2 Example
```yaml
PackageName: Microsoft.PowerToys
WindowFilter: "*"
BackgroundProcess: True
Shortcuts:
- SectionName: General
Properties:
- Name: Advanced Paste
Shortcut:
- Win: True
Ctrl: False
Alt: False
Shift: False
Keys:
- 86
Description: Open Advanced Paste window
- Name: Advanced Paste
Shortcut:
- Win: True
Ctrl: True
Alt: True
Shift: False
Keys:
- 86
Description: Paste as plain text directly
```
### 3.2 `index.yaml` file
The `index.yaml` file is a file that contains all the information about the different manifest files that are saved in the same directory. This file is only available locally and is not saved in the WinGet repository as it is specific to the user.
```yaml
DefaultShellName: # The package identifier of the default shell used in Windows
Index: # List of all manifest files
- WindowFilter: # The filter of window processes to which the shortcuts apply to
BackgroundProcess: # Optionally allows applying WindowFilter to background processes
Apps: # List of all manifest files for the filter
```
<details>
<summary><b>DefaultShellName</b> - The package identifier of the default shell used in Windows</summary>
This declares the package identifier of the default shell used in Windows. Most commonly it is `+WindowsNT.Shell`. Although not enforced, only the shell declared in the registry key `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell` should be used here.
</details>
<details>
<summary><b>Index</b> - List of all manifest files</summary>
</details>
<details>
<summary><b>WindowFilter</b> - The filter of window processes to which the shortcuts apply to</summary>
See the `WindowFilter` field in the manifest file for more information.
</details>
<details>
<summary><b>BackgroundProcess</b> - Optionally allows applying WindowFilter to background processes</summary>
**Optional field**
See the `BackgroundProcess` field in the manifest file for more information.
</details>
<details>
<summary><b>Apps</b> - List of all the package identifiers applying for the filter</summary>
| [SpeedTest](https://github.com/ruslanlap/PowerToysRun-SpeedTest) | [ruslanlap](https://github.com/ruslanlap) | One-command internet speed tests with real-time results, modern UI, and shareable links. |
| [DiskAnalyzer](https://github.com/valley-soft/powertoys-diskanalyzer) | [ValleySoft](https://github.com/valley-soft) | Scan folders, find the largest files, and view drive space usage. |
These are community driven alternative install methods to Windows Package Manager (WinGet) and GitHub. The PowerToys teams does not update or manage these install methods.
These will be listed in alphabetical order.
## Chocolatey
Download and upgrade PowerToys from [Chocolatey](https://chocolatey.org). If you have any issues when installing/upgrading the package please go to the [package page](https://chocolatey.org/packages/powertoys) and follow the [Chocolatey triage process](https://chocolatey.org/docs/package-triage-process)
To install PowerToys, run the following command from the command line / PowerShell:
```powershell
chocoinstallpowertoys
```
To upgrade PowerToys, run the following command from the command line / PowerShell:
```powershell
chocoupgradepowertoys
```
## Scoop
Download and update PowerToys from [Scoop](https://scoop.sh).
To install PowerToys, run the following command from the command line / PowerShell:
```powershell
scoopinstallpowertoys
```
To update PowerToys, run the following command from the command line / PowerShell:
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
