mirror of
https://github.com/microsoft/PowerToys.git
synced 2026-08-29 10:09:43 +02:00
8516625c4da62ad4e90f3ec021fade5084cd1dc6
9579 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Michael Jolley
|
888a142724 |
[CmdPal] Consolidate search ranking changes (#49832)
## What's going on The stacked pull requests are blocked by GitHub's stack merge flow. This gives the full remaining search ranking change set one PR against `main`. ## The plan - Consolidates the open work from #49190, #49191, #49194, #49195, #49197, #49246, #49247, and #49249. - Keeps the existing stack unchanged while this PR provides an alternate merge path. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5459b847-afeb-4163-a803-977759dd92df Copilot-Session: 49185697-186e-406f-b081-8c985c134274 Copilot-Session: 92905c83-2de6-449c-b4a1-a08003fe2576 Copilot-Session: efe987e5-9297-47fc-af99-2f49b057285a Copilot-Session: f42917e2-d298-4bde-9056-79a9e6e17dfa |
||
|
moooyo
|
9e1c39def7 |
ci: pin .NET 10 SDK to runtime package version (#49835)
## Summary of the Pull Request Pins the .NET 10 SDK used by CI to `10.0.302`, whose `10.0.10` runtime matches the .NET servicing packages declared in `Directory.Packages.props`. This prevents dependency-audit failures caused by the floating `10.0` SDK channel advancing independently of the repository's package versions. ## PR Checklist - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** N/A for this pipeline-only configuration change; validation is documented below ## Detailed Description of the Pull Request / Additional comments The CI template previously passed `10.0` to `dotnet-install.ps1 -Channel`. After .NET 10.0.11 became the latest release, CI combined SDK-provided 10.0.11 runtime assets with NuGet runtime assets pinned to 10.0.10. `.pipelines/verifyDepsJsonLibraryVersions.ps1` consequently detected different `System.Private.Windows.GdiPlus.dll` file versions across generated `.deps.json` files. This PR: - Adds the optional `exactVersion` parameter to `.pipelines/v2/templates/steps-ensure-dotnet-version.yml`. Existing callers continue using channel-based installation when the parameter is omitted. - Sets `exactVersion` to `10.0.302` in `.pipelines/v2/templates/job-build-project.yml`; that SDK contains the 10.0.10 runtime. - Defines `DotNetRuntimePackageVersion` once in `Directory.Packages.props` and references it from all 23 .NET servicing packages. - Adds cross-referenced comments so future SDK and runtime package servicing updates remain aligned. ## Validation Steps Performed - Confirmed the centralization assertion failed before the change with 23 literal `10.0.10` package versions and passed afterward with 23 `$(DotNetRuntimePackageVersion)` references and no remaining literals. - Restored `PowerToys.slnx` successfully using `tools/build/build.ps1 -RestoreOnly`. - Ran `dotnet-install.ps1 -Version 10.0.302 -DryRun` and confirmed that it resolves the exact `10.0.302` SDK payload. - Parsed `Directory.Packages.props` successfully as XML. - Ran `git diff --check` successfully. - Azure Pipelines validation remains pending while this PR is in Draft. --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Christian Gaarden Gaardmark
|
b605fd35c5 |
New+ Rename and Desktop icon positioning improvements (#48083)
New+ Rename and Desktop icon positioning improvements. Manually tested on Windows 11. Windows 10 updates have NOT been tested. ## Summary of the Pull Request * Obtain cursor position early in the lifecycle of the context menu * Busy wait until copy is complete and shell is aware of icon * If context menu is on desktop, reposition the icon using the cursor position obtained scaled using monitor appropriate DPI * Slight refactor to help port code from New++ to New+ ## PR Checklist - [x] Closes: #36440 - [ ] **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 - [n/a] **Localization:** All end-user-facing strings can be localized - [n/a] **Dev docs:** Added/updated - [n/a] **New binaries:** Added on the required places - [n/a] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [n/a] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [n/a] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [n/a] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [n/a] **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 * n/a ## Validation Steps Performed **Windows 11** * x64: Manually tested * ARM64: Not tested **Windows 10** * Not tested --------- Co-authored-by: Boliang Zhang (from Dev Box) <bozhang@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 41b6b39b-b620-4e02-b7ca-8ae470a9c1e2 |
||
|
moooyo
|
c4431304c4 |
[Quick Accent] Fix missing last-item selection highlight (#49820)
## Summary of the Pull Request Fixes a pre-existing Quick Accent rendering edge case where the last character is selected and inserted correctly, but its selection highlight is missing when a long character list is scrolled to the end. The horizontal items panel now leaves a symmetric 1-DIP margin outside its edge containers. This keeps `ScrollIntoView` from landing exactly at the maximum scroll offset, where WinUI can clip the last item's selected visual. The symmetric margin preserves short-list centering and works in both flow directions. The behavior was reproduced on both the #49633 baseline and #49655, so it was not introduced by #49655. ## PR Checklist - [ ] Closes: N/A — discovered while validating #49655; no matching issue is currently filed - [ ] **Communication:** Draft PR for maintainer discussion - [x] **Tests:** Existing tests pass; the XAML compositor edge was also covered by a deterministic GUI regression run - [x] **Localization:** N/A — no end-user-facing strings changed - [x] **Dev docs:** N/A — no developer-facing behavior or contract changed - [x] **New binaries:** N/A — no binaries or dependencies added - [x] **Documentation updated:** N/A — no documentation impact ## Detailed Description of the Pull Request / Additional comments With the overflowing horizontal list at its maximum offset, the last `ListViewItem` remains realized, selected, and visible, and its `SelectionIndicator` has opacity 1. However, WinUI does not paint that selected visual. Adding one DIP of scroll extent after the edge container avoids that boundary condition without changing selection or keyboard-navigation logic. The panel margin is symmetric so non-overflowing lists remain centered and RTL layouts receive the same protection at either edge. Infinite-width measurement already includes the margin, so the existing window sizing path needs no special case. ## Validation Steps Performed - Built `PowerAccent.UI` with `Debug|x64` using `tools/build/build.ps1`. - Built `PowerAccent.Common.UnitTests` and `PowerAccent.Core.UnitTests` with `Debug|x64`. - Ran both suites with `vstest.console.exe`: **55/55 passed**. - Reproduced the original failure by holding `A`, pressing `Space`, then `Shift+Space` before reveal: the selected `ₐ` was inserted but the baseline showed no selection-highlight pixels. - Repeated the same first-frame scenario **20 times** after the fix: all first and stable frames rendered the highlight (4441 detected accent pixels), with the foreground window preserved. - Repeated insertion validation in a dedicated text host **5 times**: all runs inserted `U+2090` (`ₐ`), rendered the highlight, and preserved foreground focus. - Ran `git diff --check` successfully. Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> |
||
|
Clint Rutkas
|
dbff0e798d |
[Mouse Highlighter] Keep ripple work off the low-level hook (#49699)
<!-- 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 Mouse Highlighter performed synchronous WinRT Composition work in its `WH_MOUSE_LL` callback. Slow low-level hook callbacks stall the shared mouse-hook chain and can be silently removed by Windows, causing a button-up event to be lost and leaving the ripple or pressed state stuck. FancyZones was inspected to confirm ownership but is not changed by this PR. This moves Mouse Highlighter's visual, animation, timer, and Z-order work onto its module window thread. The hook now records events in a bounded, allocation-free FIFO and posts a window message. Adjacent high-rate mouse moves are coalesced, while button ordering, hook timestamps, and signed screen coordinates (including negative multi-monitor coordinates) are preserved. Stop, settings changes, and teardown clear pending events, pressed state, hold state, and timers. Settings application is also marshaled to the window thread so WinRT Composition remains thread-affine. <!-- 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 low-level hook now does only constant-time event capture and queue signaling. A fixed-capacity FIFO preserves the sequence of button transitions and mouse positions without allocating in the hook. Only adjacent move events are coalesced, avoiding message flooding without moving a cursor update across a button boundary. Input timestamps keep quick-click versus hold classification based on the original 180 ms threshold even if window-thread processing is delayed. All Composition access runs through the Mouse Highlighter window/message queue. Lifecycle paths unhook before clearing the queue and reset button, ripple-hold, spotlight, and timer state. If the bounded queue ever fills, recovery resets transient visual state before retaining the triggering button event rather than risking a dropped button-up. <!-- 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/MouseUtils/MouseHighlighter/MouseHighlighter.vcxproj` in Debug x64. - Built `src/modules/FancyZones/FancyZonesLib/FancyZonesLib.vcxproj` in Debug x64 to verify the unchanged hook-chain neighbor. - Ran `git diff --check`. - Performed a focused concurrency and event-ordering code review. No focused native unit-test seam exists for this hook/Composition path without disproportionate refactoring, so no automated test was added. No end-to-end rapid-click/drag stress run across mixed-DPI multi-monitor layouts was performed. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Muyuan Li <116717757+MuyuanMS@users.noreply.github.com> Copilot-Session: 6caaf738-168e-4b11-8efb-b155139dac31 Copilot-Session: 259addc8-304d-4595-83c8-bba3d76e0637 |
||
|
Makoto Sakaguchi
|
a60c104d71 |
FileLocksmith: Fix context menu items are not localized (#49606)
<!-- 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 Fixing the issue where Windows 11 context menu items are not localized. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #37271 (Localized part ONLY) <!-- - [ ] 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 - [x] **Localization:** All end-user-facing strings can be localized - [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 <!-- 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 Reorganize resource items for the `FileLocksmithContextMenu` project - Mark `resource.base.h` as a non-compiled `None` - Add `Generated Files/resource.h` as a `ClInclude` - Mark `FileLocksmithContextMenu.base.rc`as a non-compiled `None` - Add `Generated Files/FileLocksmithContextMenu.rc` as a `ResourceCompile` Update the `.vcxproj.filters` accordingly to reflect the new locations and filters for header and resource files. <img width="1920" height="1020" alt="before" src="https://github.com/user-attachments/assets/db8732e5-408c-4ab9-8c42-2f4d3d31e00a" /> Before <img width="1920" height="1020" alt="after" src="https://github.com/user-attachments/assets/87d82eaa-4daf-4339-92c5-40bbe45f7170" /> After <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
moooyo
|
fe4a86a54d |
[Quick Accent] Cloak the accent bar instead of hiding it (#49655)
## Summary of the Pull Request Follow-up to #49633: replace the way the accent bar's first frame is protected. #49633 fixed the blank/stale first frame (#49489) by masking it — `Selector.Opacity = 0`, unveil after two `CompositionTarget.Rendering` ticks, backed by a 150 ms watchdog. This PR removes the cause instead, using the technique the Command Palette and Quick Access already ship: **DWM-cloak the overlay instead of hiding it**, so it never stops rendering and there is no stale frame to put back on screen. No user-visible behaviour change is intended beyond removing the fixed two-render-tick reveal delay; this is a mechanism swap plus the cleanup it enables. ## PR Checklist - [x] **Closes:** N/A — #49489 was already closed by #49633; this replaces that fix's mechanism - [x] **Communication:** follow-up to a merged PR in the same module, no new feature surface - [x] **Tests:** `PowerAccent.Core.UnitTests` 32/32 still pass (the pure width logic from #49633 is untouched). The current-head CI status is tracked in the PR checks; the compositor-specific manual measurements below were captured before the final commit-fence follow-up and are labeled accordingly - [x] **Localization:** no new end-user-facing strings - [x] **Dev docs:** N/A - [x] **New binaries:** none - [x] **Documentation updated:** N/A ## Detailed Description of the Pull Request / Additional comments ### Why cloaking A hidden WinUI 3 window renders nothing. Its composition surface therefore still holds the frame it was showing when it was hidden, and `ShowWindow` puts that stale frame back on screen before the rebuilt accent list has been laid out — that is #49489. Everything downstream of that follows from "the window does not render while hidden": * the bar cannot be measured before it is shown (a `Collapsed` subtree is never measured), hence #49633's measure-twice workaround; * #49633 deferred reveal using rendering ticks because it did not have a composition-commit fence; * this PR calls `Microsoft.UI.Composition.Compositor.RequestCommitAsync()` after the bar has been laid out, sized, positioned and scrolled, and only reveals after that commit completes. This replaces the frame counter and watchdog with an explicit compositor fence. A cloaked window is equally invisible to the user but stays `SW_SHOWNA`-shown, so XAML keeps laying it out and painting it. This is exactly what `Microsoft.CmdPal.UI\MainWindow.xaml.cs` does, and its comment names the same symptom: ```csharp // TRICKY: show our HWND again. This will trick XAML into painting our // HWND again, so that we avoid the "flicker" caused by a WinUI3 app // window being first shown ``` `QuickAccess.UI\QuickAccessXAML\MainWindow.xaml.cs` uses the same pattern, including the "warm up the window while cloaked" prewarm that this PR also picks up — which is what removes the *first summon of the process* case that #49633's second measurement existed for. ### What the summon looks like now `Show()` still raises `Showing`, so the surface leaves `Collapsed` and the bar lays out — but the window is still cloaked, so nothing reaches the screen. The bar is then measured **once** (on a templated, laid-out, non-collapsed subtree), sized, positioned and scrolled to the selection. The compositor commit is then awaited, and only after it completes does `Reveal()` uncloak the window. The first visible frame is a finished bar by construction rather than by timing. Removed as a result: `RevealTimeoutMs`, `FramesBeforeReveal`, `_revealTimer`, `_revealGeneration`, `_renderedFrames`, `_measuredContentWidthDip`, `ArmRevealTimeout`, `CancelPendingReveal`, `WaitForFirstFrameThenReveal`, `OnRenderingBeforeReveal`, the local `Reveal`, and the `Selector.Opacity` dance — 87 net lines out of `MainWindow`. `_showGeneration` stays: a layout callback queued by a dismissed summon still has to be dropped. ### `TransparentWindow` The cloak lives in the shared window because `Hide()` owns the `AppWindow.Hide()` that has to be replaced. It is **opt-in** (`EnableCloakedHide()`), so Shortcut Guide's overlay and CmdPal's toast keep hiding exactly as they do today; only Quick Accent enables it. `Reveal()` is a no-op for them. Two details worth review attention: * **Hit-testing.** Cloaking takes a window out of composition but *not* out of hit-testing, and this HWND sits exactly where the user is typing. While cloaked the window is therefore made click-through (`WS_EX_TRANSPARENT`), restored on reveal. Without this, an invisible accent bar would swallow clicks meant for the app underneath. * **`SW_HIDE` then `SW_SHOWNA`.** Same order as CmdPal: the hide is what hands the foreground back to whatever window should own it, and the show that follows leaves the window "shown" — which is what keeps XAML painting — while the cloak keeps it off screen. If DWM refuses to cloak, the HWND remains hidden; a later `Show()` retries instead of exposing an un-laid-out frame. ### Relationship to #34849 / #41044 Always-on-top is still released on hide, so the dormant overlay is `WS_EX_TOPMOST=False` exactly as before — verified below. Cloaking is orthogonal to topmost. The one honest trade-off is that the HWND is now permanently `WS_VISIBLE` (cloaked), so it keeps participating in composition while dormant, the same as CmdPal and Quick Access already do; it stays out of Alt-Tab and the taskbar via a hidden owner plus `WS_EX_TOOLWINDOW`. ## Validation Steps Performed > The build/test/live-state results below were recorded at `e372cdf`. Current head `ea658bb` adds the explicit `RequestCommitAsync` fence after that validation. Current-head CI is tracked by the PR checks, and the live window-state/frame-capture checks should be repeated before merge. * `build-essentials`, `Common.UI.Controls`, `PowerAccent.UI` and `PowerAccent.Core.UnitTests` all build clean (Debug|x64), 0 warnings. * `PowerAccent.Core.UnitTests`: 32/32 pass. * Live window-state measurement against the built `PowerToys.PowerAccent.exe` (`DwmGetWindowAttribute(DWMWA_CLOAKED)` + `IsWindowVisible` + ex-styles), driving a real summon of the <kbd>R</kbd> bar with **All languages** selected: | phase | state | |---|---| | dormant (prewarmed, before any summon) | `visible=True cloaked=1 topmost=False clickThrough=True` | | summoned | `visible=True cloaked=0 topmost=True clickThrough=False` | | dismissed | `visible=True cloaked=1 topmost=False clickThrough=True` | i.e. the window is shown-and-painting the whole time, invisible and click-through while dormant, and topmost/interactive only while summoned. * Screen-captured the summoned bar: all 22 characters for <kbd>R</kbd> render (including the wide `₹ ៛ ﷼`), leading and trailing padding are symmetric, nothing is clipped and the selection is on the first cell. --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Gleb Khmyznikov
|
e48152c52d |
[UITests] Add UITest.Next suites (Image Resizer, Peek, File Explorer add‑ons, File Locksmith) + local‑VM tooling and CI test‑signing (#49671)
## Summary Adds end‑to‑end UI tests on the `Microsoft.PowerToys.UITest.Next` (winappcli) framework for three modules, grows the shared `.Next` test framework with the helpers those suites needed, and adds the CI plumbing that lets shell‑extension tests exercise the **real** Windows 11 modern context menu. Also ships two agent skills that document how to write and run these tests. Product runtime behavior is **unchanged** — the only product edits are test‑observability hooks in Peek and a unit‑test project exclude. Closes: https://github.com/microsoft/PowerToys/issues/40660 https://github.com/microsoft/PowerToys/issues/49424 https://github.com/microsoft/PowerToys/issues/40661 ## What's added ### New UI test suites - **Image Resizer** — `src/modules/imageresizer/tests/ImageResizer.UITests`: context‑menu enable/disable tracking, the resize dialog, custom presets, every fit mode, every unit, filename format, keep‑date, shrink‑only, replace‑in‑place, and orientation. - **Peek** — `src/modules/peek/Peek.UITests.Next`: file‑preview coverage across image/text/archive/ markdown types with per‑arch visual baselines. - **File Explorer add‑ons** — `src/modules/previewpane/PreviewPane.UITests`: Preview Pane handlers and thumbnail providers. ### `UITestAutomation.Next` framework - New helpers: `ExplorerShell` (Shell selection/view‑mode interop), `WaitHelper` (structured stable waits), `WindowControl` (foreground/context‑menu/process control), `VisualAssert` (image compare), `WindowHelper`. - Updates to `Session`, `UITestBase`, `SettingsConfigHelper`, `WinappCli`. - New `UITestAutomation.Next.UnitTests` project covering the new wait/settings/CLI helpers. ### CI — sign sparse MSIX so the modern menu registers - **`.pipelines/signSparsePackages.ps1`** — self‑signs each sparse context‑menu MSIX with a publisher‑matching test certificate and force‑trusts it (machine stores), so `AddPackageByUriAsync` succeeds on otherwise‑unsigned PR builds. Robust `signtool` discovery with a NuGet fallback; test‑only trust that asserts no security. - Wired into **`.pipelines/v2/templates/job-test-project.yml`** as a best‑effort step covering the run‑in‑place, machine‑install, and per‑user‑install locations. Signs nothing it can't (skips already‑signed packages) and never fails the job. ### Product changes (test observability only) - **Peek `FilePreview.xaml` / `.xaml.cs`** — a named `LoadingIndicator` and a hidden automation peer that exposes the current preview state as text, so tests can read load state deterministically. No runtime behavior change. - **`ImageResizer.UnitTests.csproj`** — exclude the sibling `ImageResizer.UITests\**` folder from the unit‑test compilation. ### Agent skills & docs - **New `ui-tests-local-vm` skill** — run `.Next` suites in persistent dockur/windows VMs: setup, agentic loop, image customization, troubleshooting, the shell‑extension **signing** reference, plus controller/guest scripts and VM templates. - **Updated `ui-tests-migration` skill** — WinAppDriver/Selenium → `.Next` porting guidance (CI stability, Explorer/shell‑extension test design, patterns & pitfalls). - **`doc/devdocs/development/ui-tests.md`** — updated for the `.Next` workflow. ## Testing - All three suites pass locally and in CI across **x64 Win10**, **x64 Win11**, and **arm64** (machine and per‑user install legs). ## Reviewer notes - No product runtime behavior changes; product edits are limited to the Peek test hooks above. - The CI signing step is a **test‑only** trust anchor (self‑signed, scoped to the agent) and is best‑effort, so it can only add modern‑menu coverage and never regress the job. |
||
|
Boliang Zhang
|
aac9fb9802 |
fix(settings-ui): restore General page navigation (#49801)
## Summary of the Pull Request Fixes Settings navigation to the General page by applying the correctly typed `SecondaryIsEnabledTextBlockStyle` to `GeneralPage_UpdateChannelDescription` in `src/settings-ui/Settings.UI/SettingsXAML/Views/GeneralPage.xaml`. The previous `SecondaryTextStyle` targets `TextBlock`, so WinUI threw a `XamlParseException` when applying it to the custom `IsEnabledTextBlock` control. This prevented `GeneralPage.InitializeComponent()` from completing. ## PR Checklist - [x] **Communication:** Regression identified while validating the v0.101 preview candidate - [x] **Tests:** Existing Settings tests pass and the runtime regression was verified - [x] **Localization:** No end-user-facing strings changed ## Detailed Description of the Pull Request / Additional comments PR #49722 introduced the incompatible style assignment. This change reuses the existing `SecondaryIsEnabledTextBlockStyle`, which targets `controls:IsEnabledTextBlock` and preserves the intended secondary foreground and 12px font size. The same regression is present on `stable`; this fix should be included in the v0.101 release branch after merge. ## Validation Steps Performed - Built `src/settings-ui/PowerToys.Settings.slnf` in Release x64. - Ran `Settings.UI.UnitTests.dll`: 185 passed, 0 failed, 0 skipped. - Launched the fixed Release Settings binary directly on `Overview`; the General header and Update channel controls rendered. - Confirmed no new `NavigationService` or `XamlParseException` log entries and no relevant Event Viewer crash. Copilot-Session: e9f79ac2-9a7b-4083-834c-0d87e8c83bfd |
||
|
Bakorlam
|
110107e74a |
feat(shortcut-guide): add Claude Desktop manifest (#49245)
## Summary of the Pull Request Adds a Shortcut Guide manifest for Claude Desktop (Claude.exe), covering General (quick chat/search, incognito chat, sidebar toggle, keyboard shortcuts, settings, open-from-anywhere) and In-chat actions (send, new line, extended thinking toggle, file upload, stop generation), pulled directly from the app's own in-app "Keyboard shortcuts" panel (Ctrl+/ inside Claude Desktop). ## PR Checklist - [x] Closes: #49237 - [ ] **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 Note: the "Open Claude from anywhere" global hotkey (Ctrl+Alt+Space) is included since it's shown live in the app's shortcut panel on Windows, though I haven't found it documented on support.claude.com as of this writing — worth flagging in case Anthropic's docs are just behind. Tests/Localization/Dev docs/New binaries/Documentation: N/A — this is a data-only YAML manifest addition, no code changes, following the same shape as the merged Postman manifest (#48461). ## Validation Steps Performed Tested manually against a live build of Shortcut Guide with Claude Desktop focused. Confirmed the Claude section renders with both categories, and recommended shortcuts (Quick chat/search, Open Claude from anywhere) are pinned at top. Screenshot attached below. <img width="547" height="913" alt="Claude_Shortcut_Guide" src="https://github.com/user-attachments/assets/cd4b17ab-058b-4a64-ade9-e34122aa1eab" /> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 7f3671bf-4341-4127-90f2-c8fbd00a1f73 |
||
|
Gordon Lam
|
731f2e3b5f |
Prefer running executable location when resolving PowerToys install path (#48905)
## Summary of the Pull Request `PowerToysPathResolver.GetPowerToysInstallPath()` now resolves the PowerToys installation directory from the **running executable''s own location** first, and only falls back to the registry when the caller is not running from within the PowerToys install tree. Previously the resolver always went through the registry (the `powertoys` protocol registration) for release builds. For the common callers — module executables that ship in the PowerToys install folder (Settings deep links from Color Picker, FancyZones, Image Resizer, Workspaces, etc.) — the install directory is simply the folder the binary was loaded from, so reading it from the running process is more direct and does not depend on the registry registration being present or up to date. The registry path is retained as a fallback for callers that legitimately run **outside** the install tree — notably the packaged Command Palette extension host (MSIX, deployed under `WindowsApps`), which has no other way to locate a separately-installed PowerToys to launch `WinUI3Apps\PowerToys.Peek.UI.exe`. ## PR Checklist - [ ] Closes: #xxx - [x] **Communication:** discussed with core contributors - [ ] **Tests:** Added/updated and all pass - [x] **Localization:** No end-user-facing strings changed - [x] **Dev docs:** Not applicable - [x] **New binaries:** None added ## Detailed Description of the Pull Request / Additional comments `GetPowerToysInstallPath()` (release path) now: 1. Resolves from the current process location first via the existing `GetPathFromCurrentProcess()` helper. This works for both per-user and per-machine installs and for any caller that runs from inside the install tree. 2. Falls back to the registry only when step 1 yields nothing — i.e. for the packaged Command Palette extension host that runs from `WindowsApps`. The per-machine (HKLM) registration is consulted for any process running with administrator rights, since the per-user (HKCU) registration is only meaningful for the interactive user. The change reuses existing helpers (`GetPathFromCurrentProcess`, `GetPathFromRegistry`) and adds no new public API, dependencies, or binaries. Debug-build behavior is unchanged. ## Validation Steps Performed - Built `ManagedCommon` (Release) — compiles clean, 0 warnings / 0 errors. - Verified the three callers of `GetPowerToysInstallPath()`: - In-tree module callers (Settings deep links, Workspaces) resolve via the running executable location. - The packaged Command Palette Indexer (`PeekFileCommand`) still resolves via the registry fallback, since it runs from `WindowsApps` and PowerToys is installed separately. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Boliang Zhang (from Dev Box) <bozhang@microsoft.com> Copilot-Session: 41b6b39b-b620-4e02-b7ca-8ae470a9c1e2 |
||
|
Boliang Zhang
|
0f8120984e |
build(release): advance release train to 0.101 (#49795)
## Summary of the Pull Request Updates `ReleaseTrainVersion` in `src/Version.props` from `0.100` to `0.101` so automatic builds from `main` use the 0.101 release train. ## PR Checklist - [x] **Communication:** This release-train transition was requested and discussed with a core contributor - [x] **Tests:** Existing version resolution was exercised with the updated checked-in value ## Detailed Description of the Pull Request / Additional comments The release pipeline defaults `versionNumber` to `auto`, which reads the checked-in release train from `src/Version.props`. This change advances that source of truth to `0.101` while retaining `ReleaseTrainEpoch` as `2026-01-01` because the train transition occurs in the same calendar year. Automatic builds now generate versions in the form `0.101.<YDDDB>.0`. ## Validation Steps Performed - Ran `.pipelines/resolveBuildMetadata.ps1` for a `main` build with `versionNumber=auto`, build date `20260810`, and daily sequence `1`. - Confirmed the resolved version is `0.101.2221.0` with the `preview` channel. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8e04a72e-3b0f-4ac4-8156-d04ea9b8bb85 |
||
|
Jiří Polášek
|
5b7b91c9de |
CmdPal: Add extension gallery deep links (#49780)
## Summary of the Pull Request
This PR extends the x-cmdpal:// protocol to allow opening the Extension
Gallery and individual Extension Gallery items.
Extension developers can use this to link users directly from their
websites to the gallery, shortening the path to discovering and
installing Command Palette extensions.
- Adds typed x-cmdpal:// URI parsing in CmdPalProtocolActivation.
- Adds gallery and specific-extension deep links.
- `x-cmdpal://extensions/gallery`
- `x-cmdpal://extensions/gallery/{extension-id}`
- Opens extension details after the gallery loads.
- Integrate into existing gallery navigation to prevent garbage nav
stack.
Pictures? Pictures!
https://github.com/user-attachments/assets/d4d55b2a-2624-4a93-bdf7-55348b044b76
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #49770
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
|
||
|
Hashim Khan
|
66f63c988a |
Fix PowerToys Run settings text: searchbox -> search box (#49777)
## Summary Fixes #49717. On the PowerToys Run settings page, the plugin keywords description said "searchbox". Updated the English string to "search box". ## Validation Steps / Documentation 1. Open PowerToys Settings 2. Go to PowerToys Run 3. Confirm the plugin keywords description uses "search box" ## PR Checklist - [x] Closes: #49717 - [x] Communication: I've discussed this with a PowerToys maintainer or discussed this in a GitHub issue / discussion - [ ] Tests: Added or updated tests for this change / N/A for string-only change - [ ] Docs: Documentation has been updated or N/A - [x] Binary assets: N/A |
||
|
Gordon Lam
|
68a2a0d57b |
[Modules] Handle WM_ENDSESSION in run_message_loop daemons (GrabAndMove, AlwaysOnTop, FancyZones) (#48404)
## Summary Companion PR to #48378 (runner). Fixes the same `APPLICATION_HANG_QUIESCE_*_PowerToys.exe!run_message_loop` WER bucket in the other PowerToys daemons whose top-level windows ignored `WM_ENDSESSION`. ## Root cause (same as #48378) `run_message_loop` (`src/common/utils/window.h`) calls `GetMessageW` which only returns `0` on `WM_QUIT`. If a daemon's WndProc lets `WM_ENDSESSION` fall through to `DefWindowProc`, no `WM_QUIT` is ever posted on logoff/shutdown, the loop blocks, CSRSS hits the quiesce timeout (~5s), `TerminateProcess` fires, and Watson logs `APPLICATION_HANG_QUIESCE`. ## `run_message_loop` callsite audit 8 production callsites. Persistent daemons that own a top-level window and were affected: | Module | Status before | Fix here | |---|---|---| | `runner` | hang | Fixed in #48378 | | `GrabAndMove` | hang (tray icon, NIM_DELETE in WM_DESTROY) | ✅ `main.cpp` | | `AlwaysOnTop` | hang | ✅ `AlwaysOnTop.cpp` | | `FancyZones` | hang | ✅ `FancyZones.cpp` | | `KeyboardManagerEngine` | n/a | No top-level window → OS skips WM_ENDSESSION and TerminateProcess directly; no hang bucket possible | | `ZoomIt` | already handled | SysInternals heritage | | `PowerLauncher` | already handled | Managed `SessionEnding` event | | `MeasureTool`, `Notifications` | transient/spawned on demand | Not a shutdown-time daemon | ## Fix pattern For `AlwaysOnTop` and `FancyZones` (no tray icon to clean up) — minimal: ```cpp case WM_ENDSESSION: if (wparam) PostQuitMessage(0); // wparam==FALSE => shutdown vetoed return 0; ``` For `GrabAndMove` (has `Shell_NotifyIcon` cleanup in `WM_DESTROY` that must not run on shutdown) — use a `g_session_ending` flag and skip the tray-icon delete in `WM_DESTROY`, mirroring runner's `tray_icon.cpp` pattern from #48378. No shared header: each module's `WM_DESTROY` cleanup is module-specific; the abstraction would be too thin and would hide the variance in what to *skip*. ## Why no logging on the shutdown path Same reasoning as #48378 review feedback — `spdlog::flush_on(info)` synchronously flushes to disk; emitting log lines from `WM_ENDSESSION`/`WM_DESTROY` burns the ~5s quiesce budget for no diagnostic value (Watson already records the bucket on failure). ## Verification - Built clean (Debug|x64): GrabAndMove.vcxproj, AlwaysOnTop.vcxproj, FancyZonesLib.vcxproj — all exit 0. - Runner counterpart fix (#48378) verified end-to-end with real reboot + WM_ENDSESSION injection; quiesce 1–8 ms. Same OS-level mechanism applies here. ## Related - #48378 — runner fix (this PR's companion) - #48363 — original community fix (over-engineered; this approach is the minimal correct one) --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Gordon Lam
|
ed7595f3a7 |
Harden IPC pipe ownership and shutdown lifecycle (#48902)
## Summary of the Pull Request The two-way named-pipe IPC server (`TwoWayPipeMessageIPC`, shared by the runner, Settings, and Quick Access host) created every pipe instance without `FILE_FLAG_FIRST_PIPE_INSTANCE`. If a pipe with the same name already existed — for example a leftover instance from a previous run or another process — `CreateNamedPipe` would quietly create an *additional* instance and share the name instead of owning it. This makes `start_named_pipe_server` create the **first** instance with `FILE_FLAG_FIRST_PIPE_INSTANCE`, so `CreateNamedPipe` fails fast on a name collision and the server is the authoritative owner of its pipe name. ## PR Checklist - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized (N/A — no user-facing strings) - [x] **Dev docs:** Added/updated (N/A) - [x] **New binaries:** Added on the required places (N/A — no new binaries) ## Detailed Description of the Pull Request / Additional comments - The flag is applied **only** to the first instance. Subsequent instances continue to omit it, so the existing `PIPE_UNLIMITED_INSTANCES` behavior is fully preserved. - The change is contained to a single function in `src/common/interop/two_way_pipe_message_ipc.cpp`. Public signatures and the `PowerToys.Interop` ABI are unchanged, so the runner, Settings, and Quick Access host all benefit without any code changes on their side. ## Validation Steps Performed - The existing `Common.Interop.UnitTests` `TestSend` exercises the modified first-instance code path (`Start()` → `start_named_pipe_server`) and continues to pass — a full IPC round-trip still works. - Verified the updated `CreateNamedPipe` open-mode logic compiles cleanly. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 49797c8c-784d-47e6-bc0f-53464eecec4b |
||
|
Boliang Zhang
|
9d96049b1f |
[Mouse Jump] Sign new WinUI3 binaries (#49747)
## Summary - add the new Mouse Jump HotKeys, Models, and WinUI3 binaries to the core ESRP signing policy - remove the retired MouseJumpUI signing entries ## Context The signed main build [154175666](https://microsoft.visualstudio.com/Dart/_build/results?buildId=154175666) failed for both x64 and ARM64 because the binaries introduced by #48393 were not selected for signing. ## Validation - parsed `.pipelines/ESRPSigning_core.json` successfully - confirmed all four new binary names are present and the two obsolete names are removed --------- Copilot-Session: 11e23507-f1c3-45e5-888d-22cd78240f6b |
||
|
Jiří Polášek
|
9e12b7a8ee |
CmdPal: Reduce items on default perfmon band (#49674)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR limits the number of items shown in the default Performance Monitor dock band to prevent an overcrowded Dock experience. - Limits the primary Performance Monitor dock band to CPU and RAM. - Adds a new single-item dock band for network speed, showing upload and download traffic. (The existing single-item Network shows only % usage). - Updates the default docks to include both the primary Performance Monitor band (CPU and RAM) and the new Network Speeds (Received / Sent) band. This PR intentionally avoids solving the question of what to do with the original Performance dock band, that should be triaged separately. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Jiří Polášek
|
03c571e1fc |
CmdPal: Aggregate net adapter stats and default adapter selection (#49678)
## Summary of the Pull Request This PR introduces a new virtual network adapter in performance monitor that sums up data from all physical adapters. That way users will see any network usage, and for most of them it might be good enough. For the rest, this PR adds a new command to set any network adapter as a default. - Switches from Performance Counters to raw GetIfTable2. - Adds a new virtual network adapter "All" and uses it as a default. - Adds a new command to set an actual default network adapter for the perfmon. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Jiří Polášek
|
9cfba78b60 |
CmdPal: Clean up removed top-level view models (#49728)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR ensures that manager-owned top-level commands and dock bands release their extension subscriptions when they leave their collections. Previously, provider reloads, removals, and enable/disable cycles could retain discarded view models and their extension object graphs. - Add an explicit cleanup path to `TopLevelViewModel`. - Clean up commands and dock bands displaced by provider updates. - Clean up entries removed during full command reloads. - Clean up provider entries when a provider is removed or disabled. - Perform cleanup after releasing collection locks. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Jiří Polášek
|
a18779ec7c |
CmdPal: Clean up replaced command view models (#49730)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR formalizes ownership of command view models so replacing a command releases the outgoing owned instance without cleaning up commands borrowed by synthetic context items. It applies the same cleanup discipline to parameter commands and partially built parameter lists. This is one of the places that let Command Palette hold COM proxies much longer than it's desirable. - Track whether a `CommandViewModel` is owned or borrowed. - Add replacement logic that cleans up outgoing owned commands. - Add a borrowing path for shared command instances. - Clean up commands replaced in parameter view models. - Roll back partially initialized parameter-list updates. - Add regression tests for replacement and failure paths. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Jiří Polášek
|
a0619fe430 |
CmdPal: Release extension objects after navigation (#49732)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR replaces the bare collection performed after leaving a list page with a complete collection and finalization cycle. WinRT and COM proxies are released by their finalizers, so a single `GC.Collect()` can leave extension-owned objects retained on the finalizer queue. Correctly offloaded onto background thread shouldn't pose UX issue, and finalizers are only way to release COM garbage. For now, I left the call only in the original place: - Content and Parameter pages shouldn't generate too much garbage, so we don't have to push for release explicitly. - I considered cleanup when the CmdPal cloaks, but that would be redundant to the cleanup after navigation. Changes: - Adds a reusable `ExtensionObjectReleaser` class that can push hard enough on GC to trash COM garbage. - Schedules cleanup after navigation instead of collecting immediately. - Runs a collect, finalizer drain, and second collect off the UI thread. - Debounces navigation bursts into a single cleanup cycle. - Reschedules requests when another release cycle is already running. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Copilot
|
14b09db016 |
Add Brave Browser keyboard shortcuts manifest for Shortcut Guide (#49615)
Shortcut Guide had no manifest for Brave Browser, so no shortcuts were displayed when Brave was the active window. ## Summary of the Pull Request Adds `BraveSoftware.BraveBrowser.en-US.yml` to the Shortcut Guide manifests directory. Uses `WindowFilter: "brave.exe"` to match the active process. The index is auto-generated at runtime by enumerating all `.yml` files, so no code changes are required. ## PR Checklist - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx ## Detailed Description of the Pull Request / Additional comments 57 shortcuts across 4 sections, mirroring the Chrome manifest structure (Brave is Chromium-based) with Brave-specific adjustments: - **Tabs and windows** — standard tab/window management plus Brave's unique "New private window with Tor" (`Ctrl+Alt+N`) - **Brave features** — Brave Shields toggle (`Alt+D`), bookmarks bar, history, downloads, DevTools, task manager, find bar, clear browsing data - **Address bar** — navigation and search shortcuts - **Web page** — print, save, reload, zoom, bookmarking, page source, scrolling ## Validation Steps Performed - YAML parsed and validated programmatically; structure matches the existing manifest schema - Confirmed `WindowFilter: "brave.exe"` matches the Brave Browser executable name - Confirmed index.yml is generated at runtime from all `.yml` files — no index update needed <!-- START COPILOT CODING AGENT SUFFIX --> - Fixes #49605 --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> |
||
|
Jiří Polášek
|
d96144a506 |
CmdPal: Prevent crashes when switching main window backdrops on the fly (#49755)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR prevents CmdPal from crashing when switching backdrops and fixes transparent tint. - Keeps a single SystemBackdrop attached and root projected targets until WinUI disconnects them. - Swaps and dispose controllers, brushes, and compositors on the XAML thread. - Restores tint for transparent solid backdrops using a retained composition brush. - Coalesces theme updates and retry transient native backdrop handoffs. - Adds a fallback background if "Ooops" happens. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #49744 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Mike Griese
|
f2796b74a5 |
CmdPal: make dialogs prevent compact mode from being collapsed (#49451)
ContentDialogs we present for CommandResult.Confirm need to be visible. When the window is clipped for compact mode, the dialog is predictably also collapsed. This makes sure that content dialogs are always visible, by forcing us out of compact mode when dialogs are shown. Closes: quite sure it was filed somewhere, right? |
||
|
Gleb Khmyznikov
|
a87f5b07a9 |
Advanced Paste additional customizations and PhiSilica provider (#46727)
## Summary Adds an on-device **Phi Silica (Windows AI) paste provider** to Advanced Paste and richer per-action customization, plus the **package-identity plumbing** that lets the unpackaged Advanced Paste app use Windows AI APIs. > Note: this supersedes the earlier "self-contained MSIX package installed/registered by the > WiX installer" approach. Advanced Paste is **not** packaged or installed as a standalone > MSIX. It keeps shipping as the existing unpackaged, self-contained WinUI 3 executable in > `WinUI3Apps/` and acquires **package identity at runtime from the existing PowerToys sparse > package** — there are no installer or ESRP MSIX repack changes. ## Advanced Paste features - **New Phi Silica paste provider** (`CustomActions/PhiSilicaPasteProvider.cs`): an on-device AI provider backed by the Windows AI Phi Silica language model — no cloud endpoint or API key required. Registered as a new `AIServiceType` via `PasteAIProviderFactory` / `AIServiceTypeRegistry`. - **Additional custom actions** (`AdvancedPasteAdditionalAction`): user-defined actions with their own prompt, system prompt, AI provider, and shortcut — plus an optional "coaching" prompt/system-prompt/provider/shortcut and shortcut-conflict detection. - **Built-in default prompts** (`AdvancedPasteDefaultPrompts`) and updates to `AdvancedPasteCustomAction`, `PasteFormat(s)`, `OptionsViewModel`, and `PasteFormatExecutor` to support per-action provider selection and system prompts. - **Settings UI** (`AdvancedPastePage.xaml`/`.xaml.cs`, `Resources.resw`): configure the Phi Silica provider, choose a provider per action, edit system/coaching prompts, and a Phi Silica availability/readiness experience — Settings queries the Advanced Paste executable via `--check-phi-silica`, and a **"Download model"** action triggers `--prepare-phi-silica` to fetch the model and then re-probes. ## Package identity for Windows AI (replaces the MSIX-install approach) - Phi Silica is a **Limited Access Feature (LAF)** that can only be unlocked by a process with a registered **package identity**. Advanced Paste runs unpackaged, so it obtains identity from the existing **`Microsoft.PowerToys.SparseApp`** sparse package (`src/PackageIdentity/`): a new `<Application Id="PowerToys.AdvancedPasteUI">` entry in `AppxManifest.xml` maps it to `PowerToys.AdvancedPaste.exe`, with matching updates to `BuildSparsePackage.ps1`. - **LAF unlock** at runtime via `PhiSilicaLafHelper.cs`. The token/attestation are baked at build time by the `GeneratePhiSilicaLafCredentials` MSBuild target into `PhiSilicaLafCredentials.g.cs` — local **dev defaults** live in `src/PhiSilicaLaf.props` (imported from `Directory.Build.props`) and the **production secret** is injected via `/p:` in the release pipeline. - New **`AdvancedPaste.dev.manifest` / `AdvancedPaste.prod.manifest`** application manifests (selected by `CIBuild`) declaring full-trust and the system AI models capability. ## Build & pipeline - **Windows App SDK** moved to the coherent **stable `2.2.0`** line and **added `Microsoft.WindowsAppSDK.AI` `2.2.3`** (the Phi Silica APIs). Foundation `2.1.0` carries the sparse-identity PRI fix, and the stable AI build matches the OS Windows AI runtime. - **Independent versioning** for Advanced Paste (`src/modules/AdvancedPaste/custom.props`, XES one-store versioning, `AdvancedPasteVersion`). A `steps-setup-versioning.yml` step is added for Advanced Paste in `job-build-project.yml`, ordered **before** CmdPal to avoid a version-collision installer failure (WIX0103). - `release.yml` passes `PhiSilicaLafToken`/`PhiSilicaLafAttestation` into the main build; spell-check allow-list/patterns updated. - Removed now-unneeded dependencies: the `Microsoft.Windows.Compatibility` reference and the `Common.UI` "force matching DLL versions" hack. <img width="1073" height="716" alt="image" src="https://github.com/user-attachments/assets/9364d86a-c0d1-4a08-a669-d98cbcb4b140" /> <img width="1038" height="308" alt="image" src="https://github.com/user-attachments/assets/00eef1dd-b407-4841-bd64-f54f8a145c46" /> <img width="194" height="405" alt="image" src="https://github.com/user-attachments/assets/d2f9c5bb-2507-4112-b3e0-56da681f88ea" /> <img width="489" height="453" alt="image" src="https://github.com/user-attachments/assets/811d1afd-9993-48be-824e-82bb56c5ceca" /> [Video clip internal](https://onedrive.cloud.microsoft/✌️/a@9n6nl3fp/S/cQpvAHrL5M9ZR6eUawztyfyBEgUCwCF-aKg9TbKyyGWP4c0KMA) [Build internal](https://microsoft.visualstudio.com/Dart/_build/results?buildId=149920754&view=artifacts&pathAsName=false&type=publishedArtifacts) --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> |
||
|
Jiří Polášek
|
56025d7372 |
CmdPal: Separate in-flight icon loads from cached results (#49738)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR is stacked on #49737 and separates in-flight icon loading from completed-result caching. The XAML request path no longer takes a provider-wide lock, while concurrent requests for the same icon still share a single task and completion cleanup can retire only that exact task generation. The loader now reports whether queue admission succeeded, preventing requests rejected during shutdown from remaining pending indefinitely. Overall, it seems that we got rid of a lock and actually reduced turnaround on UI thread. The separate in-flight tracking takes its tall, but overall throughput increased (tl;dr - it's faster). - Deduplicate outstanding icon loads in a dedicated in-flight dictionary. - Cache successful tasks before atomically retiring their in-flight entries. - Keep failed and rejected loads out of the adaptive cache so they can be retried. - Replace `EnqueueLoad` with `TryEnqueueLoad` and fault rejected requests. - Add tests for concurrent loading, publication ordering, failures, rejection, and retries. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Jiří Polášek
|
601460561a |
CmdPal: Avoid all-stripe locking in the adaptive icon cache (#49737)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR removes all-stripe synchronization from `AdaptiveCache`. Using `ConcurrentDictionary.Count` for capacity checks and `Keys` while clearing could acquire every dictionary stripe, allowing XAML-bound icon cache operations to wait behind unrelated concurrent mutations. **The main problem here is that WinUI doens't take locked main STA thread well and can fail-fast the app.** - Track an approximate entry count with atomic updates after successful mutations. - Use the approximate count for capacity checks and maintenance decisions. - Enumerate the dictionary directly when clearing instead of snapshotting `Keys`. - Add concurrent cleanup and count-consistency regression tests. - Add a matching CmdPal UI unit-test project to the solution. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Jiří Polášek
|
3a84795531 |
CmdPal: Avoid redundant performance widget refreshes (#49735)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR removes a redundant collection refresh from Performance Monitor's periodically invoked disk metrics callback. The callback already updates the existing list item titles in place, so raising `ItemsChanged` on every sample needlessly asks Command Palette to refresh an unchanged collection. - Stop raising `ItemsChanged` from the disk page's `Updated` handler. - Continue updating disk usage and read/write speed titles in place. - Avoid repeated collection refresh work during periodic performance sampling. |
||
|
Jiří Polášek
|
a5b1ec8124 |
CmdPal SDK: Fix weak command property subscriptions (#49731)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR fixes a weak-event subscription in the CmdPal toolkit that still captured its owning `CommandItem` through an instance callback. That strong reference defeated the weak listener, while command replacement could also leave a stale handler attached to the outgoing command. - Make the command property-change callback static. - Resolve the owning `CommandItem` through the listener's weak reference. - Explicitly unsubscribe from the outgoing command during replacement. - Retain the detach callback that removes dead listeners from long-lived commands. |
||
|
Jiří Polášek
|
d70ab95355 |
CmdPal: Remove article from "Select a file" button text (#49752)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR changes file picker parameter button text from "Select a file" to "Select file". ## Pictures? Pictures! <img width="1600" height="953" alt="image" src="https://github.com/user-attachments/assets/221eeceb-ac49-4469-8989-b8d01cb4dd2c" /> <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Niels Laute
|
57d32bcb6b |
Fix Keyboard Manager editor file picker not opening when elevated (#48876)
## Summary Fixes #48845. In the new WinUI 3 Keyboard Manager editor, clicking the **browse icon** to select a program path (or "start in" folder) for the *Run Program* action did nothing — no dialog appeared. ### Root cause The editor (`PowerToys.KeyboardManagerEditorUI.exe`) is launched by the Keyboard Manager module DLL via `ShellExecuteExW` from inside the PowerToys runner (`src/modules/keyboardmanager/dll/dllmain.cpp`). When PowerToys runs elevated, the editor **inherits that elevation**. The browse buttons used the legacy **`Windows.Storage.Pickers`** (`FileOpenPicker` / `FolderPicker` + `InitializeWithWindow`). Those pickers activate through the UWP runtime broker, which fails with `E_ACCESSDENIED` in an elevated process. The handlers were `async void` with no `try/catch`, so the exception was swallowed and no dialog ever opened. Typing/pasting a path into the field still worked — matching the bug report. ### Fix Switch both handlers to the Windows App SDK **`Microsoft.Windows.Storage.Pickers`** API, constructed with a `WindowId`. Those pickers are a thin wrapper over the in-process Win32 Common Item Dialog (`IFileOpenDialog`, `CLSCTX_INPROC_SERVER`) and work correctly in elevated processes — the same mechanism already used elsewhere in PowerToys (e.g. Settings UI `IFileDialog`/`GetOpenFileName`, and CmdPal which already uses this exact namespace). Also wrapped the handlers in `try/catch` with `Logger.LogError` so any future failure is logged instead of silently swallowed. ### Verification - Built `KeyboardManagerEditorUI.csproj` (Release / x64) with all native dependencies — exit code 0. - Confirmed against the Windows App SDK source that `Microsoft.Windows.Storage.Pickers.FileOpenPicker` uses `create_instance<IFileOpenDialog>(CLSID_FileOpenDialog, CLSCTX_INPROC_SERVER)` and `dialog->Show(hwnd)`, i.e. the elevation-safe in-process dialog. ### Notes / out of scope The report also mentions some apps (e.g. `visio.exe`) not launching while others (`winword.exe`) do. That's a separate issue in the launch path (`run_non_elevated` uses `CreateProcessW`, which ignores registry App Paths / shell activation, unlike `ShellExecute` used by the *Open URI* action) and is **not** addressed here. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Copilot-Session: 1f00def4-e790-4071-96c6-a81c9c2adba5 |
||
|
Jiří Polášek
|
9f2ddf6e85 |
CmdPal: Set Settings window titlebar PreferredTheme to UseDefaultAppMode (#49750)
## Summary of the Pull Request This PR should fix the incorrect foreground color of title bar glyphs after a theme change by setting the Settings window's title bar `PreferredTheme` to [`TitleBarTheme.UseDefaultAppMode`](https://learn.microsoft.com/en-us/windows/windows-app-sdk/api/winrt/microsoft.ui.windowing.titlebartheme?view=windows-app-sdk-2.0). |
||
|
Jiří Polášek
|
81d3bb8e34 |
CmdPal: Initialize page icons after property changes in PageViewModel (#49672)
## Summary of the Pull Request This PR is a quick fix for pages that changes their icon at runtime, and then the icon is nowhere to be seen. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Niels Laute
|
363226587b |
feat(settings-ui): add update channel selector (#49722)
Supersedes #49719, which cannot be reopened because its original base branch was deleted after #49414 merged. ## Summary of the Pull Request Improves the update settings introduced by #49414 by replacing the prerelease checkbox with a dedicated **Update channel** expander. Users can choose between Stable and Insider channels, see the current selection while the expander is collapsed, and access the PowerToys Insider documentation. The new expander preserves the existing `IncludePrereleaseUpdates` setting and displays its own managed-by-organization state when the preview update policy is configured. <img width="1576" height="526" alt="image" src="https://github.com/user-attachments/assets/35863d4b-5ca1-4662-9d84-f184c98dbbc6" /> ## PR Checklist - [x] **Communication:** This builds on the update channel work merged in #49414 - [ ] **Tests:** No automated tests added; this is a Settings UI presentation change over the existing setting - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Documentation updated:** Documentation changes are maintained separately ## Detailed Description of the Pull Request / Additional comments - Moves `IncludePrereleaseUpdates` out of the general update settings list into a dedicated SettingsExpander in `src/settings-ui/Settings.UI/SettingsXAML/Views/GeneralPage.xaml`. - Adds Stable and Insider radio-button choices, descriptions, collapsed status text, and an Insider learn-more link. - Adds localized strings in `src/settings-ui/Settings.UI/Strings/en-us/Resources.resw`. - Separates the preview update policy warning from the other update settings warnings in `src/settings-ui/Settings.UI/ViewModels/GeneralViewModel.cs`. ## Validation Steps Performed - Built `src/settings-ui/Settings.UI/PowerToys.Settings.csproj` for Debug ARM64 with the repository build script. - Applied the repository XAML Styler configuration to `GeneralPage.xaml`. --------- Copilot-Session: 4169c03d-5e17-4495-b7b1-8e6af0d6565c |
||
|
Niels Laute
|
9df98bdad3 |
Add progress/result window to the Bug Report flow with a GitHub issue shortcut (#48980)
## Summary of the Pull Request Adds a small, native progress/result window to the **Bug Report** flow so users get feedback while the report is generated and a one-click path to file a GitHub issue. Previously, triggering "Report bug" (from the tray menu or **Settings → General**) ran `PowerToys.BugReportTool.exe` hidden for ~30 seconds with **no feedback at all**, then popped a plain message box. Many users then had to manually find the `.zip` and figure out where to file the issue. Now the runner shows a lightweight window that: - Displays an animated **"Generating bug report…"** state while the tool runs. - On completion, shows **where the `.zip` was saved** (`…\Desktop\PowerToysReport_<timestamp>.zip`) in a read-only, copyable field. - Offers **Open folder** (reveals/selects the `.zip` in Explorer) and **Report on GitHub** (opens the prefilled `bug_report.yml` issue template *and* reveals the `.zip` so it can be dragged into the issue). - Shows a clear error state if the report could not be created. > Note: GitHub has no API/URL to pre-attach a binary to a new issue (attachments only happen via browser drag-drop). So the "Report on GitHub" action does the next best thing: opens the prefilled issue page and highlights the `.zip` in Explorer for a single drag to attach. https://github.com/user-attachments/assets/9307d728-bbbd-4258-9480-ced65d2fa065 ## PR Checklist - [ ] Closes: #xxx - [x] **Communication:** Lightweight, additive UX on an existing feature; happy to adjust per maintainer feedback. - [ ] **Tests:** No automated tests (native Win32 window in the runner); validated manually — see below. - [x] **Localization:** All end-user-facing strings are added to `src/runner/Resources.resx` and loaded via `GET_RESOURCE_STRING`. - [ ] **Dev docs:** N/A - [x] **New binaries:** None — `bug_report_dialog.cpp/.h` compile into the existing `PowerToys.exe` (runner). No new WinUI app or DLL, so no signing/WXS/CI changes required. ## Detailed Description of the Pull Request / Additional comments - New files `src/runner/bug_report_dialog.{h,cpp}` implement the window as plain Win32 (no Common Controls v6 dependency, no managed/WinUI payload), so it works for **both** entry points since it lives in the runner. - `bug_report.cpp` now calls `run_bug_report_dialog(...)` instead of the silent run + message box. The "running" state (observed by Settings) is cleared as soon as the **tool process** exits, so the result window can stay open without keeping the Settings button spinning. A guard re-focuses an already-open window instead of starting a second report. - The window uses the canonical `AttachThreadInput` foreground recipe so it reliably surfaces even when launched from Settings (a different foreground process), and gets a taskbar button so it stays findable during the ~30s run. - The output path is discovered by locating the newest `PowerToysReport_*.zip` in the Desktop folder after the tool exits (the tool names the file internally with a timestamp). - Strings added: dialog title, generating/hint text, done header/hint, failed text, and button captions. ## Validation Steps Performed - Triggered **Report bug** from the **system tray** menu: window appears in the foreground, animates "Generating…", then shows the saved `.zip` path with working **Open folder** and **Report on GitHub** buttons. - Verified **Open folder** selects the `.zip` in Explorer and **Report on GitHub** opens the prefilled `bug_report.yml` issue template with the `.zip` highlighted for drag-and-drop. - Verified the error state renders correctly (and wraps long localized text) when the tool can't run. - Built `runner` (ARM64, Debug) clean; verified end-to-end on a high-DPI display. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> |
||
|
Boliang Zhang
|
bb12277d8d |
fix(ci): support automatic versions and counter-exhaustion recovery (#49745)
## Summary of the Pull Request Follow-up to #49414 that fixes two release-pipeline recovery issues: - Azure DevOps treats an empty runtime string parameter as required, so `.pipelines/v2/release.yml` now uses `auto` as the default version override. - Explicit `main` and `stable` version overrides are resolved before automatic `YDDDB` generation, allowing a manually versioned build to proceed after the daily sequence exceeds 9. ## PR Checklist - [x] **Communication:** This is a follow-up to the reviewed preview-release versioning design in #49414 - [x] **Tests:** Added/updated and all pass ## Detailed Description of the Pull Request / Additional comments `auto` is normalized to an empty override in `.pipelines/resolveBuildMetadata.ps1`, preserving automatic release-train version generation without requiring input in the Run Pipeline dialog. Override parsing is now separated from automatic version generation. Full explicit versions bypass daily-sequence and generated-date validation, while automatic versions continue to require a sequence from 1 through 9 and fail closed outside that range. `.pipelines/tests/resolveBuildMetadata.Tests.ps1` covers scheduled `main` with the `auto` default, automatic `stable` generation, and explicit preview/stable recovery when the daily counter has reached 10. ## Validation Steps Performed - `Invoke-Pester .pipelines\tests\resolveBuildMetadata.Tests.ps1 -EnableExit` — 22 passed - Confirmed `auto` resolves a first August 7 stable build to `0.100.2191.0` - Confirmed explicit `0.101.0` resolves to `0.101.0.0` with daily sequence 10 Copilot-Session: 8e04a72e-3b0f-4ac4-8156-d04ea9b8bb85 |
||
|
Michael Clayton
|
e0010c5642 |
Ready for Review - [Mouse Jump] - port upstream WinUI3 code to Mouse Jump (microsoft#48290) (#48393)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Changes for #48290 to convert Mouse Jump to a WinUI app and remove all
remaining dependencies on WinForms, based on work already done in the
original "FancyMouse" project
(https://github.com/mikeclayton/FancyMouse).
## Notes for reviewers
* the new WinUI build of the app is output into the "/WinUI3Apps"
subfolder
* there's 2 new assemblies that need to be added to the installation as
well - MouseJump.HotKeys.dll and MouseJump.Models.dll. I'm not sure how
to add those to the installer for signing / shipping...
---
### Summary of changes
* New thumbnail layout and rendering code
* WinUI rewrite (winforms version still committed)
* MouseJump.Kicker (dev launch tool)
* CsWin32 for interop
* New assemblies - code reorganised
---
### 1. New layout code
Incorporates latest FancyMouse core layout and rendering logic into
Mouse Jump:
* includes **support** for multiple devices in layout algorithms
* preview still only shows local machine though
* prerequisite for long-term goal #34126
<img width="650" height="709" alt="image"
src="https://github.com/user-attachments/assets/9d1d996d-ed05-4471-b8a5-bd93442f70dc"
/>
### 2. WinUI rewrite
Port latest stable FancyMouse WinUI implementation into Mouse Jump.
Existing WinForms UI left in-situ side-by-side for now - easy to delete
if not needed.
### 3. MouseJump.Kicker
A small dev utility to start Mouse Jump without needing to build the
runner project:
<img width="283" height="274" alt="image"
src="https://github.com/user-attachments/assets/c81bb3f5-5008-48ce-8bc0-eef18413dee6"
/>
### 4. Cswin32 for interop
All win32 interop is now accessed via CsWin32 bindings.
The original win32 bindings were heavily influenced by CsWin32 generated
code (e.g. ```BOOL```, ```HWND```, etc structs), so there's not actually
much change other than deleting a lot of boilerplate code.
### 5. New assemblies
Some code has been reorganised into new assemblies to make it easier to
keep Mouse Jump in sync with upstream FancyMouse
* MouseJump.HotKeys
* MouseJump.Models
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes #48290
- [x] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end user facing strings can be localized
- all ui strings come from Resources.resw
- [x] **Dev docs:** Added/updated
- no changes required
- [x] **New binaries:** Added on the required places
- no changes required
- [x] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [x] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [x] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [x] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [x] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
- no changes required
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
- **Workflow tests**
- [x] Automated tests passing locally
- [x] Minimal actions workflow (spelling check) passing for PR
- [ ] Full actions workflow (msbuild) passing for PR
- **UI tests**
- [x] Happy path
- [x] preview image appears when activated
- [x] clicking the preview image moves the mouse cursor to the correct
location
- [x] right-click dismisses the preview image without moving the mouse
- [x] pressing escape dismisses the preview image without moving the
mouse
- [x] left or right clicking another application / desktop dismisses the
preview image without moving the mouse
- [x] Works on multiple monitors with different dpi scaling settings
(e.g. 100% vs 150%)
*
https://github.com/microsoft/PowerToys/pull/23566#issuecomment-1411869418
*
https://github.com/microsoft/PowerToys/pull/23566#issuecomment-1412834413
- [x] Handling negative coordinates on non-primary monitors if higher or
"lefter" than primary monitor
*
https://github.com/microsoft/PowerToys/pull/23566#issuecomment-1404931694
- [x] Mouse crosshair moves when Mouse Jump moves the cursor (mouse
clicks *and* keyboard shortcuts)
* #24523
* #24527
- [x] Activating when the preview window is already visible moves the
form to the new mouse position
- [x] Number and key shortcuts (1-9, Home / End, Left / Right Arrow)
jump to the appropriate monitor
- [x] Number-pad shortcuts (1-9 jump to the appropriate monitor
- **Settings tests**
- [x] Changing thumbnail size settings updates the size of the thumbnail
- [x] Changing preview type between Compact, Bezelled and Custom shows
the correct preview type
- [x] Changing custom preview settings shows the correct settings
- [ ] Launching with settings version 1.0 upgrades settings to version
1.1, with "Bezelled" as the default style and the "Custom" settings
preconfigured to match "Bezelled"
- **Lifecycle tests**
- [x] Starting PowerToys Runner launches MouseJump exe when enabled, and
not when disabled
- [x] Enabling / disabling Mouse Jump in settings starts / stops
MouseJump exe
- [x] Exiting PowerToys Runner stops MouseJump exe
- [x] Killing runner exe via Task Manager stops MouseJump exe
- [x] Stopping Visual Studio local debug run stops MouseJump exe
- note - runner needs to be in *non*-admin mode otherwise Visual Studio
debugger disconnects at launch
- [x] Hotkey and size settings are automatically reloaded when config
file is modified from Settings UI
- [ ] ~~Hotkey and size settings are automatically reloaded when config
file is modified manually (e.g. in notepad) while runner and
MouseJumpUI.exe are running~~
- **[Internal Test
Suite](
|
||
|
Clint Rutkas
|
9fcb8faac5 |
[Quick Accent] Isolate press-and-hold activation (#49701)
## Summary of the Pull Request Makes the **Press and hold the letter** activation method exclusive. Pressing a legacy trigger key (Space or either arrow) before the hold threshold now cancels that owner-letter gesture and passes the trigger through normally, instead of allowing the already-scheduled picker to appear later. Typing any different supported physical letter during the gesture also cancels it, preventing that intervening character from being replaced when the owner letter is released. Space and arrow navigation remains available after a genuine hold activation reaches its threshold. ## PR Checklist - [ ] Closes: N/A - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: N/A ## Detailed Description of the Pull Request / Additional comments The native keyboard listener previously armed press-and-hold on owner-letter key-down and immediately queued a delayed managed render. Although pre-threshold Space/arrows were excluded from native trigger-key activation, they did not invalidate that pending render. Holding the owner letter after pressing Space therefore still displayed the picker and made both invocation systems feel enabled. This change adds an explicit native-to-managed cancellation event and a generation-based managed display state: - In `PressAndHold`, Space or either arrow before the snapshotted hold threshold cancels the current gesture and passes through without input injection. - Space/arrows at or after the threshold retain their intended picker navigation behavior. - Any different physical letter in Quick Accent's supported key set cancels the owner gesture before passing through, even when that letter has no mapping in the selected language. - Owner repeats and owner key-up are handled from active physical ownership rather than current language eligibility, so live language changes cannot leave stale state. - Activation mode, input time, and hold duration are atomically published and snapshotted once per owner gesture. The native listener passes the same delay snapshot to managed scheduling, so live settings changes apply to the next gesture instead of desynchronizing native interaction from picker visibility. - Character data is prepared before native navigation can become interactive, preventing accepted navigation from being dropped. - Legacy Space/arrow/Both acquisition behavior is preserved. The low-level hook has no clean deterministic native unit-test seam because its private handlers depend on Win32 keyboard state. Managed regression coverage exercises delayed-display cancellation, re-arming, generation invalidation, and delay snapshot preservation. ## Validation Steps Performed - Built `src/modules/poweraccent/PowerAccent.UI/PowerAccent.UI.csproj` in `Debug|x64`, covering the native WinRT projection and managed Core/UI. - Built `src/modules/poweraccent/PowerAccentKeyboardService/PowerAccentKeyboardService.vcxproj` in `Debug|x64`. - Built and ran all `PowerAccent.Core.UnitTests`: **35 passed, 0 failed**. - Ran `git diff --check`. - Performed focused code reviews of pre-threshold trigger cancellation, intervening mapped/unmapped letters, live mode/duration snapshots, language changes, owner key-up balance, and post-threshold navigation. --------- Copilot-Session: cbd8418a-64cb-4c6c-8653-2f3f0a6ceb9e |
||
|
Clint Rutkas
|
ddeb7f1bf5 |
[Always On Top] Render a solid border frame (#49698)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Fixes the Always On Top frame appearing mottled or translucent even when frame opacity is set to 100%. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments The frame helper window is intentionally placed behind the tracked window. The previous Direct2D rendering used a centered stroke, so the tracked window occluded the stroke's inner half. With per-primitive antialiasing enabled, partial-coverage pixels became disproportionately visible in the remaining thin outer half, making a fully opaque frame look mottled. This change replaces the centered stroke with a filled, even-odd outer/inner geometry ring. It preserves configured opacity, the transparent interior, DPI-scaled frame thickness and corner radius, smooth rounded corners, and target-window occlusion while limiting antialiasing to the ring's actual contours. It also recreates render-target-bound brush resources when the HWND render target is recreated, clears stale resources on `D2DERR_RECREATE_TARGET`, and redraws when rectangle or corner geometry changes. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed - Built `src\modules\alwaysontop\AlwaysOnTop\AlwaysOnTop.vcxproj` for Debug x64 successfully. - Ran the freshly built `PowerToys.AlwaysOnTop.exe` with frame opacity 100%, thickness 4, and rounded corners enabled. - Pinned a controlled Win32 window and confirmed it received `WS_EX_TOPMOST`. - Confirmed the module created an `AlwaysOnTop_Border` HWND sized 946x627 behind the 960x630 target window. - Restored the temporary setting change and stopped the test processes. Residual limitation: the RDP input desktop was detached, so composed-screen pixel capture was unavailable. `winapp` could capture the layered border HWND only by flattening transparency to black, which is not trustworthy visual pixel evidence. An interactive-desktop visual check is still recommended. Copilot-Session: c2697877-8736-4e8d-add3-06ed2cec15b9 |
||
|
Jiří Polášek
|
e403027451 |
CmdPal: Improve dock buttons (#49703)
## Summary of the Pull Request - Scales down a dock button icon when pressed down; - Gives user a better feedback; - Hides delay if the icon changes as a result of that click. - Adds a small gap between the edge(s) and the dock button; - Gives a cleaner visual separation when mouse is over or pressed. - Whole area, including the gap is still clickable. - Updates size of dock button that only has an icon to be a square. - Updates button style to give it more button/3D appearance on hover. - Updates sizes and padding in vertical dock layouts to give buttons more space. ## Pictures? Pictures! https://github.com/user-attachments/assets/80b59ccf-b7ff-487e-9c63-621a1c91ae89 <img width="1362" height="304" alt="image" src="https://github.com/user-attachments/assets/ef2a642d-90f5-41d4-a156-deda8d0d2c57" /> <img width="575" height="2159" alt="image" src="https://github.com/user-attachments/assets/e07d5450-6e2f-4ac5-8981-531980807234" /> <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Niels Laute
|
848b3a3465 |
[Mouse Without Borders] Fix German ampersand localization (#49687)
## Summary of the Pull Request Adds translator guidance for the Mouse Without Borders OOBE description so the German translation uses a literal ampersand in "Drag & Drop" instead of displaying the HTML entity text. ## PR Checklist - [x] Closes: #42943 - [x] **Communication:** Requested by a core contributor - [x] ~~**Tests:** Added/updated and all pass~~ Not applicable; localization comment only - [x] **Localization:** All end-user-facing strings can be localized - [x] ~~**Dev docs:** Added/updated~~ Not applicable - [x] ~~**New binaries:** Added on the required places~~ Not applicable - [x] ~~**Documentation updated:**~~ Not applicable ## Detailed Description of the Pull Request / Additional comments The German translation of `Oobe_MouseWithoutBorders.Description` currently renders `Drag & 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 |
||
|
Michael Jolley
|
f20348386a |
[CmdPal] Replace main-page magic-number scoring with a principled tiered ranker (#49189)
>[!WARNING] > This PR is one in a series of PRs focused on rearchitecting the search/scoring logic of the `MainListPage`. An explanation of the entire search/scoring logic can be found below. > > **This PR should not be merged until PR #49190 is merged into it.** >[!NOTE] > To test the final result, run the branch associated with PR #49249. This stack rebuilds how Command Palette ranks and displays results on its main page. Strong text matches now consistently appear above weaker ones. Usage history and provider preferences can improve ordering between similarly relevant results, but they cannot push a poor match above an obvious one. The stack also makes search feel faster. Results appear without waiting for slower providers, app scoring runs more efficiently, and weak matches are hidden while the user has typed only one or two characters. Automated tests protect the new behavior, while privacy conscious telemetry measures performance and relevance without recording searches. ## Pull requests 1. [#49189](https://github.com/microsoft/PowerToys/pull/49189) introduces the new ranking foundation. Results are grouped by match strength, ensuring exact names, prefixes, and acronyms rank above loose fuzzy matches. 2. [#49190](https://github.com/microsoft/PowerToys/pull/49190) improves how Command Palette learns from command usage. Recent and frequently used commands receive a sensible boost, and that history now persists across restarts. 3. [#49191](https://github.com/microsoft/PowerToys/pull/49191) lets users give each provider a Lower, Normal, or Higher search preference. This preference helps resolve close matches without overriding result relevance. 4. [#49194](https://github.com/microsoft/PowerToys/pull/49194) makes the first set of results appear sooner. Commands and apps are shown immediately, while slower fallback results are added when they become available. 5. [#49195](https://github.com/microsoft/PowerToys/pull/49195) adds a comprehensive relevance test suite. It verifies that common searches return the expected results and protects ranking quality from future regressions. 6. [#49197](https://github.com/microsoft/PowerToys/pull/49197) adds privacy conscious search telemetry. It measures result counts, response time, and which result position was selected without recording search text, result names, paths, or other user content. 7. [#49246](https://github.com/microsoft/PowerToys/pull/49246) adds a performance measurement suite. It identifies where search time is spent and provides a reliable way to evaluate performance improvements. 8. [#49247](https://github.com/microsoft/PowerToys/pull/49247) delivers the main performance improvement. App results are scored in parallel and expensive work no longer blocks rendering, while the final result order remains unchanged. 9. [#49249](https://github.com/microsoft/PowerToys/pull/49249) prevents misleading results from flashing when a search begins. For one or two character searches, weak fuzzy app matches remain hidden until the query is specific enough to produce useful results. > [!WARNING] > These PRs should be merged in LIFO order starting with #49249 with this PR being the last. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> |
||
|
Mike Griese
|
15df4db8f2 |
Dock: update the displays list when navigating to dock settings (#49705)
I opened the settings when my laptop was portable. I docked my laptop to my displays. I navigated to the dock settings. I **expected**: to see all my displays I _actually_: saw only the laptop display ------ the fix: make sure to update the displays when we navigate to the dock settings page, so that we properly show all of them Closes: nope didn't file this |
||
|
Boliang Zhang
|
558e633c59 |
Add preview release versioning and update channel support (#49414)
## Summary - Publish scheduled `main` builds as GitHub prereleases while keeping manual `main` runs as preview validation builds. - Add an opt-in Settings switch for prerelease update checks; stable updates remain the default. - Use one MSI-safe version across bundles, MSI packages, binaries, symbols, and package manifests. - Prevent preview releases from triggering Microsoft Store, WinGet, or public-symbol publication. - Label preview builds explicitly in Settings, update notifications, and What's New. ## Build intent | Source | Trigger | Intent | | --- | --- | --- | | `main` | Scheduled | Publish a preview release | | `main` | Manual | Validate a preview build without publishing | | `stable` | Manual | Produce a stable release | | Other branches | Any supported trigger | Produce a private validation build | ## MSI-safe release versioning Windows Installer compares only `major.minor.build` and ignores the fourth version component. Preview and stable release builds therefore use: ```text major.minor.YDDDB.0 ``` - `Y`: zero-based number of calendar years since `ReleaseTrainEpoch`. - `DDD`: three-position calendar day of year. - `B`: daily release sequence `1-9`. - The fourth component is always `0`. With `ReleaseTrainVersion=0.100` and `ReleaseTrainEpoch=2026-01-01`: ```text 0.100.2111.0 = July 30, 2026, release build 1 0.100.3659.0 = December 31, 2026, release build 9 0.100.10011.0 = January 1, 2027, release build 1 ``` The allocator formats `DDD` as exactly three digits before converting the MSI component to its numeric representation. Leading zeros may not be displayed because Windows version components are numeric; decoding remains positional: ```text B = component % 10 DDD = (component / 10) % 1000 Y = component / 10000 ``` `ReleaseTrainVersion` and `ReleaseTrainEpoch` are checked in under `src/Version.props`. The epoch remains January 1 of the active epoch year and advances on the first release-train minor change in a new year. ## Daily release counter Azure DevOps persists the daily sequence server-side using a counter keyed as `release-YYYYMMDD`. - `main` and `stable` share the same daily counter. - Other branches do not evaluate or consume the release counter. - Failed or canceled `main`/`stable` runs may leave gaps. - The build fails when the daily sequence exceeds `9`. - The counter date and encoded `YDDD` date both use `pipeline.startTime`. Private branches retain independent `0.0.<extended-day><NN>.0` validation versions. ## Update behavior - Stable users continue to query GitHub's stable latest-release path. - Users who explicitly enable preview updates can select newer GitHub prereleases. - Preview releases and notifications are labeled as PowerToys Preview. - What's New separates preview entries from stable release history and hides previews by default. ## Validation - 17 Pester tests cover `main`, `stable`, private branches, year rollover, epoch reset, monotonicity, override validation, sequence limits, and date alignment. - Version propagation verified `0.100.2111.0` in `Version.props` and all affected AppX/MSIX manifests. - Azure DevOps pipeline dry-runs succeeded for both `refs/heads/main` and `refs/heads/stable`. - The affected native version project builds successfully. - PR CI is green for x64, ARM64, Command Palette SDK, dependency review, telemetry detection, and CLA. ## Remaining end-to-end checks - Install two locally or officially produced installers with consecutive MSI-visible `YDDDB` versions and verify the upgrade preserves binaries, package registrations, hardlinks, and shell integrations. - On the first natural post-merge `main` or `stable` run, verify the production counter value and resolved version in the release logs. ## Local GPO verification Validated locally with the signed `v0.100.2171` build from Azure DevOps build [153961073](https://microsoft.visualstudio.com/Dart/_build/results?buildId=153961073). These checks cover the administrative-template integration and Settings behavior. ### Policy enabled: preview updates are disabled With `PreviewUpdatesDisabled=1`, **Include prerelease updates** is forced off and locked, and Settings displays the managed-by-your-organization notice.  ### 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 |
||
|
Copilot
|
0126a1aff0 |
Add Desktop Peek to Shortcut Guide Windows shortcuts (#49638)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Shortcut Guide was missing the Windows desktop peek shortcut (`Win + ,`) from the Windows shell shortcuts it displays. This update adds the missing entry and pins it with a focused manifest test. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments - **Shortcut manifest** - Adds `Peek at desktop temporarily` to the Windows shell manifest in the `Windows key` section. - Models the shortcut as `Win + ,`, matching the OS behavior Shortcut Guide should surface. - **Regression coverage** - Adds a focused unit test that deserializes `+WindowsNT.Shell.en-US.yml` and asserts the Desktop Peek entry is present with the expected shortcut payload. ```yml - Name: Peek at desktop temporarily Shortcut: - Win: true Ctrl: false Shift: false Alt: false Keys: - "," ``` <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed - Parsed the updated `+WindowsNT.Shell.en-US.yml` manifest and verified the new entry is present in the `Windows key` section. - Added a manifest-focused unit test covering the new shortcut entry. <!-- START COPILOT CODING AGENT SUFFIX --> - Fixes #49458 --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> |
||
|
Niels Laute
|
581be30101 |
[Mouse Utilities] Clarify Gliding Cursor description (#49691)
## Summary - replace the misleading Gliding Cursor description in PowerToys Settings - clarify that the feature positions the cursor and clicks using only a keyboard shortcut ## Validation - parsed `Resources.resw` as XML - `git diff --check` - Settings UI dependency restore completed; the build could not finish because the D: drive ran out of space Addresses #45598. Copilot-Session: a53b4a7f-26bc-41e1-963a-c80ec33a4b1c |
||
|
Niels Laute
|
286d6e767a |
[Settings] Make attribution links localizable (#49690)
## Summary of the Pull Request Moves Settings attribution link text into localized resources so Turkish and other locales can translate grammatical wording while preserving contributor and product names. Also makes the technical term "Stereolithography" translatable. ## PR Checklist - [x] Closes: #35272 - [x] **Communication:** Requested in #35272 - [x] **Tests:** Resource/XAML-only change; the ARM64 Debug Settings UI build passes - [x] **Localization:** All end-user-facing strings can be localized - [x] **Dev docs:** Not applicable - [x] **New binaries:** Not applicable - [x] **Documentation updated:** Not applicable ## Detailed Description of the Pull Request / Additional comments The affected attribution labels were hard-coded in XAML, preventing the localization pipeline from translating text such as "and other original contributors." Each label now uses an `x:Uid` resource, with translator comments that explicitly identify contributor, product, and file-format names that must remain unchanged. Links containing only a person or product name remain hard-coded. The locked `Stereolithography` resource is also unlocked because it is a translatable technical term rather than a name. ## Validation Steps Performed - Restored and built PowerToys build essentials for ARM64 Debug - Built `src/settings-ui/PowerToys.Settings.slnf` for ARM64 Debug - Validated all attribution `x:Uid` values resolve to unique `.Text` resources Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 98217841-f046-4fe3-a6e0-72046ed9a720 |
||
|
Aryan gupta
|
6fcbde5484 |
[Keyboard Manager] Fix shortcut modifier display order in the new editor (#49707)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Fix shortcut key display order in the new Keyboard Manager editor (C# WinUI). When recording a shortcut, modifier keys are now always displayed in the standard canonical order (Win → Ctrl → Alt → Shift → Action key), regardless of the order the user physically pressed them. This matches the existing behavior of the old C++ editor's `GetKeyVector` function. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #48943 - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments **Bug:** In the new C# KBM editor (`KeyboardManagerEditorUI`), the `GetFormattedKeyList()` method in `KeyboardHookHelper.cs` displayed modifier keys in the order the user pressed them rather than the standard display order. For example, pressing Shift before Win would show `Shift + Win + S` instead of `Win + Shift + S`. **Root cause:** The `modifierKeys` list was populated by iterating `_keyPressOrder` (which preserves temporal press order), and was then rendered directly without sorting. **Fix:** Added a sort step before the display loop that sorts modifier keys using the existing `KeyboardManagerInterop.GetKeyType()` P/Invoke, which returns the `KeyType` enum value (Win=0, Ctrl=1, Alt=2, Shift=3). This enforces the canonical order **Win → Ctrl → Alt → Shift → Action key**, matching the old C++ `EditorHelpers::GetKeyVector()` behavior. **Scope:** Single-line change in `KeyboardHookHelper.GetFormattedKeyList()`. This is a display-only fix — it does not affect the internal key tracking (`_keyPressOrder`), save/load logic, or hook behavior. **Changed file:** - `src/modules/keyboardmanager/KeyboardManagerEditorUI/Helpers/KeyboardHookHelper.cs` <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed 1. Open the new Keyboard Manager editor 2. Click the shortcut trigger button to start recording 3. Press modifier keys in non-standard order (e.g., press Shift first, then Win, then S) 4. **Before fix:** UI shows `Shift + Win + S` 5. **After fix:** UI shows `Win + Shift + S` (correct canonical order) 6. Verified standard-order input (e.g., Win → Shift → S) still displays correctly 7. Verified single modifier + action key shortcuts (e.g., Ctrl+C) display correctly 8. Verified all four modifiers (Win+Ctrl+Alt+Shift+Key) display in correct order regardless of press sequence 9. Verified saving and loading remappings is unaffected by the display change ```` |
||
|
Mike Griese
|
30d070be85 |
CmdPal: fix alt+f4 handling (#49708)
As I threw in https://github.com/microsoft/PowerToys/issues/49572#issuecomment-5195807441: Our alt+f4 handling is wack. We shouldn't close the dock when you press alt+f4 on it, just like you can't close the taskbar with alt+f4. But also some folks want alt+f4 to quit cmdpal, and some folks don't. So there's a setting for what happens when you alt+f4 cmdpal. Closes #38333 Closes #40277 Closes #49572 |
