Commit Graph

9567 Commits

Author SHA1 Message Date
Jiří Polášek
5b7b91c9de CmdPal: Add extension gallery deep links (#49780)
## Summary of the Pull Request


This PR extends the x-cmdpal:// protocol to allow opening the Extension
Gallery and individual Extension Gallery items.

Extension developers can use this to link users directly from their
websites to the gallery, shortening the path to discovering and
installing Command Palette extensions.

- Adds typed x-cmdpal:// URI parsing in CmdPalProtocolActivation.
- Adds gallery and specific-extension deep links.
    - `x-cmdpal://extensions/gallery`
    - `x-cmdpal://extensions/gallery/{extension-id}`
- Opens extension details after the gallery loads.
- Integrate into existing gallery navigation to prevent garbage nav
stack.

Pictures? Pictures!


https://github.com/user-attachments/assets/d4d55b2a-2624-4a93-bdf7-55348b044b76

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist

- [x] Closes: #49770
<!-- - [ ] 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
2026-08-09 14:15:20 -05:00
Hashim Khan
66f63c988a Fix PowerToys Run settings text: searchbox -> search box (#49777)
## Summary

Fixes #49717.

On the PowerToys Run settings page, the plugin keywords description said
"searchbox". Updated the English string to "search box".

## Validation Steps / Documentation

1. Open PowerToys Settings
2. Go to PowerToys Run
3. Confirm the plugin keywords description uses "search box"

## PR Checklist

- [x] Closes: #49717
- [x] Communication: I've discussed this with a PowerToys maintainer or
discussed this in a GitHub issue / discussion
- [ ] Tests: Added or updated tests for this change / N/A for
string-only change
- [ ] Docs: Documentation has been updated or N/A
- [x] Binary assets: N/A
2026-08-09 17:22:28 +00:00
Gordon Lam
68a2a0d57b [Modules] Handle WM_ENDSESSION in run_message_loop daemons (GrabAndMove, AlwaysOnTop, FancyZones) (#48404)
## Summary

Companion PR to #48378 (runner). Fixes the same
`APPLICATION_HANG_QUIESCE_*_PowerToys.exe!run_message_loop` WER bucket
in the other PowerToys daemons whose top-level windows ignored
`WM_ENDSESSION`.

## Root cause (same as #48378)

`run_message_loop` (`src/common/utils/window.h`) calls `GetMessageW`
which only returns `0` on `WM_QUIT`. If a daemon's WndProc lets
`WM_ENDSESSION` fall through to `DefWindowProc`, no `WM_QUIT` is ever
posted on logoff/shutdown, the loop blocks, CSRSS hits the quiesce
timeout (~5s), `TerminateProcess` fires, and Watson logs
`APPLICATION_HANG_QUIESCE`.

## `run_message_loop` callsite audit

8 production callsites. Persistent daemons that own a top-level window
and were affected:

| Module | Status before | Fix here |
|---|---|---|
| `runner` | hang | Fixed in #48378 |
| `GrabAndMove` | hang (tray icon, NIM_DELETE in WM_DESTROY) | 
`main.cpp` |
| `AlwaysOnTop` | hang |  `AlwaysOnTop.cpp` |
| `FancyZones` | hang |  `FancyZones.cpp` |
| `KeyboardManagerEngine` | n/a | No top-level window → OS skips
WM_ENDSESSION and TerminateProcess directly; no hang bucket possible |
| `ZoomIt` | already handled | SysInternals heritage |
| `PowerLauncher` | already handled | Managed `SessionEnding` event |
| `MeasureTool`, `Notifications` | transient/spawned on demand | Not a
shutdown-time daemon |

## Fix pattern

For `AlwaysOnTop` and `FancyZones` (no tray icon to clean up) — minimal:

```cpp
case WM_ENDSESSION:
    if (wparam) PostQuitMessage(0);  // wparam==FALSE => shutdown vetoed
    return 0;
```

For `GrabAndMove` (has `Shell_NotifyIcon` cleanup in `WM_DESTROY` that
must not run on shutdown) — use a `g_session_ending` flag and skip the
tray-icon delete in `WM_DESTROY`, mirroring runner's `tray_icon.cpp`
pattern from #48378.

No shared header: each module's `WM_DESTROY` cleanup is module-specific;
the abstraction would be too thin and would hide the variance in what to
*skip*.

## Why no logging on the shutdown path

Same reasoning as #48378 review feedback — `spdlog::flush_on(info)`
synchronously flushes to disk; emitting log lines from
`WM_ENDSESSION`/`WM_DESTROY` burns the ~5s quiesce budget for no
diagnostic value (Watson already records the bucket on failure).

## Verification

- Built clean (Debug|x64): GrabAndMove.vcxproj, AlwaysOnTop.vcxproj,
FancyZonesLib.vcxproj — all exit 0.
- Runner counterpart fix (#48378) verified end-to-end with real reboot +
WM_ENDSESSION injection; quiesce 1–8 ms. Same OS-level mechanism applies
here.

## Related

- #48378 — runner fix (this PR's companion)
- #48363 — original community fix (over-engineered; this approach is the
minimal correct one)

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-08-09 21:01:48 +08:00
Gordon Lam
ed7595f3a7 Harden IPC pipe ownership and shutdown lifecycle (#48902)
## Summary of the Pull Request

The two-way named-pipe IPC server (`TwoWayPipeMessageIPC`, shared by the
runner, Settings, and Quick Access host) created every pipe instance
without `FILE_FLAG_FIRST_PIPE_INSTANCE`. If a pipe with the same name
already existed — for example a leftover instance from a previous run or
another process — `CreateNamedPipe` would quietly create an *additional*
instance and share the name instead of owning it.

This makes `start_named_pipe_server` create the **first** instance with
`FILE_FLAG_FIRST_PIPE_INSTANCE`, so `CreateNamedPipe` fails fast on a
name collision and the server is the authoritative owner of its pipe
name.

## PR Checklist

- [ ] **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
(N/A — no user-facing strings)
- [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

- The flag is applied **only** to the first instance. Subsequent
instances continue to omit it, so the existing
`PIPE_UNLIMITED_INSTANCES` behavior is fully preserved.
- The change is contained to a single function in
`src/common/interop/two_way_pipe_message_ipc.cpp`. Public signatures and
the `PowerToys.Interop` ABI are unchanged, so the runner, Settings, and
Quick Access host all benefit without any code changes on their side.

## Validation Steps Performed

- The existing `Common.Interop.UnitTests` `TestSend` exercises the
modified first-instance code path (`Start()` →
`start_named_pipe_server`) and continues to pass — a full IPC round-trip
still works.
- Verified the updated `CreateNamedPipe` open-mode logic compiles
cleanly.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 49797c8c-784d-47e6-bc0f-53464eecec4b
2026-08-09 20:56:12 +08:00
Boliang Zhang
9d96049b1f [Mouse Jump] Sign new WinUI3 binaries (#49747)
## Summary
- add the new Mouse Jump HotKeys, Models, and WinUI3 binaries to the
core ESRP signing policy
- remove the retired MouseJumpUI signing entries

## Context
The signed main build
[154175666](https://microsoft.visualstudio.com/Dart/_build/results?buildId=154175666)
failed for both x64 and ARM64 because the binaries introduced by #48393
were not selected for signing.

## Validation
- parsed `.pipelines/ESRPSigning_core.json` successfully
- confirmed all four new binary names are present and the two obsolete
names are removed

---------

Copilot-Session: 11e23507-f1c3-45e5-888d-22cd78240f6b
2026-08-09 19:00:04 +08:00
Jiří Polášek
9e12b7a8ee CmdPal: Reduce items on default perfmon band (#49674)
<!-- 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 limits the number of items shown in the default Performance
Monitor dock band to prevent an overcrowded Dock experience.

- Limits the primary Performance Monitor dock band to CPU and RAM.
- Adds a new single-item dock band for network speed, showing upload and
download traffic. (The existing single-item Network shows only % usage).
- Updates the default docks to include both the primary Performance
Monitor band (CPU and RAM) and the new Network Speeds (Received / Sent)
band.

This PR intentionally avoids solving the question of what to do with the
original Performance dock band, that should be triaged separately.

<!-- 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
2026-08-08 13:41:42 -05:00
Jiří Polášek
03c571e1fc CmdPal: Aggregate net adapter stats and default adapter selection (#49678)
## Summary of the Pull Request

This PR introduces a new virtual network adapter in performance monitor
that sums up data from all physical adapters. That way users will see
any network usage, and for most of them it might be good enough. For the
rest, this PR adds a new command to set any network adapter as a
default.

- Switches from Performance Counters to raw GetIfTable2.
- Adds a new virtual network adapter "All" and uses it as a default.
- Adds a new command to set an actual default network adapter for the
perfmon.

<!-- 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
2026-08-08 13:40:59 -05:00
Jiří Polášek
9cfba78b60 CmdPal: Clean up removed top-level view models (#49728)
<!-- 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 ensures that manager-owned top-level commands and dock bands
release their extension subscriptions when they leave their collections.
Previously, provider reloads, removals, and enable/disable cycles could
retain discarded view models and their extension object graphs.

- Add an explicit cleanup path to `TopLevelViewModel`.
- Clean up commands and dock bands displaced by provider updates.
- Clean up entries removed during full command reloads.
- Clean up provider entries when a provider is removed or disabled.
- Perform cleanup after releasing collection locks.

<!-- 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: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 13:39:50 -05:00
Jiří Polášek
a18779ec7c CmdPal: Clean up replaced command view models (#49730)
<!-- 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 formalizes ownership of command view models so replacing a
command releases the outgoing owned instance without cleaning up
commands borrowed by synthetic context items. It applies the same
cleanup discipline to parameter commands and partially built parameter
lists.

This is one of the places that let Command Palette hold COM proxies much
longer than it's desirable.

- Track whether a `CommandViewModel` is owned or borrowed.
- Add replacement logic that cleans up outgoing owned commands.
- Add a borrowing path for shared command instances.
- Clean up commands replaced in parameter view models.
- Roll back partially initialized parameter-list updates.
- Add regression tests for replacement and failure paths.

<!-- 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
2026-08-08 13:05:35 -05:00
Jiří Polášek
a0619fe430 CmdPal: Release extension objects after navigation (#49732)
<!-- 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 replaces the bare collection performed after leaving a list page
with a complete collection and finalization cycle. WinRT and COM proxies
are released by their finalizers, so a single `GC.Collect()` can leave
extension-owned objects retained on the finalizer queue.

Correctly offloaded onto background thread shouldn't pose UX issue, and
finalizers are only way to release COM garbage.

For now, I left the call only in the original place:
- Content and Parameter pages shouldn't generate too much garbage, so we
don't have to push for release explicitly.
- I considered cleanup when the CmdPal cloaks, but that would be
redundant to the cleanup after navigation.

Changes:
- Adds a reusable `ExtensionObjectReleaser` class that can push hard
enough on GC to trash COM garbage.
- Schedules cleanup after navigation instead of collecting immediately.
- Runs a collect, finalizer drain, and second collect off the UI thread.
- Debounces navigation bursts into a single cleanup cycle.
- Reschedules requests when another release cycle is already running.

<!-- 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
2026-08-08 13:01:47 -05:00
Copilot
14b09db016 Add Brave Browser keyboard shortcuts manifest for Shortcut Guide (#49615)
Shortcut Guide had no manifest for Brave Browser, so no shortcuts were
displayed when Brave was the active window.

## Summary of the Pull Request

Adds `BraveSoftware.BraveBrowser.en-US.yml` to the Shortcut Guide
manifests directory. Uses `WindowFilter: "brave.exe"` to match the
active process. The index is auto-generated at runtime by enumerating
all `.yml` files, so no code changes are required.

## 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

57 shortcuts across 4 sections, mirroring the Chrome manifest structure
(Brave is Chromium-based) with Brave-specific adjustments:

- **Tabs and windows** — standard tab/window management plus Brave's
unique "New private window with Tor" (`Ctrl+Alt+N`)
- **Brave features** — Brave Shields toggle (`Alt+D`), bookmarks bar,
history, downloads, DevTools, task manager, find bar, clear browsing
data
- **Address bar** — navigation and search shortcuts
- **Web page** — print, save, reload, zoom, bookmarking, page source,
scrolling

## Validation Steps Performed

- YAML parsed and validated programmatically; structure matches the
existing manifest schema
- Confirmed `WindowFilter: "brave.exe"` matches the Brave Browser
executable name
- Confirmed index.yml is generated at runtime from all `.yml` files — no
index update needed

<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes #49605

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
2026-08-08 19:58:14 +02:00
Jiří Polášek
d96144a506 CmdPal: Prevent crashes when switching main window backdrops on the fly (#49755)
<!-- 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 prevents CmdPal from crashing when switching backdrops and fixes
transparent tint.

- Keeps a single SystemBackdrop attached and root projected targets
until WinUI disconnects them.
- Swaps and dispose controllers, brushes, and compositors on the XAML
thread.
- Restores tint for transparent solid backdrops using a retained
composition brush.
- Coalesces theme updates and retry transient native backdrop handoffs.
- Adds a fallback background if "Ooops" happens.


<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist

- [x] Closes: #49744
<!-- - [ ] 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
2026-08-08 12:48:24 -05:00
Mike Griese
f2796b74a5 CmdPal: make dialogs prevent compact mode from being collapsed (#49451)
ContentDialogs we present for CommandResult.Confirm need to be visible.
When the window is clipped for compact mode, the dialog is predictably
also collapsed.

This makes sure that content dialogs are always visible, by forcing us
out of compact mode when dialogs are shown.

Closes: quite sure it was filed somewhere, right?
2026-08-08 10:34:53 -05:00
Gleb Khmyznikov
a87f5b07a9 Advanced Paste additional customizations and PhiSilica provider (#46727)
## Summary

Adds an on-device **Phi Silica (Windows AI) paste provider** to Advanced
Paste and richer
per-action customization, plus the **package-identity plumbing** that
lets the unpackaged
Advanced Paste app use Windows AI APIs.

> Note: this supersedes the earlier "self-contained MSIX package
installed/registered by the
> WiX installer" approach. Advanced Paste is **not** packaged or
installed as a standalone
> MSIX. It keeps shipping as the existing unpackaged, self-contained
WinUI 3 executable in
> `WinUI3Apps/` and acquires **package identity at runtime from the
existing PowerToys sparse
> package** — there are no installer or ESRP MSIX repack changes.

## Advanced Paste features

- **New Phi Silica paste provider**
(`CustomActions/PhiSilicaPasteProvider.cs`): an on-device
AI provider backed by the Windows AI Phi Silica language model — no
cloud endpoint or API
key required. Registered as a new `AIServiceType` via
`PasteAIProviderFactory` /
  `AIServiceTypeRegistry`.
- **Additional custom actions** (`AdvancedPasteAdditionalAction`):
user-defined actions with
their own prompt, system prompt, AI provider, and shortcut — plus an
optional "coaching"
prompt/system-prompt/provider/shortcut and shortcut-conflict detection.
- **Built-in default prompts** (`AdvancedPasteDefaultPrompts`) and
updates to
  `AdvancedPasteCustomAction`, `PasteFormat(s)`, `OptionsViewModel`, and
`PasteFormatExecutor` to support per-action provider selection and
system prompts.
- **Settings UI** (`AdvancedPastePage.xaml`/`.xaml.cs`,
`Resources.resw`): configure the
Phi Silica provider, choose a provider per action, edit system/coaching
prompts, and a
Phi Silica availability/readiness experience — Settings queries the
Advanced Paste
executable via `--check-phi-silica`, and a **"Download model"** action
triggers
  `--prepare-phi-silica` to fetch the model and then re-probes.

## Package identity for Windows AI (replaces the MSIX-install approach)

- Phi Silica is a **Limited Access Feature (LAF)** that can only be
unlocked by a process
with a registered **package identity**. Advanced Paste runs unpackaged,
so it obtains
identity from the existing **`Microsoft.PowerToys.SparseApp`** sparse
package
(`src/PackageIdentity/`): a new `<Application
Id="PowerToys.AdvancedPasteUI">` entry in
`AppxManifest.xml` maps it to `PowerToys.AdvancedPaste.exe`, with
matching updates to
  `BuildSparsePackage.ps1`.
- **LAF unlock** at runtime via `PhiSilicaLafHelper.cs`. The
token/attestation are baked at
build time by the `GeneratePhiSilicaLafCredentials` MSBuild target into
`PhiSilicaLafCredentials.g.cs` — local **dev defaults** live in
`src/PhiSilicaLaf.props`
(imported from `Directory.Build.props`) and the **production secret** is
injected via
  `/p:` in the release pipeline.
- New **`AdvancedPaste.dev.manifest` / `AdvancedPaste.prod.manifest`**
application manifests
(selected by `CIBuild`) declaring full-trust and the system AI models
capability.

## Build & pipeline

- **Windows App SDK** moved to the coherent **stable `2.2.0`** line and
**added
`Microsoft.WindowsAppSDK.AI` `2.2.3`** (the Phi Silica APIs). Foundation
`2.1.0` carries the
sparse-identity PRI fix, and the stable AI build matches the OS Windows
AI runtime.
- **Independent versioning** for Advanced Paste
(`src/modules/AdvancedPaste/custom.props`,
XES one-store versioning, `AdvancedPasteVersion`). A
`steps-setup-versioning.yml` step is
added for Advanced Paste in `job-build-project.yml`, ordered **before**
CmdPal to avoid a
  version-collision installer failure (WIX0103).
- `release.yml` passes `PhiSilicaLafToken`/`PhiSilicaLafAttestation`
into the main build;
  spell-check allow-list/patterns updated.
- Removed now-unneeded dependencies: the
`Microsoft.Windows.Compatibility` reference and the
  `Common.UI` "force matching DLL versions" hack.
  
<img width="1073" height="716" alt="image"
src="https://github.com/user-attachments/assets/9364d86a-c0d1-4a08-a669-d98cbcb4b140"
/>
<img width="1038" height="308" alt="image"
src="https://github.com/user-attachments/assets/00eef1dd-b407-4841-bd64-f54f8a145c46"
/>
<img width="194" height="405" alt="image"
src="https://github.com/user-attachments/assets/d2f9c5bb-2507-4112-b3e0-56da681f88ea"
/>
<img width="489" height="453" alt="image"
src="https://github.com/user-attachments/assets/811d1afd-9993-48be-824e-82bb56c5ceca"
/>

[Video clip
internal](https://onedrive.cloud.microsoft/✌️/a@9n6nl3fp/S/cQpvAHrL5M9ZR6eUawztyfyBEgUCwCF-aKg9TbKyyGWP4c0KMA)

[Build
internal](https://microsoft.visualstudio.com/Dart/_build/results?buildId=149920754&view=artifacts&pathAsName=false&type=publishedArtifacts)

---------

Co-authored-by: Niels Laute <niels.laute@live.nl>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
2026-08-08 07:43:59 +02:00
Jiří Polášek
56025d7372 CmdPal: Separate in-flight icon loads from cached results (#49738)
<!-- 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 is stacked on #49737 and separates in-flight icon loading from
completed-result caching. The XAML request path no longer takes a
provider-wide lock, while concurrent requests for the same icon still
share a single task and completion cleanup can retire only that exact
task generation.

The loader now reports whether queue admission succeeded, preventing
requests rejected during shutdown from remaining pending indefinitely.

Overall, it seems that we got rid of a lock and actually reduced
turnaround on UI thread. The separate in-flight tracking takes its tall,
but overall throughput increased (tl;dr - it's faster).

- Deduplicate outstanding icon loads in a dedicated in-flight
dictionary.
- Cache successful tasks before atomically retiring their in-flight
entries.
- Keep failed and rejected loads out of the adaptive cache so they can
be retried.
- Replace `EnqueueLoad` with `TryEnqueueLoad` and fault rejected
requests.
- Add tests for concurrent loading, publication ordering, failures,
rejection, and retries.

<!-- 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
2026-08-07 14:15:34 -05:00
Jiří Polášek
601460561a CmdPal: Avoid all-stripe locking in the adaptive icon cache (#49737)
<!-- 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 removes all-stripe synchronization from `AdaptiveCache`. Using
`ConcurrentDictionary.Count` for capacity checks and `Keys` while
clearing could acquire every dictionary stripe, allowing XAML-bound icon
cache operations to wait behind unrelated concurrent mutations.

**The main problem here is that WinUI doens't take locked main STA
thread well and can fail-fast the app.**

- Track an approximate entry count with atomic updates after successful
mutations.
- Use the approximate count for capacity checks and maintenance
decisions.
- Enumerate the dictionary directly when clearing instead of
snapshotting `Keys`.
- Add concurrent cleanup and count-consistency regression tests.
- Add a matching CmdPal UI unit-test project to the solution.

<!-- 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
2026-08-07 12:40:13 -05:00
Jiří Polášek
3a84795531 CmdPal: Avoid redundant performance widget refreshes (#49735)
<!-- 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 removes a redundant collection refresh from Performance
Monitor's periodically invoked disk metrics callback. The callback
already updates the existing list item titles in place, so raising
`ItemsChanged` on every sample needlessly asks Command Palette to
refresh an unchanged collection.

- Stop raising `ItemsChanged` from the disk page's `Updated` handler.
- Continue updating disk usage and read/write speed titles in place.
- Avoid repeated collection refresh work during periodic performance
sampling.
2026-08-07 12:30:15 -05:00
Jiří Polášek
a5b1ec8124 CmdPal SDK: Fix weak command property subscriptions (#49731)
<!-- 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 fixes a weak-event subscription in the CmdPal toolkit that still
captured its owning `CommandItem` through an instance callback. That
strong reference defeated the weak listener, while command replacement
could also leave a stale handler attached to the outgoing command.

- Make the command property-change callback static.
- Resolve the owning `CommandItem` through the listener's weak
reference.
- Explicitly unsubscribe from the outgoing command during replacement.
- Retain the detach callback that removes dead listeners from long-lived
commands.
2026-08-07 12:28:40 -05:00
Jiří Polášek
d70ab95355 CmdPal: Remove article from "Select a file" button text (#49752)
<!-- 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 changes file picker parameter button text from "Select a file"
to "Select file".

## Pictures? Pictures!

<img width="1600" height="953" alt="image"
src="https://github.com/user-attachments/assets/221eeceb-ac49-4469-8989-b8d01cb4dd2c"
/>


<!-- 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
2026-08-07 15:58:28 +00:00
Niels Laute
57d32bcb6b Fix Keyboard Manager editor file picker not opening when elevated (#48876)
## Summary

Fixes #48845.

In the new WinUI 3 Keyboard Manager editor, clicking the **browse icon**
to select a program path (or "start in" folder) for the *Run Program*
action did nothing — no dialog appeared.

### Root cause

The editor (`PowerToys.KeyboardManagerEditorUI.exe`) is launched by the
Keyboard Manager module DLL via `ShellExecuteExW` from inside the
PowerToys runner (`src/modules/keyboardmanager/dll/dllmain.cpp`). When
PowerToys runs elevated, the editor **inherits that elevation**.

The browse buttons used the legacy **`Windows.Storage.Pickers`**
(`FileOpenPicker` / `FolderPicker` + `InitializeWithWindow`). Those
pickers activate through the UWP runtime broker, which fails with
`E_ACCESSDENIED` in an elevated process. The handlers were `async void`
with no `try/catch`, so the exception was swallowed and no dialog ever
opened. Typing/pasting a path into the field still worked — matching the
bug report.

### Fix

Switch both handlers to the Windows App SDK
**`Microsoft.Windows.Storage.Pickers`** API, constructed with a
`WindowId`. Those pickers are a thin wrapper over the in-process Win32
Common Item Dialog (`IFileOpenDialog`, `CLSCTX_INPROC_SERVER`) and work
correctly in elevated processes — the same mechanism already used
elsewhere in PowerToys (e.g. Settings UI
`IFileDialog`/`GetOpenFileName`, and CmdPal which already uses this
exact namespace). Also wrapped the handlers in `try/catch` with
`Logger.LogError` so any future failure is logged instead of silently
swallowed.

### Verification

- Built `KeyboardManagerEditorUI.csproj` (Release / x64) with all native
dependencies — exit code 0.
- Confirmed against the Windows App SDK source that
`Microsoft.Windows.Storage.Pickers.FileOpenPicker` uses
`create_instance<IFileOpenDialog>(CLSID_FileOpenDialog,
CLSCTX_INPROC_SERVER)` and `dialog->Show(hwnd)`, i.e. the elevation-safe
in-process dialog.

### Notes / out of scope

The report also mentions some apps (e.g. `visio.exe`) not launching
while others (`winword.exe`) do. That's a separate issue in the launch
path (`run_non_elevated` uses `CreateProcessW`, which ignores registry
App Paths / shell activation, unlike `ShellExecute` used by the *Open
URI* action) and is **not** addressed here.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Copilot-Session: 1f00def4-e790-4071-96c6-a81c9c2adba5
2026-08-07 17:05:47 +02:00
Jiří Polášek
9f2ddf6e85 CmdPal: Set Settings window titlebar PreferredTheme to UseDefaultAppMode (#49750)
## Summary of the Pull Request

This PR should fix the incorrect foreground color of title bar glyphs
after a theme change by setting the Settings window's title bar
`PreferredTheme` to [`TitleBarTheme.UseDefaultAppMode`](https://learn.microsoft.com/en-us/windows/windows-app-sdk/api/winrt/microsoft.ui.windowing.titlebartheme?view=windows-app-sdk-2.0).
2026-08-07 09:57:35 -05:00
Jiří Polášek
81d3bb8e34 CmdPal: Initialize page icons after property changes in PageViewModel (#49672)
## Summary of the Pull Request

This PR is a quick fix for pages that changes their icon at runtime, and
then the icon is nowhere to be seen.

<!-- 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
2026-08-07 09:53:08 -05:00
Niels Laute
363226587b feat(settings-ui): add update channel selector (#49722)
Supersedes #49719, which cannot be reopened because its original base
branch was deleted after #49414 merged.

## Summary of the Pull Request Improves the update settings introduced
by #49414 by replacing the prerelease checkbox with a dedicated **Update
channel** expander. Users can choose between Stable and Insider
channels, see the current selection while the expander is collapsed, and
access the PowerToys Insider documentation. The new expander preserves
the existing `IncludePrereleaseUpdates` setting and displays its own
managed-by-organization state when the preview update policy is
configured. <img width="1576" height="526" alt="image"
src="https://github.com/user-attachments/assets/35863d4b-5ca1-4662-9d84-f184c98dbbc6"
/> ## PR Checklist - [x] **Communication:** This builds on the update
channel work merged in #49414 - [ ] **Tests:** No automated tests added;
this is a Settings UI presentation change over the existing setting -
[x] **Localization:** All end-user-facing strings can be localized - [ ]
**Documentation updated:** Documentation changes are maintained
separately ## Detailed Description of the Pull Request / Additional
comments - Moves `IncludePrereleaseUpdates` out of the general update
settings list into a dedicated SettingsExpander in
`src/settings-ui/Settings.UI/SettingsXAML/Views/GeneralPage.xaml`. -
Adds Stable and Insider radio-button choices, descriptions, collapsed
status text, and an Insider learn-more link. - Adds localized strings in
`src/settings-ui/Settings.UI/Strings/en-us/Resources.resw`. - Separates
the preview update policy warning from the other update settings
warnings in
`src/settings-ui/Settings.UI/ViewModels/GeneralViewModel.cs`. ##
Validation Steps Performed - Built
`src/settings-ui/Settings.UI/PowerToys.Settings.csproj` for Debug ARM64
with the repository build script. - Applied the repository XAML Styler
configuration to `GeneralPage.xaml`.

---------

Copilot-Session: 4169c03d-5e17-4495-b7b1-8e6af0d6565c
2026-08-07 16:40:44 +08:00
Niels Laute
9df98bdad3 Add progress/result window to the Bug Report flow with a GitHub issue shortcut (#48980)
## Summary of the Pull Request

Adds a small, native progress/result window to the **Bug Report** flow
so users get feedback while the report is generated and a one-click path
to file a GitHub issue.

Previously, triggering "Report bug" (from the tray menu or **Settings →
General**) ran `PowerToys.BugReportTool.exe` hidden for ~30 seconds with
**no feedback at all**, then popped a plain message box. Many users then
had to manually find the `.zip` and figure out where to file the issue.

Now the runner shows a lightweight window that:

- Displays an animated **"Generating bug report…"** state while the tool
runs.
- On completion, shows **where the `.zip` was saved**
(`…\Desktop\PowerToysReport_<timestamp>.zip`) in a read-only, copyable
field.
- Offers **Open folder** (reveals/selects the `.zip` in Explorer) and
**Report on GitHub** (opens the prefilled `bug_report.yml` issue
template *and* reveals the `.zip` so it can be dragged into the issue).
- Shows a clear error state if the report could not be created.

> Note: GitHub has no API/URL to pre-attach a binary to a new issue
(attachments only happen via browser drag-drop). So the "Report on
GitHub" action does the next best thing: opens the prefilled issue page
and highlights the `.zip` in Explorer for a single drag to attach.


https://github.com/user-attachments/assets/9307d728-bbbd-4258-9480-ced65d2fa065


## PR Checklist

- [ ] Closes: #xxx
- [x] **Communication:** Lightweight, additive UX on an existing
feature; happy to adjust per maintainer feedback.
- [ ] **Tests:** No automated tests (native Win32 window in the runner);
validated manually — see below.
- [x] **Localization:** All end-user-facing strings are added to
`src/runner/Resources.resx` and loaded via `GET_RESOURCE_STRING`.
- [ ] **Dev docs:** N/A
- [x] **New binaries:** None — `bug_report_dialog.cpp/.h` compile into
the existing `PowerToys.exe` (runner). No new WinUI app or DLL, so no
signing/WXS/CI changes required.

## Detailed Description of the Pull Request / Additional comments

- New files `src/runner/bug_report_dialog.{h,cpp}` implement the window
as plain Win32 (no Common Controls v6 dependency, no managed/WinUI
payload), so it works for **both** entry points since it lives in the
runner.
- `bug_report.cpp` now calls `run_bug_report_dialog(...)` instead of the
silent run + message box. The "running" state (observed by Settings) is
cleared as soon as the **tool process** exits, so the result window can
stay open without keeping the Settings button spinning. A guard
re-focuses an already-open window instead of starting a second report.
- The window uses the canonical `AttachThreadInput` foreground recipe so
it reliably surfaces even when launched from Settings (a different
foreground process), and gets a taskbar button so it stays findable
during the ~30s run.
- The output path is discovered by locating the newest
`PowerToysReport_*.zip` in the Desktop folder after the tool exits (the
tool names the file internally with a timestamp).
- Strings added: dialog title, generating/hint text, done header/hint,
failed text, and button captions.

## Validation Steps Performed

- Triggered **Report bug** from the **system tray** menu: window appears
in the foreground, animates "Generating…", then shows the saved `.zip`
path with working **Open folder** and **Report on GitHub** buttons.
- Verified **Open folder** selects the `.zip` in Explorer and **Report
on GitHub** opens the prefilled `bug_report.yml` issue template with the
`.zip` highlighted for drag-and-drop.
- Verified the error state renders correctly (and wraps long localized
text) when the tool can't run.
- Built `runner` (ARM64, Debug) clean; verified end-to-end on a high-DPI
display.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
2026-08-07 10:08:56 +02:00
Boliang Zhang
bb12277d8d fix(ci): support automatic versions and counter-exhaustion recovery (#49745)
## Summary of the Pull Request

Follow-up to #49414 that fixes two release-pipeline recovery issues:

- Azure DevOps treats an empty runtime string parameter as required, so
`.pipelines/v2/release.yml` now uses `auto` as the default version
override.
- Explicit `main` and `stable` version overrides are resolved before
automatic `YDDDB` generation, allowing a manually versioned build to
proceed after the daily sequence exceeds 9.

## PR Checklist

- [x] **Communication:** This is a follow-up to the reviewed
preview-release versioning design in #49414
- [x] **Tests:** Added/updated and all pass

## Detailed Description of the Pull Request / Additional comments

`auto` is normalized to an empty override in
`.pipelines/resolveBuildMetadata.ps1`, preserving automatic
release-train version generation without requiring input in the Run
Pipeline dialog.

Override parsing is now separated from automatic version generation.
Full explicit versions bypass daily-sequence and generated-date
validation, while automatic versions continue to require a sequence from
1 through 9 and fail closed outside that range.

`.pipelines/tests/resolveBuildMetadata.Tests.ps1` covers scheduled
`main` with the `auto` default, automatic `stable` generation, and
explicit preview/stable recovery when the daily counter has reached 10.

## Validation Steps Performed

- `Invoke-Pester .pipelines\tests\resolveBuildMetadata.Tests.ps1
-EnableExit` — 22 passed
- Confirmed `auto` resolves a first August 7 stable build to
`0.100.2191.0`
- Confirmed explicit `0.101.0` resolves to `0.101.0.0` with daily
sequence 10

Copilot-Session: 8e04a72e-3b0f-4ac4-8156-d04ea9b8bb85
2026-08-07 15:34:29 +08:00
Michael Clayton
e0010c5642 Ready for Review - [Mouse Jump] - port upstream WinUI3 code to Mouse Jump (microsoft#48290) (#48393)
<!-- 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

Changes for #48290 to convert Mouse Jump to a WinUI app and remove all
remaining dependencies on WinForms, based on work already done in the
original "FancyMouse" project
(https://github.com/mikeclayton/FancyMouse).

## Notes for reviewers

* the new WinUI build of the app is output into the "/WinUI3Apps"
subfolder

* there's 2 new assemblies that need to be added to the installation as
well - MouseJump.HotKeys.dll and MouseJump.Models.dll. I'm not sure how
to add those to the installer for signing / shipping...

---

### Summary of changes

* New thumbnail layout and rendering code
* WinUI rewrite (winforms version still committed)
* MouseJump.Kicker (dev launch tool)
* CsWin32 for interop
* New assemblies - code reorganised

---

### 1. New layout code

Incorporates latest FancyMouse core layout and rendering logic into
Mouse Jump:

* includes **support** for multiple devices in layout algorithms
* preview still only shows local machine though
* prerequisite for long-term goal #34126

<img width="650" height="709" alt="image"
src="https://github.com/user-attachments/assets/9d1d996d-ed05-4471-b8a5-bd93442f70dc"
/>

### 2. WinUI rewrite

Port latest stable FancyMouse WinUI implementation into Mouse Jump.

Existing WinForms UI left in-situ side-by-side for now - easy to delete
if not needed.

### 3. MouseJump.Kicker

A small dev utility to start Mouse Jump without needing to build the
runner project:

<img width="283" height="274" alt="image"
src="https://github.com/user-attachments/assets/c81bb3f5-5008-48ce-8bc0-eef18413dee6"
/>

### 4. Cswin32 for interop

All win32 interop is now accessed via CsWin32 bindings.

The original win32 bindings were heavily influenced by CsWin32 generated
code (e.g. ```BOOL```, ```HWND```, etc structs), so there's not actually
much change other than deleting a lot of boilerplate code.

### 5. New assemblies

Some code has been reorganised into new assemblies to make it easier to
keep Mouse Jump in sync with upstream FancyMouse

* MouseJump.HotKeys
* MouseJump.Models




<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist

- [x] Closes #48290
- [x] **Communication:** I've discussed this with core contributors
already. If 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
  -  all ui strings come from Resources.resw
- [x] **Dev docs:** Added/updated
  -  no changes required
- [x] **New binaries:** Added on the required places
  -  no changes required
- [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:** 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
  -  no changes required
<!-- 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

- **Workflow tests**
  - [x] Automated tests passing locally
  - [x] Minimal actions workflow (spelling check) passing for PR
  - [ ] Full actions workflow (msbuild) passing for PR
- **UI tests**
  - [x] Happy path
    - [x] preview image appears when activated
- [x] clicking the preview image moves the mouse cursor to the correct
location
- [x] right-click dismisses the preview image without moving the mouse
- [x] pressing escape dismisses the preview image without moving the
mouse
- [x] left or right clicking another application / desktop dismisses the
preview image without moving the mouse
- [x] Works on multiple monitors with different dpi scaling settings
(e.g. 100% vs 150%)
*
https://github.com/microsoft/PowerToys/pull/23566#issuecomment-1411869418
*
https://github.com/microsoft/PowerToys/pull/23566#issuecomment-1412834413
- [x] Handling negative coordinates on non-primary monitors if higher or
"lefter" than primary monitor
*
https://github.com/microsoft/PowerToys/pull/23566#issuecomment-1404931694
- [x] Mouse crosshair moves when Mouse Jump moves the cursor (mouse
clicks *and* keyboard shortcuts)
    * #24523
    * #24527
- [x] Activating when the preview window is already visible moves the
form to the new mouse position
- [x] Number and key shortcuts (1-9, Home / End, Left / Right Arrow)
jump to the appropriate monitor
  - [x] Number-pad shortcuts (1-9 jump to the appropriate monitor
- **Settings tests**
- [x] Changing thumbnail size settings updates the size of the thumbnail
- [x] Changing preview type between Compact, Bezelled and Custom shows
the correct preview type
  - [x] Changing custom preview settings shows the correct settings
- [ ] Launching with settings version 1.0 upgrades settings to version
1.1, with "Bezelled" as the default style and the "Custom" settings
preconfigured to match "Bezelled"
- **Lifecycle tests**
- [x] Starting PowerToys Runner launches MouseJump exe when enabled, and
not when disabled
- [x] Enabling / disabling Mouse Jump in settings starts / stops
MouseJump exe
  - [x] Exiting PowerToys Runner stops MouseJump exe
  - [x] Killing runner exe via Task Manager stops MouseJump exe
  - [x] Stopping Visual Studio local debug run stops MouseJump exe
- note - runner needs to be in *non*-admin mode otherwise Visual Studio
debugger disconnects at launch
- [x] Hotkey and size settings are automatically reloaded when config
file is modified from Settings UI
- [ ] ~~Hotkey and size settings are automatically reloaded when config
file is modified manually (e.g. in notepad) while runner and
MouseJumpUI.exe are running~~
- **[Internal Test
Suite](5bc7201ae2/doc/releases/tests-checklist-template.md (mouse-utils))**
  - [x] Enable Mouse Jump. Then:
- [x] Press the activation shortcut and verify the screens preview
appears.
- [x] Change activation shortcut and verify that new shortcut triggers
Mouse Jump.
- [x] Click around the screen preview and ensure that mouse cursor
jumped to clicked location.
- [x] Reorder screens in Display settings and confirm that Mouse Jump
reflects the change and still works correctly.
- [x] Change scaling of screens and confirm that Mouse Jump still works
correctly.
- [ ] Unplug additional monitors and confirm that Mouse Jump still works
correctly.
- [x] Disable Mouse Jump and verify that the module is not activated
when you press the activation shortcut.

---------

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Boliang Zhang (from Dev Box) <bozhang@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: moooyo <42196638+moooyo@users.noreply.github.com>
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Copilot-Session: 8e04a72e-3b0f-4ac4-8156-d04ea9b8bb85
2026-08-07 13:34:15 +08:00
Clint Rutkas
9fcb8faac5 [Quick Accent] Isolate press-and-hold activation (#49701)
## Summary of the Pull Request

Makes the **Press and hold the letter** activation method exclusive.
Pressing a legacy trigger key (Space or either arrow) before the hold
threshold now cancels that owner-letter gesture and passes the trigger
through normally, instead of allowing the already-scheduled picker to
appear later. Typing any different supported physical letter during the
gesture also cancels it, preventing that intervening character from
being replaced when the owner letter is released.

Space and arrow navigation remains available after a genuine hold
activation reaches its threshold.

## PR Checklist

- [ ] Closes: N/A
- [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: N/A

## Detailed Description of the Pull Request / Additional comments

The native keyboard listener previously armed press-and-hold on
owner-letter key-down and immediately queued a delayed managed render.
Although pre-threshold Space/arrows were excluded from native
trigger-key activation, they did not invalidate that pending render.
Holding the owner letter after pressing Space therefore still displayed
the picker and made both invocation systems feel enabled.

This change adds an explicit native-to-managed cancellation event and a
generation-based managed display state:

- In `PressAndHold`, Space or either arrow before the snapshotted hold
threshold cancels the current gesture and passes through without input
injection.
- Space/arrows at or after the threshold retain their intended picker
navigation behavior.
- Any different physical letter in Quick Accent's supported key set
cancels the owner gesture before passing through, even when that letter
has no mapping in the selected language.
- Owner repeats and owner key-up are handled from active physical
ownership rather than current language eligibility, so live language
changes cannot leave stale state.
- Activation mode, input time, and hold duration are atomically
published and snapshotted once per owner gesture. The native listener
passes the same delay snapshot to managed scheduling, so live settings
changes apply to the next gesture instead of desynchronizing native
interaction from picker visibility.
- Character data is prepared before native navigation can become
interactive, preventing accepted navigation from being dropped.
- Legacy Space/arrow/Both acquisition behavior is preserved.

The low-level hook has no clean deterministic native unit-test seam
because its private handlers depend on Win32 keyboard state. Managed
regression coverage exercises delayed-display cancellation, re-arming,
generation invalidation, and delay snapshot preservation.

## Validation Steps Performed

- Built `src/modules/poweraccent/PowerAccent.UI/PowerAccent.UI.csproj`
in `Debug|x64`, covering the native WinRT projection and managed
Core/UI.
- Built
`src/modules/poweraccent/PowerAccentKeyboardService/PowerAccentKeyboardService.vcxproj`
in `Debug|x64`.
- Built and ran all `PowerAccent.Core.UnitTests`: **35 passed, 0
failed**.
- Ran `git diff --check`.
- Performed focused code reviews of pre-threshold trigger cancellation,
intervening mapped/unmapped letters, live mode/duration snapshots,
language changes, owner key-up balance, and post-threshold navigation.

---------

Copilot-Session: cbd8418a-64cb-4c6c-8653-2f3f0a6ceb9e
2026-08-06 21:14:08 -07:00
Clint Rutkas
ddeb7f1bf5 [Always On Top] Render a solid border frame (#49698)
<!-- 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 the Always On Top frame appearing mottled or translucent even when
frame opacity is set to 100%.

<!-- 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
- [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

The frame helper window is intentionally placed behind the tracked
window. The previous Direct2D rendering used a centered stroke, so the
tracked window occluded the stroke's inner half. With per-primitive
antialiasing enabled, partial-coverage pixels became disproportionately
visible in the remaining thin outer half, making a fully opaque frame
look mottled.

This change replaces the centered stroke with a filled, even-odd
outer/inner geometry ring. It preserves configured opacity, the
transparent interior, DPI-scaled frame thickness and corner radius,
smooth rounded corners, and target-window occlusion while limiting
antialiasing to the ring's actual contours.

It also recreates render-target-bound brush resources when the HWND
render target is recreated, clears stale resources on
`D2DERR_RECREATE_TARGET`, and redraws when rectangle or corner geometry
changes.

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

- Built `src\modules\alwaysontop\AlwaysOnTop\AlwaysOnTop.vcxproj` for
Debug x64 successfully.
- Ran the freshly built `PowerToys.AlwaysOnTop.exe` with frame opacity
100%, thickness 4, and rounded corners enabled.
- Pinned a controlled Win32 window and confirmed it received
`WS_EX_TOPMOST`.
- Confirmed the module created an `AlwaysOnTop_Border` HWND sized
946x627 behind the 960x630 target window.
- Restored the temporary setting change and stopped the test processes.

Residual limitation: the RDP input desktop was detached, so
composed-screen pixel capture was unavailable. `winapp` could capture
the layered border HWND only by flattening transparency to black, which
is not trustworthy visual pixel evidence. An interactive-desktop visual
check is still recommended.

Copilot-Session: c2697877-8736-4e8d-add3-06ed2cec15b9
2026-08-06 20:56:44 -07:00
Jiří Polášek
e403027451 CmdPal: Improve dock buttons (#49703)
## Summary of the Pull Request

- Scales down a dock button icon when pressed down;
  - Gives user a better feedback;
  - Hides delay if the icon changes as a result of that click.
- Adds a small gap between the edge(s) and the dock button;
  - Gives a cleaner visual separation when mouse is over or pressed.
  - Whole area, including the gap is still clickable.
- Updates size of dock button that only has an icon to be a square.
- Updates button style to give it more button/3D appearance on hover.
- Updates sizes and padding in vertical dock layouts to give buttons
more space.

## Pictures? Pictures!



https://github.com/user-attachments/assets/80b59ccf-b7ff-487e-9c63-621a1c91ae89


<img width="1362" height="304" alt="image"
src="https://github.com/user-attachments/assets/ef2a642d-90f5-41d4-a156-deda8d0d2c57"
/>


<img width="575" height="2159" alt="image"
src="https://github.com/user-attachments/assets/e07d5450-6e2f-4ac5-8981-531980807234"
/>


<!-- 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
2026-08-06 14:05:04 -05:00
Niels Laute
848b3a3465 [Mouse Without Borders] Fix German ampersand localization (#49687)
## Summary of the Pull Request

Adds translator guidance for the Mouse Without Borders OOBE description
so the German translation uses a literal ampersand in "Drag & Drop"
instead of displaying the HTML entity text.

## PR Checklist

- [x] Closes: #42943
- [x] **Communication:** Requested by a core contributor
- [x] ~~**Tests:** Added/updated and all pass~~ Not applicable;
localization comment only
- [x] **Localization:** All end-user-facing strings can be localized
- [x] ~~**Dev docs:** Added/updated~~ Not applicable
- [x] ~~**New binaries:** Added on the required places~~ Not applicable
- [x] ~~**Documentation updated:**~~ Not applicable

## Detailed Description of the Pull Request / Additional comments

The German translation of `Oobe_MouseWithoutBorders.Description`
currently renders `Drag &amp; Drop`. The resource comment now gives
translators the exact expected `Drag & Drop` text and clarifies that the
ampersand must be entered as a literal character rather than as an HTML
entity.

## Validation Steps Performed

- Parsed `Resources.resw` as XML and confirmed the comment resolves to
the intended literal ampersand and erroneous entity text.
- Confirmed the patch passes `git diff --check`.

Copilot-Session: abfefd1b-8709-43c9-a1f7-67afb9308804
2026-08-06 20:16:40 +02:00
Michael Jolley
f20348386a [CmdPal] Replace main-page magic-number scoring with a principled tiered ranker (#49189)
>[!WARNING]
> This PR is one in a series of PRs focused on rearchitecting the
search/scoring logic of the `MainListPage`. An explanation of the entire
search/scoring logic can be found below.
> 
> **This PR should not be merged until PR #49190 is merged into it.**

>[!NOTE]
> To test the final result, run the branch associated with PR #49249.

This stack rebuilds how Command Palette ranks and displays results on
its main page.

Strong text matches now consistently appear above weaker ones. Usage
history and provider preferences can improve ordering between similarly
relevant results, but they cannot push a poor match above an obvious
one.

The stack also makes search feel faster. Results appear without waiting
for slower providers, app scoring runs more efficiently, and weak
matches are hidden while the user has typed only one or two characters.
Automated tests protect the new behavior, while privacy conscious
telemetry measures performance and relevance without recording searches.

## Pull requests

1. [#49189](https://github.com/microsoft/PowerToys/pull/49189)
introduces the new ranking foundation. Results are grouped by match
strength, ensuring exact names, prefixes, and acronyms rank above loose
fuzzy matches.

2. [#49190](https://github.com/microsoft/PowerToys/pull/49190) improves
how Command Palette learns from command usage. Recent and frequently
used commands receive a sensible boost, and that history now persists
across restarts.

3. [#49191](https://github.com/microsoft/PowerToys/pull/49191) lets
users give each provider a Lower, Normal, or Higher search preference.
This preference helps resolve close matches without overriding result
relevance.

4. [#49194](https://github.com/microsoft/PowerToys/pull/49194) makes the
first set of results appear sooner. Commands and apps are shown
immediately, while slower fallback results are added when they become
available.

5. [#49195](https://github.com/microsoft/PowerToys/pull/49195) adds a
comprehensive relevance test suite. It verifies that common searches
return the expected results and protects ranking quality from future
regressions.

6. [#49197](https://github.com/microsoft/PowerToys/pull/49197) adds
privacy conscious search telemetry. It measures result counts, response
time, and which result position was selected without recording search
text, result names, paths, or other user content.

7. [#49246](https://github.com/microsoft/PowerToys/pull/49246) adds a
performance measurement suite. It identifies where search time is spent
and provides a reliable way to evaluate performance improvements.

8. [#49247](https://github.com/microsoft/PowerToys/pull/49247) delivers
the main performance improvement. App results are scored in parallel and
expensive work no longer blocks rendering, while the final result order
remains unchanged.

9. [#49249](https://github.com/microsoft/PowerToys/pull/49249) prevents
misleading results from flashing when a search begins. For one or two
character searches, weak fuzzy app matches remain hidden until the query
is specific enough to produce useful results.

> [!WARNING]
> These PRs should be merged in LIFO order starting with #49249 with
this PR being the last.

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
2026-08-06 13:14:37 -05:00
Mike Griese
15df4db8f2 Dock: update the displays list when navigating to dock settings (#49705)
I opened the settings when my laptop was portable.

I docked my laptop to my displays.

I navigated to the dock settings.

I **expected**: to see all my displays

I _actually_: saw only the laptop display

------

the fix: make sure to update the displays when we navigate to the dock
settings page, so that we properly show all of them

Closes: nope didn't file this
2026-08-06 11:38:09 -05:00
Boliang Zhang
558e633c59 Add preview release versioning and update channel support (#49414)
## Summary
- Publish scheduled `main` builds as GitHub prereleases while keeping
manual `main` runs as preview validation builds.
- Add an opt-in Settings switch for prerelease update checks; stable
updates remain the default.
- Use one MSI-safe version across bundles, MSI packages, binaries,
symbols, and package manifests.
- Prevent preview releases from triggering Microsoft Store, WinGet, or
public-symbol publication.
- Label preview builds explicitly in Settings, update notifications, and
What's New.

## Build intent

| Source | Trigger | Intent |
| --- | --- | --- |
| `main` | Scheduled | Publish a preview release |
| `main` | Manual | Validate a preview build without publishing |
| `stable` | Manual | Produce a stable release |
| Other branches | Any supported trigger | Produce a private validation
build |

## MSI-safe release versioning

Windows Installer compares only `major.minor.build` and ignores the
fourth version component. Preview and stable release builds therefore
use:

```text
major.minor.YDDDB.0
```

- `Y`: zero-based number of calendar years since `ReleaseTrainEpoch`.
- `DDD`: three-position calendar day of year.
- `B`: daily release sequence `1-9`.
- The fourth component is always `0`.

With `ReleaseTrainVersion=0.100` and `ReleaseTrainEpoch=2026-01-01`:

```text
0.100.2111.0   = July 30, 2026, release build 1
0.100.3659.0   = December 31, 2026, release build 9
0.100.10011.0  = January 1, 2027, release build 1
```

The allocator formats `DDD` as exactly three digits before converting
the MSI component to its numeric representation. Leading zeros may not
be displayed because Windows version components are numeric; decoding
remains positional:

```text
B   = component % 10
DDD = (component / 10) % 1000
Y   = component / 10000
```

`ReleaseTrainVersion` and `ReleaseTrainEpoch` are checked in under
`src/Version.props`. The epoch remains January 1 of the active epoch
year and advances on the first release-train minor change in a new year.

## Daily release counter

Azure DevOps persists the daily sequence server-side using a counter
keyed as `release-YYYYMMDD`.

- `main` and `stable` share the same daily counter.
- Other branches do not evaluate or consume the release counter.
- Failed or canceled `main`/`stable` runs may leave gaps.
- The build fails when the daily sequence exceeds `9`.
- The counter date and encoded `YDDD` date both use
`pipeline.startTime`.

Private branches retain independent `0.0.<extended-day><NN>.0`
validation versions.

## Update behavior
- Stable users continue to query GitHub's stable latest-release path.
- Users who explicitly enable preview updates can select newer GitHub
prereleases.
- Preview releases and notifications are labeled as PowerToys Preview.
- What's New separates preview entries from stable release history and
hides previews by default.

## Validation
- 17 Pester tests cover `main`, `stable`, private branches, year
rollover, epoch reset, monotonicity, override validation, sequence
limits, and date alignment.
- Version propagation verified `0.100.2111.0` in `Version.props` and all
affected AppX/MSIX manifests.
- Azure DevOps pipeline dry-runs succeeded for both `refs/heads/main`
and `refs/heads/stable`.
- The affected native version project builds successfully.
- PR CI is green for x64, ARM64, Command Palette SDK, dependency review,
telemetry detection, and CLA.

## Remaining end-to-end checks
- Install two locally or officially produced installers with consecutive
MSI-visible `YDDDB` versions and verify the upgrade preserves binaries,
package registrations, hardlinks, and shell integrations.
- On the first natural post-merge `main` or `stable` run, verify the
production counter value and resolved version in the release logs.
## Local GPO verification

Validated locally with the signed `v0.100.2171` build from Azure DevOps
build
[153961073](https://microsoft.visualstudio.com/Dart/_build/results?buildId=153961073).
These checks cover the administrative-template integration and Settings
behavior.

### Policy enabled: preview updates are disabled

With `PreviewUpdatesDisabled=1`, **Include prerelease updates** is
forced off and locked, and Settings displays the
managed-by-your-organization notice.

![PowerToys Settings with preview updates disabled by
policy](https://raw.githubusercontent.com/LegendaryBlair/PowerToys/df808630b04e65ba437081aff9401c4efd58e67f/.github/pr-assets/49414/gpo-policy-enforced.png)

### Policy removed: the user preference is preserved

After removing `PreviewUpdatesDisabled` and restarting PowerToys, the
previously selected preview-update preference is restored and editable.
The policy suppresses the preference without overwriting it.

![PowerToys Settings with the preview-update preference
restored](https://raw.githubusercontent.com/LegendaryBlair/PowerToys/df808630b04e65ba437081aff9401c4efd58e67f/.github/pr-assets/49414/gpo-preference-restored.png)

### Group Policy Editor

After importing the updated ADMX/ADML templates, **Disable preview build
updates** appears under **Microsoft PowerToys > Installer and Updates**.
The policy dialog documents that **Enabled** blocks preview updates,
while **Disabled** or **Not Configured** leaves the choice available to
the user.

![Disable preview build updates in Local Group Policy
Editor](https://raw.githubusercontent.com/LegendaryBlair/PowerToys/e9e5c12f4480ef895d263460a59982246b7654dc/.github/pr-assets/49414/group-policy-editor-policy-dialog.png)

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: ad8b7909-0472-4464-bdee-deaeca726f94
Copilot-Session: 8e04a72e-3b0f-4ac4-8156-d04ea9b8bb85
2026-08-06 23:45:11 +08:00
Copilot
0126a1aff0 Add Desktop Peek to Shortcut Guide Windows shortcuts (#49638)
<!-- 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

Shortcut Guide was missing the Windows desktop peek shortcut (`Win + ,`)
from the Windows shell shortcuts it displays. This update adds the
missing entry and pins it with a focused manifest test.

<!-- Please review the items on the PR checklist before submitting-->
## 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

<!-- 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

- **Shortcut manifest**
- Adds `Peek at desktop temporarily` to the Windows shell manifest in
the `Windows key` section.
- Models the shortcut as `Win + ,`, matching the OS behavior Shortcut
Guide should surface.

- **Regression coverage**
- Adds a focused unit test that deserializes
`+WindowsNT.Shell.en-US.yml` and asserts the Desktop Peek entry is
present with the expected shortcut payload.

```yml
- Name: Peek at desktop temporarily
  Shortcut:
    - Win: true
      Ctrl: false
      Shift: false
      Alt: false
      Keys:
        - ","
```

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

- Parsed the updated `+WindowsNT.Shell.en-US.yml` manifest and verified
the new entry is present in the `Windows key` section.
- Added a manifest-focused unit test covering the new shortcut entry.

<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes #49458

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
2026-08-06 14:52:26 +00:00
Niels Laute
581be30101 [Mouse Utilities] Clarify Gliding Cursor description (#49691)
## Summary
- replace the misleading Gliding Cursor description in PowerToys
Settings
- clarify that the feature positions the cursor and clicks using only a
keyboard shortcut

## Validation
- parsed `Resources.resw` as XML
- `git diff --check`
- Settings UI dependency restore completed; the build could not finish
because the D: drive ran out of space

Addresses #45598.

Copilot-Session: a53b4a7f-26bc-41e1-963a-c80ec33a4b1c
2026-08-06 15:47:24 +02:00
Niels Laute
286d6e767a [Settings] Make attribution links localizable (#49690)
## Summary of the Pull Request

Moves Settings attribution link text into localized resources so Turkish
and other locales can translate grammatical wording while preserving
contributor and product names. Also makes the technical term
"Stereolithography" translatable.

## PR Checklist

- [x] Closes: #35272
- [x] **Communication:** Requested in #35272
- [x] **Tests:** Resource/XAML-only change; the ARM64 Debug Settings UI
build passes
- [x] **Localization:** All end-user-facing strings can be localized
- [x] **Dev docs:** Not applicable
- [x] **New binaries:** Not applicable
- [x] **Documentation updated:** Not applicable

## Detailed Description of the Pull Request / Additional comments

The affected attribution labels were hard-coded in XAML, preventing the
localization pipeline from translating text such as "and other original
contributors." Each label now uses an `x:Uid` resource, with translator
comments that explicitly identify contributor, product, and file-format
names that must remain unchanged. Links containing only a person or
product name remain hard-coded.

The locked `Stereolithography` resource is also unlocked because it is a
translatable technical term rather than a name.

## Validation Steps Performed

- Restored and built PowerToys build essentials for ARM64 Debug
- Built `src/settings-ui/PowerToys.Settings.slnf` for ARM64 Debug
- Validated all attribution `x:Uid` values resolve to unique `.Text`
resources

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 98217841-f046-4fe3-a6e0-72046ed9a720
2026-08-06 15:47:06 +02:00
Aryan gupta
6fcbde5484 [Keyboard Manager] Fix shortcut modifier display order in the new editor (#49707)
<!-- 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 shortcut key display order in the new Keyboard Manager editor (C#
WinUI). When recording a shortcut, modifier keys are now always
displayed in the standard canonical order (Win → Ctrl → Alt → Shift →
Action key), regardless of the order the user physically pressed them.
This matches the existing behavior of the old C++ editor's
`GetKeyVector` function.

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist

- [x] Closes: #48943
- [ ] **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

**Bug:** In the new C# KBM editor (`KeyboardManagerEditorUI`), the
`GetFormattedKeyList()` method in `KeyboardHookHelper.cs` displayed
modifier keys in the order the user pressed them rather than the
standard display order. For example, pressing Shift before Win would
show `Shift + Win + S` instead of `Win + Shift + S`.

**Root cause:** The `modifierKeys` list was populated by iterating
`_keyPressOrder` (which preserves temporal press order), and was then
rendered directly without sorting.

**Fix:** Added a sort step before the display loop that sorts modifier
keys using the existing `KeyboardManagerInterop.GetKeyType()` P/Invoke,
which returns the `KeyType` enum value (Win=0, Ctrl=1, Alt=2, Shift=3).
This enforces the canonical order **Win → Ctrl → Alt → Shift → Action
key**, matching the old C++ `EditorHelpers::GetKeyVector()` behavior.

**Scope:** Single-line change in
`KeyboardHookHelper.GetFormattedKeyList()`. This is a display-only fix —
it does not affect the internal key tracking (`_keyPressOrder`),
save/load logic, or hook behavior.

**Changed file:**
-
`src/modules/keyboardmanager/KeyboardManagerEditorUI/Helpers/KeyboardHookHelper.cs`

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

1. Open the new Keyboard Manager editor
2. Click the shortcut trigger button to start recording
3. Press modifier keys in non-standard order (e.g., press Shift first,
then Win, then S)
4. **Before fix:** UI shows `Shift + Win + S`
5. **After fix:** UI shows `Win + Shift + S` (correct canonical order)
6. Verified standard-order input (e.g., Win → Shift → S) still displays
correctly
7. Verified single modifier + action key shortcuts (e.g., Ctrl+C)
display correctly
8. Verified all four modifiers (Win+Ctrl+Alt+Shift+Key) display in
correct order regardless of press sequence
9. Verified saving and loading remappings is unaffected by the display
change
````
2026-08-06 09:44:00 +00:00
Mike Griese
30d070be85 CmdPal: fix alt+f4 handling (#49708)
As I threw in
https://github.com/microsoft/PowerToys/issues/49572#issuecomment-5195807441:

Our alt+f4 handling is wack. We shouldn't close the dock when you press
alt+f4 on it, just like you can't close the taskbar with alt+f4.

But also some folks want alt+f4 to quit cmdpal, and some folks don't. So
there's a setting for what happens when you alt+f4 cmdpal.

Closes #38333
Closes #40277
Closes #49572
2026-08-05 21:06:50 +00:00
Niels Laute
2c1a14b9b8 [Settings] Align File Explorer navigation title (#49692)
## Summary
- keep the `File Explorer Add-ons` source string in the navigation view
- use the same title on the File Explorer Add-ons settings page through
`FileExplorerPreview.ModuleTitle`
- add translator guidance to keep the navigation and page-title values
consistent

## Validation
- parsed `Resources.resw` as XML
- ran `git diff --check`
- verified both resource values resolve to `File Explorer Add-ons`

Fixes #24414.

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: a53b4a7f-26bc-41e1-963a-c80ec33a4b1c
Copilot-Session: 75064a4f-2237-4c2b-97de-c983de9e9ecd
2026-08-05 16:39:29 +02:00
Niels Laute
16baa2d676 [Image Resizer] Clarify preset size descriptions (#49694)
## Summary of the Pull Request

Updates Image Resizer preset descriptions in both the resize dialog and
the Settings page from sentence fragments such as `Fits within 1920 ×
1080 pixels` to CRUTKAS's proposed `Fit - 1920 × 1080 pixels` format.
The UI reuses existing localized mode labels and removes the obsolete
third-person resources.

## Screenshots

### Resize dialog

![Image Resizer dialog showing the new Fit - Width × Height unit
format](https://raw.githubusercontent.com/niels9001/PowerToys/pr-assets/screenshots/49694/image-resizer-preset-format.png)

### Settings page

![Image Resizer Settings page showing the new Fit - Width × Height unit
format](https://raw.githubusercontent.com/niels9001/PowerToys/pr-assets/screenshots/49694/image-resizer-settings-preset-format.png)

## PR Checklist

- [x] Closes: #16790
- [x] **Communication:** Implements the pattern proposed and accepted by
core contributors in #16790
- [x] **Tests:** Existing Image Resizer tests pass; the Image Resizer
and Settings UI projects build successfully
- [x] **Localization:** Reuses existing localized mode and unit strings;
no new translatable text
- [x] **Dev docs:** Not applicable
- [x] **New binaries:** Not applicable
- [x] **Documentation updated:** Not applicable

## Detailed Description of the Pull Request / Additional comments

Preset details now use the infinitive resize mode followed by a neutral
dash and the dimensions on both Image Resizer surfaces. This avoids
requiring translators to make a sentence fragment agree grammatically
with the dimensions.

Accessible Settings descriptions use the same wording, and the obsolete
third-person mode resources are removed from both resource sets.

## Validation Steps Performed

- Built `ImageResizerUI.csproj` for x64 Debug
- Built `ImageResizer.UnitTests.csproj` for x64 Debug
- Ran all 149 Image Resizer unit tests successfully
- Built `Settings.UI.csproj` for x64 Debug
- Ran the PR-built resize dialog and Settings page and verified the new
text in both surfaces

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: f058c3d9-38d8-4a35-8c5e-69100b2b673c
2026-08-05 10:39:17 +00:00
Noraa Junker
2bb28899d7 [Shortcut Guide] Make Shortcut Guide AOT-ready (#49673)
<!-- 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

Makes changes so Shoertcut Guide could be compiled ahead of time

<!-- 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: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
2026-08-05 10:23:23 +00:00
moooyo
bd33911dd8 [Mouse Utilities] Fix Chinese Ctrl translation (#49693)
## Summary of the Pull Request

Adds Simplified and Traditional Chinese translator guidance for both
Find My Mouse double-Control activation options so the localized UI
keeps the familiar `Ctrl` key label instead of using `控制键` or `控制鍵`.

## PR Checklist

- [x] Closes: #46223
- [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

## Detailed Description of the Pull Request / Additional comments

As discussed in
[#46223](https://github.com/microsoft/PowerToys/issues/46223#issuecomment-5189066402),
Chinese users commonly identify this physical keyboard key by its `Ctrl`
label. Translating it as `控制键` in Simplified Chinese or `控制鍵` in
Traditional Chinese makes the Find My Mouse activation options harder to
understand.

PowerToys localized resources are generated through the CDPX
localization pipeline, so this PR expands the translator comments for
both the left and right Control activation strings. The English values,
resource keys, settings schema, UI tests, and runtime behavior remain
unchanged.

## Validation Steps Performed

- Parsed the modified `Resources.resw` successfully as XML.
- Verified both affected Find My Mouse entries contain Simplified and
Traditional Chinese guidance.
- Confirmed the diff changes translator comments only and passes `git
diff --check`.
- No build or automated tests were run because this is a comment-only
localization guidance change with no runtime impact.

---------

Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
2026-08-05 10:11:47 +00:00
Dave Rayment
3079a3c546 [EnvironmentVariables] Validation fixes, centralised validation, error message improvements (#46837)
## Summary of the Pull Request
This fixes several critical validation issues with the Environment
Variables utility, centralises the validation, guards registry writes,
and improves error messages for validation failures.

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist

- [x] Closes: #46763
<!-- - [ ] 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
This PR fixes a reported critical vulnerability (#46763) where creating
an environment variable with an equals sign in the name reportedly
caused Windows to crash and enter a boot loop upon restarting. During
the investigation of the issue, several other environment variable
constraints were identified as missing, including there being no
prevention of leading or trailing spaces in names (meaning variables
could not be typed on the command line), no combined length checks and
so on. This PR introduces a centralised, robust validation pipeline for
UI and registry writes to prevent entering states which could corrupt
the Windows environment block.

## Changes
### Centralised validation logic
- All environment validation is now inside
EnvironmentVariablesHelper.cs, rather than split between this code and
the UI.
- Both the UI (via model validate bindings) and backend registry writes
now strictly evaluate against the same unified ruleset before applying
changes or enabling/disabling controls.
- Existing methods have been updated to report back their success or
failure, to enable errors to be tracked more effectively.

### Blocked OS-breaking characters
- In response to the user report, the equals character is now blocked
from both Variable and Profile names. `=` being disallowed is
[explicitly
mentioned](https://learn.microsoft.com/en-us/windows/win32/procthread/environment-variables)
in the Environment Variables Win32 documentation, so it's a surprise it
wasn't caught previously.
- All control characters (including `\0`, `\r` and `\n`) are also
disallowed, both to protect the integrity of the environment block and
the rendering of the strings in the UI.
- Leading and trailing whitespace is rejected to prevent orphaned
variables.

### Enforced Windows length constraints
- Variable Names and Profile Names are restricted to 259 characters, to
match the 260-character null-terminated string length limit in the
Windows Environment Variables Editor (via sysdm.cpl) and RegEdit. To be
clear: profile names may technically be longer, but we should choose to
abide by this authoring tool limit to maintain compatibility with other
editors. There was previously a 255-character limit on names in the
code, and a comment indicating this was a registry limit, but that was
incorrect and has been removed. The new limit constant is
`MaxEnvironmentVariableNameAuthoringLength`.
- In the prior code, there was no limit on the length of system variable
names. This was incorrect. The limit for both System and User name
fields is now the identical at 259 characters.
- There is a length limit on the full environment variable entry
`[VariableName]=[VariableValue]\0`, which is 32766 characters plus the
null-terminator. This is now enforced and the constant is
`MaxTotalEnvironmentVariableLength`. (There's no imposed limit on the
number of environment variables.)

### Fixed User Profile backup "overflows"
- Fixed a bug where a user could create a valid Profile Name and a valid
environment variable name, but applying them would silently fail to
apply the profile because the generated backup variable name
`[VariableName]_PowerToys_[ProfileName]` exceeded the previous authoring
limit of 255 characters.
- Backup variables are excluded from the 259-character limit, as they
are internal to the application, but the combined
`[VariableName]=[VariableVavlue]\0` length is still strictly constrained
to the 32767 environment variable length limit.

There are now separate paths through the code to deal with backup
variable persistence and validation.

### UI
- If an applied user profile's name is now rejected because of the new
rules (e.g. it contains `=`), the UI now shows a specific "Profile name
is invalid" warning rather than the generic "not applicable" message
from before, allowing the user to identify and fix the problem.
- Fixed a small issue in the Add New Variable dialog where a vertical
scrollbar was always present. There are other cases where this occurs,
too, but I've left them for a future PR.

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

New unit tests project added with coverage of the new validation
functionality.

Also, manual testing...

Manual validation of each dialog:
- Add variable
- Edit variable
- Add variable via Profile Edit dialog

Test against:
- `=` being in either the Variable Name or the Profile Name
- A control character being present in the Variable Name or Profile Name
- Either the Variable Name or Profile Name containing one or more
trailing or leading whitespace characters
- The length of the Variable Name being longer than 259 characters
- The combined length of name + `=` + value being longer than 32766
characters

The dialog tests can be confirmed by checking to see if the Save button
is enabled:

<img width="1099" height="843" alt="image"
src="https://github.com/user-attachments/assets/685e561a-bd8d-4926-b9b2-a61dea4cc96a"
/>

Also confirm:
- An invalid Profile Name is caught. This can be confirmed by:

Editing the JSON file and adding an `=` character in the name:
<img width="497" height="197" alt="image"
src="https://github.com/user-attachments/assets/c6aa5d62-0672-499a-aac4-c639e8158b61"
/>

Then opening the application and trying to enable the profile:

<img width="1117" height="371" alt="image"
src="https://github.com/user-attachments/assets/bd887a44-5e65-4750-9c6f-9bf1b82a5ad6"
/>

Also confirm that in the Edit profile dialog, you can enable the
profile, but the Save button is disabled:

<img width="688" height="603" alt="image"
src="https://github.com/user-attachments/assets/10d186d9-17a0-4210-93e3-23b1e2723f5f"
/>

- Confirm that control characters cannot be part of the Variable Name:

First, run this from PowerShell, which adds a string containing the
newline character to the clipboard:

```pwsh
Set-Clipboard -Value "MyVar`nName"
```

Open the Add or Edit variable dialog and paste the value into the Name
field. Confirm that the character is not pasted and the string truncates
before it:

<img width="1424" height="732" alt="image"
src="https://github.com/user-attachments/assets/260ff728-57a2-438f-bb66-08d32a327b64"
/>

(For the null character specifically, use `Set-Clipboard -Value ("MyVar"
+ [char]0 + "Name")`.)

- The initial dialog button state. Re-open the Add New variable dialog
multiple times and confirm the Save button is disabled each time before
making any input.

- In the Add/Edit Variable dialogs, enter a valid variable name and then
clear it, confirming that the Save button enables and disables
correctly.

## Still outstanding

There are some flaws I've found which I'm choosing to leave for now,
mainly for expedience so the above issues can be prioritised:
- Handling duplicate profile names - there is the potential there for
duplicate variable names under identically-named profiles to conflict.
- Profile JSON import is still not sanitised.

These should be added in a future PR.
2026-08-05 16:42:25 +08:00
Gavin 北稱
1703e7ac09 [Build] Fix UTF-8 and output paths for local C++ builds (#49575)
## Summary of the Pull Request

Fixes two local C++ build reliability problems:

- Compiles all PowerToys C++ projects as UTF-8 through
`Cpp.Build.props`, so builds do not depend on the active Windows code
page. On code page 936, UTF-8 punctuation in BOM-less source files
otherwise triggers C4819 and fails the build because warnings are
treated as errors.
- Uses `$(RepoRoot)` for Keyboard Manager repository paths and
standardizes native/test output directories. This makes direct project
builds find the resource conversion script and headers, places the
Editor wrapper beside the WinUI app, and keeps the Engine test DLL under
the repository test output directory.

No runtime logic, end-user strings, dependencies, or binaries are added.

## PR Checklist

- [x] Closes: #49573
- [x] Closes: #49574
- [x] **Communication:** Discussed the shared UTF-8 policy with a
PowerToys collaborator in this PR
- [x] **Tests:** Existing Keyboard Manager Engine tests pass; no new
tests are needed for project-only changes
- [x] **Localization:** No end-user-facing strings are changed
- [x] **Dev docs:** No documentation changes are required for project
configuration fixes
- [x] **New binaries:** No new binaries are added
- [x] **Documentation updated:** No user documentation changes are
required

## Detailed Description of the Pull Request / Additional comments

`Directory.Build.props` imports `Cpp.Build.props` for C++ projects.
Defining `/utf-8 %(AdditionalOptions)` in its shared `ClCompile`
settings makes source decoding deterministic across the native codebase
and prevents future BOM-less UTF-8 source files from reintroducing the
same locale-dependent failure. `/utf-8` explicitly sets both the source
and execution character sets instead of suppressing C4819 or replacing
valid Unicode text.

`$(SolutionDir)` is only reliable when MSBuild is invoked through a
solution. The repository's local build script builds `.vcxproj` files
directly from their project directories, where `$(RepoRoot)` is the
stable repository root property. The wrapper output now follows the
existing `$(RepoRoot)$(Platform)\$(Configuration)\WinUI3Apps\` pattern
used by other native WinUI dependencies.

## Validation Steps Performed

All successful builds used the repository build scripts with `-Platform
x64 -Configuration Debug`.

- Ran `tools/build/build-essentials.cmd`: solution restore, Runner, and
Settings all succeeded with empty errors logs.
- Built `FancyZonesLib` successfully after it had failed with a
resource-related CL exit during a full parallel build.
- Built `WorkspacesModuleInterface` successfully, validating that
existing UTF-16 BOM headers remain compatible with the shared option.
- Built `ZoomItBreak` and `ZoomIt` successfully.
- Built `KeyboardManagerEngineTest` successfully.
- Built `KeyboardManagerEditor` and `KeyboardManagerEditorUI`
successfully after the documented essentials prerequisite.
- Confirmed the successful native build logs contain `/utf-8` compiler
invocations and all corresponding `build.debug.x64.errors.log` files are
empty.
- Ran `vstest.console.exe` against the Keyboard Manager Engine test
assembly: 103/103 passed.
- Confirmed `PowerToys.KeyboardManagerEditorLibraryWrapper.dll` is
emitted to `x64/Debug/WinUI3Apps`.
- Confirmed `KeyboardManager.Engine.UnitTests.dll` is emitted to
`x64/Debug/tests/KeyboardManagerEngine`.
- Previously manually verified the x64 Debug PowerToys build can open
Keyboard Manager Editor without 0x8007007E.

A full `PowerToys.slnx` x64 Debug build was attempted twice. The first
attempt exhausted the remaining 62 MB of disk space. After clearing
52.46 GB of ignored build outputs, the second attempt still exceeded the
machine's temporary disk/commit limits (`CL.exe` exit `0xC000012D` and
an out-of-space cppwinrt write). Before that resource failure, the log
contained 4,642 `/utf-8` command entries and no character-set
diagnostics. The full configuration matrix is left to PR CI rather than
bypassing normal build settings locally.

---------

Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
2026-08-05 08:10:36 +00:00
Niels Laute
6bb16d014b [Settings][Image Resizer] Edit/add presets in a ContentDialog instead of a Flyout (#49161)
## Summary of the Pull Request

Replaces the inline preset-edit **Flyout** on the Image Resizer settings
page with a **ContentDialog**, matching the add/edit pattern already
used on the **Color Picker** page. This aligns the experience with the
Windows 11 / Fluent paradigm and fixes preset settings being saved on
every intermediate change.

Editing now happens on a **working copy** of the preset
(`ImageSize.Clone()`), which is committed only when the user presses
**Save/Update**. As a side effect, the intermediate width/height spinner
changes no longer persist `settings.json` / `sizes.json` on every value
change — resolving #36938.

The per-row **delete** action moves from an inline trash button into a
**"..." (More options)** `MenuFlyout`, again matching the Color Picker
page.

Historically this editing was a Flyout rather than a ContentDialog due
to known `ContentDialog` / `XamlRoot` issues back when Settings was a
UWP app. Now that Settings is on WinUI 3 / Windows App SDK,
`ContentDialog` works reliably (as Color Picker's `ColorFormatDialog`
demonstrates), so the original constraint no longer applies.



https://github.com/user-attachments/assets/bf71b0a9-c3f8-4078-95c7-c7ee9dc7b24b



## PR Checklist

- [x] Closes: #49157
- [x] Closes: #36938
- [ ] **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
(added to `Resources.resw`; reused existing keys for the delete menu)
- [ ] **Dev docs:** Added/updated
- [x] **New binaries:** None added

## Detailed Description of the Pull Request / Additional comments

- **Dialog:** Clicking a preset card (or **Add new size**) opens an
`EditSizeDialog` `ContentDialog`. Fields are bound with compiled
`{x:Bind}` against a working-copy `EditingSize`. The dimensions field
header is dynamic — **"Width"** when height is used, **"Size"** for
aspect-ratio-preserving percentage scaling — so the label isn't
misleading. The dialog is widened for a less cramped layout.
- **Save semantics:**
  - `ImageSize.Clone()` — builds the editable working copy.
- `ImageResizerViewModel.CreateNewImageSizeModel()` — builds a
default-valued model for the add dialog without adding it to `Sizes`.
- `ImageResizerViewModel.AddImageSize(ImageSize)` — commits a new preset
with the next unique ID.
- `ImageResizerViewModel.UpdateImageSize(original, updated)` — applies
edited values back onto the original, temporarily detaching the per-item
`PropertyChanged` save handler so it persists **once** instead of on
every property. This is what fixes the "saved too often" behavior in
#36938.
- **Delete:** per-row `Button` → `MenuFlyout` with a Delete
`MenuFlyoutItem`; the `ImageSize` is passed via
`CommandParameter="{x:Bind}"` (robust inside a flyout popup) and the
Yes/No confirmation dialog is preserved.

## Validation Steps Performed

- Built `PowerToys.Settings` (x64/Debug) — clean (exit 0).
- Ran the runner from this build and manually validated in Settings →
Image Resizer:
- **Add new size** opens the dialog pre-filled; Save adds the preset;
Cancel discards.
- **Editing** a preset in the dialog and pressing Cancel leaves the
original untouched (working-copy clone).
- Selecting **Percent** shows the **Size** header (not a misleading
"Width").
- Spinning width/height inside the dialog no longer writes settings
files on each change; a single save occurs on Update (#36938).
- The **"..."** menu shows **Delete**, with the confirmation dialog
intact.

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
2026-08-05 15:02:52 +08:00
Mike Griese
d04ebff5e7 CmdPal: Use RepoRoot instead of SolutionDir (#49643)
As it turns out, the robots are unbelievably stupid. When they build our
projects to verify their changes, they will often just build the .csproj
that they changed rather than building it in the context of the
solution. On the surface, this feels like a good idea. Only build the
thing that changed.

However, because they're not building it in the context of a solution,
the MSBuild variable `$(SolutionDir)` doesn't get expanded to the actual
directory of the solution. Instead, it just gets treated as the *path to
the project*. This creates terrible recursive loops where the output of
a project gets dumped relative to the project itself, and then that gets
taken as input to the project's package outputs, and eventually you're
gonna end up with a max path overrun.

The very easy solution here is to just replace `$(SolutionDir)` with
`$(RepoRoot)`.

If we use that variable, then the dumb robots will still get the correct
value for that variable when they build just a project. And for all the
actual humans, everything will work exactly as it did before.
2026-08-04 09:17:30 -05:00
moooyo
10236ee8c7 [Quick Accent] Fix the accent bar's blank first frame and its under-measured width (#49633)
## Summary of the Pull Request

Two defects in the WinUI 3 Quick Accent selector. They look unrelated
but share a root: the overlay owns no layout of its own, so `MainWindow`
sizes and shows it by hand — and both halves of that hand-rolled logic
rest on an assumption that does not hold.

* **#49489** — the bar appears blank, too wide and clipped on the right
for a few frames, then snaps into place. A hidden WinUI 3 window renders
nothing, so `ShowWindow(SW_SHOWNA)` puts the HWND on screen before the
freshly rebuilt accent list has ever been laid out.
* **#49488** — the window is sized narrower than its own content
whenever a glyph is wider than the 48 DIP cell, so the list silently
scrolls inside it and the trailing accents are pushed against the right
edge.

test result:




https://github.com/user-attachments/assets/80d57aa8-5030-46c3-9ec8-6ed05ed00f03



## PR Checklist

- [x] Closes: #49489
- [x] Closes: #49488
- [x] **Communication:** bug fixes for two open, triaged issues in an
existing module; no new feature surface
- [x] **Tests:** added — 11 cases in `PowerAccent.Core.UnitTests`
covering the new `Calculation.GetToolbarWidth`; the existing
positioning/DPI suites are unaffected
- [x] **Localization:** no new end-user-facing strings
- [ ] **Dev docs:** N/A — the *Toolbar Sizing and Reveal* section was
dropped from this PR; the reasoning lives in the code comments and in
the commit messages instead
- [x] **New binaries:** none — no new projects or outputs, so no
`ESRPSigning_core.json`, `Product.wxs`, CI or release YML changes are
needed
- [ ] **Documentation updated:** N/A — internal rendering/layout fix
with no user-facing behavior change beyond the bugs going away

## Detailed Description of the Pull Request / Additional comments

### #49489 — the blank, over-wide, clipped first frame

The window is never actually repositioned or resized. Measuring the two
frames in the issue shows the same HWND rect in both: identical left
edge, and the bad frame's hard right cut sits exactly where the good
frame's rounded corner plus its 24 DIP margin ends. What changes is the
**content** — it is composed once from a stale layout, then re-laid-out.

Two ordering problems produced that stale composition:

1. `TransientSurface` is `Collapsed` while hidden and is only flipped to
`Visible` from the `Showing` event, which `TransparentWindow.RaiseShow`
raises **after** `ShowWindow(SW_SHOWNA)`. The accent bar's subtree
therefore provably has not been measured or arranged at the moment the
HWND becomes visible.
2. The hide path called `ViewModel.Characters.Clear()` synchronously
right after `Hide()` — but `Hide()` only *queues* the dismissal, so the
still-visible window rendered an empty bar at the old width. That empty
card is exactly what the next summon put back on screen.

The fix mirrors what the WPF implementation did for the same symptom in
#46593 (render off screen, then `SetWindowPos` into view), adapted to
WinUI 3 where a hidden window does not render at all:

* Show the bar with `Selector.Opacity = 0`, lay it out, and unveil it
once `CompositionTarget.Rendering` confirms a couple of frames have
elapsed. `Opacity = 0` still renders (unlike `Visibility.Collapsed`),
which is exactly what is needed here. A 150 ms timeout backs it up — not
because frames stop arriving (attaching a `Rendering` handler forces the
UI thread to run every frame) but because the tick cadence carries no
guarantee and can stop for a locked or fully occluded session; on that
path the bar simply appears the way it used to, so it can never get
stuck invisible.
* Size the bar **twice** per summon: once before `Show`, and again after
the first real layout pass. The first measurement runs while the surface
is still `Collapsed` and, on the first summon of the process, before its
template has ever been applied, so it can report less than the items
need. The correction happens while the bar is still transparent, so it
is never seen as a resize.
* Leave the characters in the list on hide. The next summon clears and
refills them anyway, and not clearing them removes the blank-bar frame
at the source.
* A generation counter drops a pending reveal when the summon is
dismissed or superseded before its frame lands, and arming a new summon
detaches the previous one's per-frame handler so it cannot unveil the
new bar ahead of its own layout pass.

### #49488 — width derived from the item count instead of measured

`MainWindow` computed the window width as `Characters.Count * 48`, while
the XAML cell is `MinWidth="48"` — a *minimum*, not a fixed width.
`ListViewItem` → `Grid MinWidth=48` with a `ContentPresenter Margin=12`,
so a cell is `max(48, glyphWidth + 24)`: any glyph wider than 24 DIP (₹,
‰, ﷼, ៛, CJK fallbacks) grows its cell. With **All languages** selected,
R and P each carry ~20 characters and the accumulated error is enough
for the real content to overflow the window. The ListView's
`ScrollViewer` (`HorizontalScrollMode="Enabled"`,
`HorizontalScrollBarVisibility="Hidden"`) then absorbs the overflow
invisibly, and `ScrollIntoView` starts scrolling a bar that should not
scroll at all.

The pre-migration WPF window used `SizeToContent="WidthAndHeight"` and
only set `MaxWidth`, so the layout system measured the same item
template and the window simply grew — which is why this never showed up
before. `AppWindow` has no `SizeToContent` equivalent, and the migration
replaced it with a constant model.

Now:

* `SelectorControl.MeasureContentWidthDip()` measures the list against
an unbounded width and returns what the items actually need. Measuring
explicitly, rather than reading a stale `DesiredSize`, addresses the
concern recorded in the original comment: the bar is rebuilt on every
summon while the window is still hidden, so no layout pass has run for
the new items yet.
* `Calculation.GetToolbarWidth()` — a pure function, hence the unit
tests — floors that measurement at `itemCount * minItemWidth` (every
cell is at least the minimum, so a list that could not be measured
reports 0 and safely falls back to the old estimate instead of
collapsing the bar), applies the description row's minimum width, and
clamps to the display's usable width so long character sets still scroll
on purpose.
* The clamp's lower bound is `minItemWidth + chromeWidth` — one cell
plus the space around it, the narrowest bar that can still draw a glyph
— and its upper bound is `Math.Max(minItemWidth + chromeWidth,
maxWidth)`, because a display narrower than that floor would otherwise
invert the bounds and make `Math.Clamp` throw.

`DescriptionMinWidthDip = 648` masked this bug whenever the Unicode
description row was on and the character set short, which is likely why
#49402 (description-row width) did not surface it.

## Validation Steps Performed

* `PowerAccent.Core`, `PowerAccent.UI` and `PowerAccent.Core.UnitTests`
build clean (Debug|x64).
* `PowerAccent.Core.UnitTests`: 32/32 pass, including the 11
`GetToolbarWidth` cases — narrow glyphs hug the item count, wide glyphs
win over the count estimate (the #49488 regression guard), the
measurement winning by a single DIP, a partly realized list keeping the
item-count floor, an unmeasured list falling back to the estimate,
over-long content clamping to the display maximum, the description row
widening a short bar but not a long one, the description minimum losing
to a narrower display, and both ends of the clamp. The lower clamp bound
was verified by mutation: rewriting it to `Math.Clamp(width, 0, ...)`
fails only `GetToolbarWidth_EmptyList_FallsBackToOneCellPlusChrome`.

---------

Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 14:08:23 +08:00
A. G. Soto
e542b82a2a [PowerAccent] Forward key-up after false activation (#49644)
## Summary of the Pull Request

Quick Accent passes the owner letter's key-down to the rest of the
low-level keyboard hook chain. When activation is canceled before the
configured threshold, trigger-key modes currently swallow the matching
key-up. This leaves downstream keyboard state reporting the letter as
held and causes Keyboard Manager's shortcut-to-shortcut safety check to
reject later remaps.

This change forwards the owner letter's key-up on that false-start path,
balancing the event pair for downstream hooks and applications.
Successful Quick Accent activation behavior is unchanged.

Partial fix: #38089

## PR Checklist

- [ ] Closes 
- [ ] **Communication:** Root cause, deterministic reproduction, and
validation were posted on #38089; awaiting core-contributor review
- [ ] **Tests:** No automated low-level keyboard-hook test seam is
available; extensive manual validation is documented below
- [x] **Localization:** No end-user-facing strings changed
- [x] **Dev docs:** No developer documentation changes are required for
this targeted bug fix
- [x] **New binaries:** No new binaries were added
- [ ] **Documentation updated:** No user-facing documentation change is
required

## Detailed Description of the Pull Request / Additional comments

The false-start path runs when the owner letter is released before Quick
Accent's activation threshold. Its key-down was already allowed through
by `OnKeyDown`, but `OnKeyUp` returned `true` for the Space/arrow
activation modes. Returning `true` from the low-level hook prevents
later hooks and the target application from receiving the release.

Keyboard Manager intentionally checks that no unrelated key is held
before applying a shortcut-to-shortcut remap. The missing release
therefore makes several remaps stop together while both PowerToys
processes remain responsive. It also explains why locking and unlocking
the Windows session restores them: the stale keyboard state is reset.

The fix is intentionally in Quick Accent rather than relaxing Keyboard
Manager's safety check, which must continue to reject remaps when
unrelated keys are genuinely held.

Full captured evidence and source analysis:
https://github.com/microsoft/PowerToys/issues/38089#issuecomment-5171089872

## Validation Steps Performed

- Built `PowerAccentKeyboardService` from current `main` in Release x64:
0 warnings, 0 errors. Spectre mitigation was disabled for the local
build because the corresponding Visual Studio libraries were not
installed.
- Built and installed the same change against PowerToys 0.100.2 so the
test DLL matched the installed release ABI.
- Repeated dozens of false activations with E/N/O/Y by pressing Space
and releasing the owner letter before the 500 ms threshold.
- Interleaved successful Quick Accent selections to verify normal
activation still worked.
- Captured `GetAsyncKeyState` transitions and confirmed both the letter
and Space changed from down to up; all sampled keys remained up after
testing.
- Continuously tested a Left Shift+O -> Left Alt+Tab Keyboard Manager
remap; it remained functional throughout.
- Completed an additional user soak test without recurrence;
locking/unlocking was no longer required.
2026-08-04 03:36:11 +00:00
Michael Jolley
e141d172c8 Modify PR branch filters in CI configuration (#49646)
Commented out branch filters for PRs to allow CI on stacked PRs.
2026-08-03 17:41:04 -05:00
Mike Griese
e5c63b2ea4 Dock: Remove our last 1px gap once and for all (#49641)
I guess if you set ExtendsContentIntoTitleBar, well, WinUI will offset
your island by x,y=0,1. That's what happens if you don't actually set
any titlebar content.

*
https://github.com/microsoft/microsoft-ui-xaml/blob/main/dxaml/xcp/components/WindowChrome/CWindowChrome.cpp#L202
*
https://github.com/microsoft/microsoft-ui-xaml/blob/main/dxaml/xcp/components/WindowChrome/CWindowChrome.cpp#L171
*
https://github.com/microsoft/microsoft-ui-xaml/blob/main/dxaml/xcp/components/WindowChrome/inc/CWindowChrome.h#L23

cause like, of course it does.

I'm sure there are previous threads to xlink this too
2026-08-03 12:42:26 -05:00