mirror of
https://github.com/microsoft/PowerToys.git
synced 2026-08-29 10:09:43 +02:00
ab1f521067b5c6808d4ad437566bebfab47f353e
9567 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
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
|
||
|
|
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 |
||
|
|
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> |
||
|
|
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 |
||
|
|
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 |
||
|
|
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 |
||
|
|
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 |
||
|
|
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> |
||
|
|
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 |
||
|
|
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 |
||
|
|
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> |
||
|
|
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 |
||
|
|
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? |
||
|
|
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> |
||
|
|
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 |
||
|
|
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 |
||
|
|
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. |
||
|
|
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. |
||
|
|
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 |
||
|
|
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 |
||
|
|
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). |
||
|
|
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 |
||
|
|
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 |
||
|
|
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> |
||
|
|
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 |
||
|
|
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](
|
||
|
|
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 |
||
|
|
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 |
||
|
|
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 |
||
|
|
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 & 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 |
||
|
|
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> |
||
|
|
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 |
||
|
|
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.  ### 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.  ### 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.  --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: ad8b7909-0472-4464-bdee-deaeca726f94 Copilot-Session: 8e04a72e-3b0f-4ac4-8156-d04ea9b8bb85 |
||
|
|
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> |
||
|
|
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 |
||
|
|
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 |
||
|
|
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 ```` |
||
|
|
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 |
||
|
|
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 |
||
|
|
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  ### Settings page  ## 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 |
||
|
|
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> |
||
|
|
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> |
||
|
|
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. |
||
|
|
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> |
||
|
|
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> |
||
|
|
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. |
||
|
|
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> |
||
|
|
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. |
||
|
|
e141d172c8 |
Modify PR branch filters in CI configuration (#49646)
Commented out branch filters for PRs to allow CI on stacked PRs. |
||
|
|
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 |