Merge main into stable for 0.101 release - #49741
Merged
Boliang Zhang (LegendaryBlair) merged 240 commits intoAug 7, 2026
Merged
Merge main into stable for 0.101 release#49741Boliang Zhang (LegendaryBlair) merged 240 commits into
Boliang Zhang (LegendaryBlair) merged 240 commits into
Conversation
## Summary of the Pull Request Adds linked brightness control to PowerDisplay so multiple brightness-capable monitors can be controlled from a single "All Displays" slider. This PR: - Adds a linked brightness mode with one master brightness slider. - Seeds the master slider from the linked display with the lowest Windows DISPLAY number, falling back to monitor ID for determinism. - Persists linked mode enabled/disabled state. - Persists per-monitor exclusions by monitor ID. - Keeps individual display cards available under an expandable section while linked mode is enabled. - Shows linked-state guidance in the link icon tooltip instead of a separate info banner. - Allows excluded displays to keep their own independent brightness slider. - Keeps profiles as per-monitor snapshots; applying a profile turns linked brightness off before applying the profile values. - Adds unit tests for linked-brightness selection/seed behavior and settings compatibility. ## PR Checklist - [x] Closes: microsoft#47319 - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx ## Detailed Description of the Pull Request / Additional comments **Screenshots** | State | Light | Dark | | --- | --- | --- | | Linked mode off | <img width="519" height="817" alt="image" src="https://github.com/user-attachments/assets/bdfae94b-b2e2-4ad3-a45c-7925bb9e5dcd" /> | <img width="520" height="817" alt="image" src="https://github.com/user-attachments/assets/69290a70-0375-480d-957c-c9e0af43d18e" /> | | Linked mode on | <img width="520" height="307" alt="image" src="https://github.com/user-attachments/assets/a2b3572b-e51f-4bdc-9209-23ad2f96d27a" /> | <img width="520" height="307" alt="image" src="https://github.com/user-attachments/assets/8b14b665-b641-4256-a15b-eced82e62728" /> | | Linked mode on — individual displays expanded | <img width="520" height="895" alt="image" src="https://github.com/user-attachments/assets/0b40e60d-e78a-4814-baf6-00be7e283edd" /> | <img width="520" height="895" alt="image" src="https://github.com/user-attachments/assets/4f59bbfa-d6e5-4cb7-af84-cb484f922a7c" /> | The first version is intentionally scoped to brightness-only linked control. Contrast, volume, color temperature, input source, and LightSwitch-specific behavior remain independent. Linked brightness is stored as global PowerDisplay settings: - `linked_levels_active` - `excluded_from_sync_monitor_ids` Newly connected brightness-capable monitors are included by default, because the exclusion list is the explicit exception. Hotplugging a monitor does not immediately write brightness; linked hardware writes happen only after the user changes the master slider. Profiles remain per-monitor snapshots. This PR does not add profile-level linked brightness configuration. If linked brightness is active when a profile is applied, linked mode is turned off first, then the saved per-monitor profile values are applied. That avoids leaving the master linked slider active while hardware brightness has been changed independently per monitor. When linked mode is turned on, the master slider is seeded from the linked brightness-capable display with the lowest Windows DISPLAY number, falling back to monitor ID for determinism. Excluded displays and displays without brightness support are ignored; if no linked target remains, the master slider stays disabled. The seed only positions the slider; it is never written to hardware, so the first user gesture is the first broadcast. ## Validation Steps Performed - Built `PowerDisplay.Lib.UnitTests` Debug x64: ```powershell .\tools\build\build.ps1 -Platform x64 -Configuration Debug -Path src\modules\powerdisplay\PowerDisplay.Lib.UnitTests ``` - Ran `PowerDisplay.Lib.UnitTests` with `vstest.console.exe` - Ran the XAML styling script: ```powershell .\.pipelines\applyXamlStyling.ps1 -Main ``` - Result: the XAML styling script completed successfully and processed `src/modules/powerdisplay/PowerDisplay/PowerDisplayXAML/MainWindow.xaml`.
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request <!-- 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
…icrosoft#48266) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This change adds the [RNNoise](https://github.com/xiph/rnnoise) filter for noise cancellation (audio) and the [Google mediapipe](https://github.com/google-ai-edge/mediapipe/tree/master) `selfie_segmentation_cpu` model for webcam background detection and blurring. It also fixes an issue introduced with ba68b88 causing the ZoomIt shortcuts to fail to register in the standalone version. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments The Settings UI has been extended with a Noise cancellation option, a Background selection for the webcam and a Brightness slider. The functionality for these is added to ZoomIt itself. Also, restored the Mono checkbox which was accidentally masked by b93fd97. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Mario Hewardt <marioh@microsoft.com>
…ock band (microsoft#48514) ## Summary Clicking the clock dock band in the CmdPal Dock now opens the Windows notification center (Action Center). A separate bell-icon-only dock band is also exposed for users who prefer a dedicated notification center shortcut. Closes microsoft#46327 ## Detail - **Clock band left-click**: replaced the previous `NoOpCommand` on `NowDockBand` with `OpenUrlCommand("ms-actioncenter:")`, dismissing the Dock on invoke. The `ms-actioncenter:` URI is the correct shell mechanism - `SendInput` Win+N was tested but dropped because it requires foreground focus, which the Dock holds at click time. - **Notification center band**: new `NotificationCenterDockBand` (`ListItem`) in `TimeDateCommandsProvider.cs`, with a bell icon (`\uEA8F`, Segoe Fluent Icons) and the same `ms-actioncenter:` command. Exposed as a second `WrappedDockItem` from `GetDockBands()` under the id `com.microsoft.cmdpal.timedate.notificationCenterBand`. Users can pin it from the Dock's edit mode. - **New resource strings**: `timedate_show_notification_center_command_name` and `timedate_notification_center_band_title` added to `Resources.resx` / `Resources.Designer.cs`. - **VS 2026 C++ build fixes** (pre-existing failures on `HEAD`): added `_SILENCE_EXPERIMENTAL_COROUTINE_DEPRECATION_WARNINGS` to `CalculatorEngineCommon.vcxproj`. ## Screenshots <img width="339" height="991" alt="image" src="https://github.com/user-attachments/assets/e0ef8c9a-ec1f-40fa-9620-1e83e6aeeb8d" /> ## How tested - Built `Microsoft.CmdPal.UI.csproj` (Debug x64) - 0 errors. - Launched dev `Microsoft.CmdPal.UI.exe`, clicked the clock band - notification center opened correctly. - Right-click context menu on the clock band still shows "Copy time" and "Copy date" unchanged. - Pinned the notification center band via edit mode - bell icon renders icon-only, click opens notification center.
…e excludes (microsoft#48548) ## Summary The `Check Spelling` workflow has been failing on PRs against `main` (e.g. microsoft#48546) due to issues introduced by the recent ZoomIt webcam-blur / noise-cancellation change (microsoft#48266) plus two pre-existing duplicate entries in `.github/actions/spell-check/excludes.txt`. ## What the bot reported | Severity | Type | Location | |---|---|---| | ❌ | `forbidden-pattern` (Should be `a`) | `src/modules/ZoomIt/ZoomIt/rnnoise/kiss_fft.h:79` — third-party kiss_fft header contains `an fft` | |⚠️ | `large-file` (~30 MB) | `src/modules/ZoomIt/ZoomIt/rnnoise/rnnoise_data_little.c` | |⚠️ | `binary-file` | `src/modules/ZoomIt/ZoomIt/selfie_segmentation.onnx` | |⚠️ | `duplicate-pattern` ×2 | `excludes.txt` lines 115/116 duplicate lines 108/109 (`FuzzyMatcher{Comparison,Diacritics}Tests.cs`) | ## Fix `.github/actions/spell-check/excludes.txt`: - **Drop 2 duplicate** `FuzzyMatcher*Tests.cs` lines. - **Add 2 new exclusions** for the new third-party ZoomIt assets: - `^src/modules/ZoomIt/ZoomIt/rnnoise/` — entire third-party rnnoise/kiss_fft tree (covers both the `an fft` forbidden-pattern in `kiss_fft.h` and the 30 MB `rnnoise_data_little.c` large-file). - `^src/modules/ZoomIt/ZoomIt/selfie_segmentation\.onnx$` — the ML model binary. Net change: `-2` duplicates, `+2` new exclusions → file count unchanged at 148 lines. ## Notes - Third-party content under `rnnoise/` should not be spell-checked; this matches how other vendored/third-party trees in the repo are handled (e.g. `src/common/CalculatorEngineCommon/exprtk.hpp`, `src/common/sysinternals/Eula/`). - No source code changes; pure config. - Unblocks microsoft#48546 and any other PR currently failing `Check Spelling` on `main`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Updated the DiskAnalyzer plugin link and author information to point to the ValleySoft organization repository instead of my personal account. ## Summary of the Pull Request Documentation-only change. Updates the DiskAnalyzer entry in `thirdPartyRunPlugins.md`: - Plugin URL: `thetsaw/PowerToys.Plugin` → `valley-soft/powertoys-diskanalyzer` - Author: `thetsaw` → `ValleySoft` ## PR Checklist - [ ] Closes: N/A - [x] **Communication:** This is a minor doc-only update to correct a repo link — no prior discussion needed - [x] **Tests:** N/A — documentation change only - [x] **Localization:** N/A — no user-facing strings changed - [x] **Dev docs:** Updated `doc/thirdPartyRunPlugins.md` - [ ] **New binaries:** N/A ## Detailed Description of the Pull Request / Additional comments The DiskAnalyzer PowerToys Run plugin was originally submitted under my personal GitHub account (`thetsaw`). The project has since been moved to the official **ValleySoft** organization at: https://github.com/valley-soft/powertoys-diskanalyzer ## Validation Steps Performed Verified all URLs are live and resolve correctly: - https://github.com/valley-soft/powertoys-diskanalyzer ✅ - https://github.com/valley-soft ✅
…microsoft#48628) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Power Display could put a monitor to sleep but never wake it back up. Selecting **On** in the per-monitor power-state list was a hard-coded no-op, so the DDC/CI wake command (VCP `0xD6` = `0x01`) was never sent. This removes that guard so selecting **On** wakes the display, and cleans up the dead code/comment left behind by the original one-directional design. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: microsoft#48428 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments `MonitorViewModel.HandlePowerStateSelectionChanged` early-returned when the selected power state was **On** (`0x01`), so `SetPowerStateAsync` was never called for On and the wake write never reached the monitor. As a result Power Display's power control was one-directional: it could send Standby/Suspend/Off but could never turn a monitor back on. The guard dates back to the very first power-state commit and was paired with a single-monitor assumption — *"the monitor must be on to see the UI"*, so On was treated as the always-current state and skipped. A later change made the selection reflect the monitor's real power state (so a monitor in the list can legitimately be asleep), and multi-monitor support means the flyout can be shown on monitor A while the user wants to wake monitor B. Those changes invalidated the assumption, but the action-side guard survived a subsequent refactor. The lower layers already do the right thing: `MonitorManager.SetPowerStateAsync` → `DdcCiController.SetPowerStateAsync` → `SetVcpFeatureAsync(monitor, 0xD6, value)` passes the value through unchanged, so the fix is purely removing the UI-layer guard. DDC/CI stays reachable while the panel is in Standby/Suspend/Off(DPM), so writing `0x01` turns it back on (this is the same mechanism Twinkle Tray uses). `Off (Hard)` / `0x05` may still require a physical wake on some monitors, since that state can cut the DDC command channel. Cleanup included in this PR: - Removed the now-unused `PowerStateItem.PowerStateOn` constant (its only consumer was the deleted guard). - Removed the dead `SetPowerState` `[RelayCommand]` (the generated `SetPowerStateCommand` had zero references — the XAML wires `SelectionChanged`, not a command). - Updated the `SetPowerStateAsync` doc comment from the one-directional framing to a neutral bidirectional description. Net change: 2 files, +5 / −24. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed - **Build:** `MSBuild PowerDisplay.csproj -p:Platform=x64 -p:Configuration=Debug` (CoreCompile) — **0 errors / 0 warnings**. - **Static check:** repo-wide grep confirms no remaining references to `PowerStateOn` or `SetPowerStateCommand`; the power-state ListView binds only `ItemsSource` + `SelectionChanged` (no `SelectedItem` binding), so opening the flyout cannot spuriously re-fire a selection. - **Manual (requires a DDC/CI monitor):** enable *Power state control* for a monitor → open its flyout and select **Standby** or **Off (DPM)** (screen blanks) → reopen the flyout and select **On** → the display wakes. No automated test was added: with the guard removed the handler is an unconditional pass-through (identical in shape to `HandleInputSourceSelectionChanged`), and it is an `async void` WinUI event handler over real DDC/CI hardware, which is outside the `PowerDisplay.Lib` unit-test seam. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Summary Upgrades the centrally-managed Windows App SDK package versions to the **2.2.0 stable** umbrella released on NuGet. | Package | Before | After | |---|---|---| | `Microsoft.WindowsAppSDK` | 2.0.1 | **2.2.0** | | `Microsoft.WindowsAppSDK.Foundation` | 2.0.20 | **2.1.0** | | `Microsoft.WindowsAppSDK.AI` | 2.0.185 | **2.2.3** | | `Microsoft.WindowsAppSDK.Runtime` | 2.0.1 | **2.2.0** | Foundation/AI/Runtime versions match the dependency graph declared by `Microsoft.WindowsAppSDK` `2.2.0`'s own nuspec (`Foundation=2.1.0`, `AI=2.2.3`, `Runtime=[2.2.0]`), so transitive resolution is exact and no version-conflict warnings are introduced. Also bumps the CmdPal `ExtensionTemplate` sample's local `Directory.Packages.props` so the template stays in sync with the main repo. ## Files changed - `Directory.Packages.props` - `src/modules/cmdpal/ExtensionTemplate/TemplateCmdPalExtension/Directory.Packages.props` ## Validation Ran `tools/build/build-essentials.cmd` on a clean `origin/main` worktree: - `msbuild PowerToys.slnx /t:restore /p:RestorePackagesConfig=true` — **Build succeeded, 0 warnings, 0 errors** (00:02:50) - `src/runner/runner.vcxproj` (x64 Debug) — **Build succeeded, 0 warnings, 0 errors** (00:04:15) - `src/settings-ui/Settings.UI/PowerToys.Settings.csproj` (x64 Debug) — **Build succeeded, 0 warnings, 0 errors** (00:03:14) Full module test suite has **not** been run yet — this PR only certifies the build-essentials baseline. CI will exercise the wider build/test matrix. ## Notes - This is an atomic packaging-only change. No source code touched, no behavior changes. - If WinAppSDK 2.2.0 surfaces any runtime regression downstream, it can be reverted as a single commit. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary Add `docs/superpowers/` to `.gitignore` so all locally generated superpowers artifacts (specs, design docs, and plans) are not committed. These files are produced by local AI tooling and are workspace-local only; they should not land in the repository. ## Change ```gitignore # Superpowers-generated docs (specs, design, plans) — local-only, not committed docs/superpowers/ ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
It was a race condition.
…OWN (microsoft#47192) ## Summary of the Pull Request When a modifier key (Ctrl/Alt/Shift) is remapped to a non-modifier key using Keyboard Manager, the injected key event is delivered to applications as WM_SYSKEYDOWN instead of WM_KEYDOWN. This causes unexpected behavior — for example, remapping Left Alt to Backspace results in whole words being deleted instead of single characters, because applications interpret WM_SYSKEYDOWN + VK_BACK as Alt+Backspace. The fix resets the modifier state with a suppress-flag key-up event before injecting the target key, consistent with the existing approach used for the Caps Lock remapping scenario. ## PR Checklist - [ ] Closes: microsoft#47191 - [ ] Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] Tests: Added/updated and all pass - [ ] Localization: All end-user-facing strings can be localized - [ ] Dev docs: Added/updated - [ ] New binaries: Added on the required places ## Detailed Description of the Pull Request / Additional comments The root cause is that SendInput is called inside the low-level keyboard hook callback before the original modifier event is suppressed. At that point the modifier state is still active, so the OS delivers the injected key as WM_SYSKEYDOWN (system key with Alt context) rather than WM_KEYDOWN. This is the same mechanism that was already fixed for the Ctrl/Alt/Shift ↔ Caps Lock case. This PR extends the fix to cover modifier → non-modifier remaps. ## Validation Steps Performed 1. Remapped Left Alt → Backspace in Keyboard Manager 2. Opened a text editor, typed text, pressed the remapped key 3. Confirmed single characters are deleted instead of whole words 4. All 93 unit tests pass (KeyboardManager.Engine.UnitTests)
…osoft#46688) ## Summary Addresses the **root cause chain** behind the NullReferenceException crash in Settings navigation. Crash dump analysis with WinDbg revealed that `Frame.Navigate()` can throw native WinUI ABI exceptions that propagate unhandled through multiple code paths. ### Changes (3 files) **NavigationService.cs** — Defensive try-catch for all `Frame.Navigate()` call sites: - `Navigate()`: Wrap in try-catch, log via `Logger.LogError()`, return `false` on failure - `EnsurePageIsSelected()`: Add matching try-catch for consistency (also calls `Frame.Navigate()` unprotected) - Protects **all** navigation in the Settings app **ShellViewModel.cs** — Fix the crash-causing `Frame_NavigationFailed` handler: - Replace `throw e.Exception` with `e.Handled = true` + `Logger.LogError()` - The original code threw `NullReferenceException` when `e.Exception` was null (native WinUI errors don't always marshal to managed Exception objects) - Mark the event as handled to prevent framework error propagation **ShellPage.xaml.cs** — Protect `async void SearchBox_QuerySubmitted`: - Wrap entire method body in try-catch - `async void` methods that throw after `await` produce unhandled exceptions that crash the process - Covers both search indexing (`Task.Run`) and navigation failures ### Crash Dump Evidence Analysis of `PowerToys.Settings_2025_03_26_48636.dmp` with WinDbg: - 4 stowed exception records found at `0x000001c60d3b9100` - Exception chain: `SearchBox_QuerySubmitted` → `Frame.Navigate()` fails at native ABI → `NavigationFailed` fires with null Exception → `throw null` → `NullReferenceException` → `FailFastWithStowedExceptions` - Root failure in `Microsoft.UI.Xaml.dll!DirectUI::Frame::Navigate` ### Review Notes - `catch (Exception)` pattern matches 92.5% of Settings.UI codebase convention - `Logger.LogError()` with `using ManagedCommon` matches standard import pattern - No security concerns: logged page type names are not sensitive data - Build verified locally (38/38 applicable tests pass; 111 COM-dependent tests fail identically on main) Co-authored-by: Tucker Burns <tuck.burns@gmail.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… item (microsoft#47043) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: microsoft#46464 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…osoft#48457) ## Summary Adds the two missing top-level exception handlers in the QuickAccess (Preview) flyout host so that an unhandled XAML exception during launch or page navigation no longer FailFasts `PowerToys.QuickAccess.exe`. Spotted while reading through `App.OnLaunched` and `ShellPage` for an unrelated review of the flyout startup path — none of the existing handlers exist yet, so any throw during `MainWindow` construction, `ShellHost.Initialize`, or `ContentFrame.Navigate(typeof(LaunchPage) | typeof(AppsListPage), …)` bubbles all the way out to the Windows App SDK runtime and is stowed as a XAML failure. Compare with `src\settings-ui\Settings.UI\SettingsXAML\App.xaml.cs`, which already wires `UnhandledException += App_UnhandledException`. ## Changes **`src\settings-ui\QuickAccess.UI\QuickAccessXAML\App.xaml.cs`** - Hook `Application.UnhandledException` in the constructor. The handler logs the exception via `ManagedCommon.Logger.LogError` (same logger Settings uses) and sets `e.Handled = true`. QuickAccess is a transient launcher flyout owned by the runner, so swallowing a stray XAML error and keeping the host alive for the next summon is the correct trade-off — the failure is still recorded for diagnostics. - Wrap the body of `OnLaunched` in a try/catch. If `MainWindow` (which sets up window chrome, listener threads, the IPC coordinator, and the XAML shell) fails to construct, log the exception and call `Exit()` cleanly rather than letting the throw escape into the Windows App SDK launch path. **`src\settings-ui\QuickAccess.UI\QuickAccessXAML\Flyout\ShellPage.xaml.cs`** - Subscribe to `ContentFrame.NavigationFailed` after `InitializeComponent`. A page constructor or XAML-load failure in `LaunchPage` / `AppsListPage` would otherwise bubble out of the `Frame` and crash the launcher. The handler logs the failure (`SourcePageType.FullName` + the exception) and marks it handled so the next summon retries navigation. No production behaviour changes when things work — only the failure paths are different. No public API surface changes. ## Why both handlers, not just one - `Application.UnhandledException` does not fire for `Frame.NavigationFailed`. The Frame raises its own event first and, if no handler runs or `e.Handled` is left `false`, then it rethrows on the dispatcher. - Conversely, `Frame.NavigationFailed` only fires for navigation failures — not for an exception thrown directly in `OnLaunched` before any navigation happens. The two events are complementary, so both need a handler to fully cover the launch + navigation paths. ## Testing - The local NuGet feed on my dev box currently can't restore `Microsoft.NETCore.App.Runtime.win-x64 = 10.0.9` (the feed only has `11.0.0-preview.1.26104.118`), which fails the project restore for every WinUI project including this one. That's the same environment issue I called out on microsoft#48414 — pipeline restore uses a different feed and is fine. - All three patterns added here are copy-paste analogues of code that already exists in `Settings.UI` (`App.xaml.cs:96, 106-109`, `ShellViewModel.cs:86, 136`), so namespace and signature drift risk is minimal. The only behavioural difference is `e.Handled = true`, which is the actual goal of this PR. ## Risk - Low. Two new event handlers and one try/catch. No behaviour change on the success path. - Worst-case regression is that a real, repeatable XAML failure becomes silent in the runner's eyes (no process crash) instead of loud — but it's logged via `Logger.LogError` so the user can still find the trace in `%LOCALAPPDATA%\Microsoft\PowerToys\Logs\`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- ADO: https://microsoft.visualstudio.com/DefaultCollection/OS/_workitems/edit/61258633/ --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…oad and Battery strings (microsoft#48649) ## Summary Adds translation guidance comments to English .resx resource strings that have incorrect Japanese translations in the CDPX localization pipeline. ## Problem - **Download/Downloading** — translated as 受け取り (implies physical package receipt) instead of the correct IT term 受信 - **Battery** (laptop/tablet context) — translated as 電池 (dry cell) instead of バッテリー (built-in battery) ## Fix Added comment elements to 9 resource entries across 3 files with the prefix JA: to guide the localization team: | File | Strings | Comment | |------|---------|---------| | Microsoft.CmdPal.Ext.WinGet\Properties\Resources.resx | winget_downloading, winget_download_progress | JA: translate as 受信 not 受け取り | | Microsoft.CmdPal.UI.ViewModels\Properties\Resources.resx | winget_operation_status_downloading, winget_operation_status_downloading_percent, gallery_item_winget_action_downloading_with_progress, gallery_item_winget_action_downloading | JA: translate as 受信 not 受け取り | | Microsoft.CmdPal.Ext.WindowsSettings\Properties\Resources.resx | BatterySaver, BatterySaverSettings, BatteryUse | JA: translate as バッテリー not 電池 | ## Background As documented in doc/devdocs/development/localization.md, localized .resx files are generated at build time by the CDPX pipeline from .lcl files managed by the internal localization team. The comment elements in English .resx files are surfaced to translators and are the correct mechanism for providing translation guidance. The actual .lcl file fixes must be applied by the internal team. Closes microsoft#48598
…ibernate (microsoft#48534) (microsoft#48653) ## Summary Fixes incorrect Chinese translation where both Sleep and Hibernate commands showed '休眠' (hibernation) instead of using distinct terms: '睡眠' for Sleep and '休眠' for Hibernate. ## Changes Added \<comment>\ elements with \ZH:\ guidance to 6 resource entries in \Microsoft.CmdPal.Ext.System\\Properties\\Resources.resx\: | Resource Key | Current Comment | Added ZH Guidance | |---|---|---| | \Microsoft_plugin_command_name_hibernate\ | *(none)* | translate as '休眠' | | \Microsoft_plugin_sys_hibernate\ | Existing English comment | use 休眠 not 睡眠 | | \Microsoft_plugin_sys_hibernate_confirmation\ | Existing English comment | use 休眠 not 睡眠 | | \Microsoft_plugin_command_name_sleep\ | *(none)* | translate as '睡眠', do NOT use '休眠' | | \Microsoft_plugin_sys_sleep\ | Existing English comment | use 睡眠 not 休眠 | | \Microsoft_plugin_sys_sleep_confirmation\ | Existing English comment | use 睡眠 not 休眠 | ## Why comments only? Chinese translations are managed by the internal CDPX localization pipeline. Adding \<comment>\ elements to the English \.resx\ file is the standard way to guide translators for the next localization pass. See similar fix in PR microsoft#48649 for Japanese translation guidance.
…t#46028) Adds a `SettingsManager` scaffold to the CmdPal extension template so new extensions have a ready-to-use settings pattern out of the box. ## Summary of the Pull Request Most extensions need configuration. The template previously had no settings infrastructure, leaving developers to discover the pattern from built-in extensions. This adds a wired-up `SettingsManager` following the same conventions used across all built-in extensions. ## PR Checklist - [ ] Closes: #xxx - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx ## Detailed Description of the Pull Request / Additional comments **`Helpers/SettingsManager.cs`** (new) - Extends `JsonSettingsManager` (already bundled in `Microsoft.CommandPalette.Extensions`) - Uses `Utilities.BaseSettingsPath()` for correct local-state path (packaged and unpackaged) - Includes commented-out `ToggleSetting` example illustrating the full add/register/expose cycle - Auto-saves via `Settings.SettingsChanged` event **`TemplateCmdPalExtensionCommandsProvider.cs`** (updated) - Instantiates `SettingsManager` as a field - Sets `Settings = _settingsManager.Settings` to advertise settings to CmdPal - Exposes `_settingsManager.Settings.SettingsPage` in `MoreCommands` for in-app settings access ```csharp // Helpers/SettingsManager.cs internal sealed partial class SettingsManager : JsonSettingsManager { private static readonly string _namespace = "templatecmdpalextension"; private static string Namespaced(string propertyName) => $"{_namespace}.{propertyName}"; // TODO: Add your settings here. For example: // private readonly ToggleSetting _myToggle = new( // Namespaced(nameof(MyToggle)), "My toggle setting", "Description", false); // public bool MyToggle => _myToggle.Value; public SettingsManager() { FilePath = SettingsJsonPath(); // Settings.Add(_myToggle); LoadSettings(); Settings.SettingsChanged += (_, _) => SaveSettings(); } } // TemplateCmdPalExtensionCommandsProvider.cs private readonly SettingsManager _settingsManager = new(); public TemplateCmdPalExtensionCommandsProvider() { // ... _commands = [ new CommandItem(new TemplateCmdPalExtensionPage()) { Title = DisplayName, MoreCommands = [new CommandContextItem(_settingsManager.Settings.SettingsPage)], }, ]; Settings = _settingsManager.Settings; } ``` The template wizard replaces `"TemplateCmdPalExtension"` throughout all files, so `BaseSettingsPath` and the namespace string will update automatically when scaffolding a new extension. ## Validation Steps Performed - Verified `SettingsManager` pattern matches existing built-in extensions (`ClipboardHistory`, `System`, `Registry`) - No new package references required — `JsonSettingsManager`, `ToggleSetting`, and `Utilities` are all included in the existing `Microsoft.CommandPalette.Extensions` NuGet package <!-- START COPILOT ORIGINAL PROMPT --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>CmdPal: Include basic SettingsManager in Template</issue_title> > <issue_description>### Description of the new feature / enhancement > > Include basic `SettingsManager` in template. > > ### Scenario when this would be used? > > I believe most extensions will require some form of configuration, so adding basic `SettingsManager` would be helpful. > > ### Supporting information > > _No response_</issue_description> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > </comments> > </details> <!-- START COPILOT CODING AGENT SUFFIX --> - Fixes microsoft#39274 <!-- START COPILOT CODING AGENT TIPS --> --- 🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. [Learn more about Advanced Security.](https://gh.io/cca-advanced-security) --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: niels9001 <9866362+niels9001@users.noreply.github.com> Co-authored-by: Muyuan Li (from Dev Box) <muyuanli@microsoft.com>
This pull request updates the auto-labeling workflow to support both issues and pull requests, improves clarity in logs and prompts, and renames the workflow file for broader applicability. The changes enhance automation for triaging by enabling area label assignment to new or updated pull requests in addition to issues. **Expanded triage coverage and workflow improvements:** * The workflow now triggers on both issue and pull request events (`opened`, `reopened`, `edited`, `synchronize`), allowing automatic area labeling for pull requests as well as issues. (`.github/workflows/auto-labeler.yml`, [.github/workflows/auto-labeler.ymlL1-R7](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL1-R7)) * The concurrency group logic has been updated to handle pull request events separately from issues, ensuring that rapid updates to a PR or issue are managed correctly. (`.github/workflows/auto-labeler.yml`, [.github/workflows/auto-labeler.ymlR24-R26](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eR24-R26)) **User experience and clarity enhancements:** * Console logs and prompt messages now refer generically to "item" or distinguish between "Issue" and "Pull request" as appropriate, improving clarity in workflow output and AI prompts. (`.github/workflows/auto-labeler.yml`, [[1]](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL41-R44) [[2]](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL58-R79) [[3]](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL139-R146) [[4]](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL212-R217) * The system prompt for the AI labeling assistant has been updated to clarify that both issues and pull requests should be classified and labeled. (`.github/workflows/auto-labeler.yml`, [.github/workflows/auto-labeler.ymlL127-R133](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL127-R133)) **File naming:** * The workflow file has been renamed from `.github/workflows/auto-label-issues.yml` to `.github/workflows/auto-labeler.yml` to reflect its broader scope. (`.github/workflows/auto-labeler.yml`, [.github/workflows/auto-labeler.ymlL1-R7](diffhunk://#diff-f874b1d773361dc46f2496bc3ce97ee3441e91257188b27a2bd83693c3b8a82eL1-R7))
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Fixes some typos and grammar mistakes inside docs, strings, and comments. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed None --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
## Summary of the Pull Request Gives the CmdPal toast notification a glow-up: it now slides in/out with a nice fade, has acrylic + a soft shadow, and stops fighting with `SizeToContent`. Along the way, the toast guts got refactored into a couple of reusable bits that live in `PowerToys.Common.UI.Controls` so other PowerToys utilities can grab them for their own transient overlays: - **`TransparentWindow`** — a `WindowEx`-derived host that strips the native frame, hides from taskbar/Alt-Tab, uses `TransparentTintBackdrop` for transparency, and runs show/hide implicit animations on its content. Supply your own animations via `ShowAnimations` / `HideAnimations`, or take the defaults (fade + slide). - **`TransparentCard`** — a templated `ContentControl` with acrylic (`AlwaysActiveDesktopAcrylicBackdrop`), rounded corners, border, and shadow. Drop whatever XAML you want inside. - **`AlwaysActiveDesktopAcrylicBackdrop`** — small `SystemBackdrop` wrapper so the acrylic doesn''t go grey when the window isn''t focused (transient overlays are never focused). CmdPal''s `ToastWindow` is now basically a 16-line wrapper: derives from `TransparentWindow`, drops a bound `TextBlock` inside, and handles its own 2.5s auto-hide timer + bottom-center positioning. https://github.com/user-attachments/assets/3a62080c-22f0-480c-ac4d-028bcc32f07d ## PR Checklist - [x] Closes: microsoft#40886 - [x] **Communication:** I''ve discussed this with core contributors already. - [ ] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places ## Detailed Description of the Pull Request / Additional comments A couple of design notes worth calling out: - The window is sized slightly bigger than the visible card (~24px breathing room on each side) so the shadow and slide animation have room to render without clipping. That buffer area is transparent but NOT click-through — kept it small on purpose. We explored `SetWindowRgn` and `EnableWindow` tricks to make it click-through too, but neither plays nicely with WinUI 3''s DesktopWindowXamlSource. Small transparent frame is the pragmatic compromise. - Animations use the Toolkit''s implicit `ShowAnimations` / `HideAnimations` so there''s zero animation code in `ToastWindow.xaml.cs`. - `TransparentCard.xaml` is registered in `Themes/Generic.xaml` — required for templated controls in a library project; `<GenerateLibraryLayout>` alone doesn''t auto-merge per-control xaml. ## Validation Steps Performed - Built clean (arm64 Debug). - Triggered a CmdPal toast manually: fades + slides in, hangs for 2.5s, fades + slides out. - Acrylic stays active when the window isn''t focused (toasts are never focused). - Shadow renders fully without clipping. --------- Co-authored-by: niels9001 <niels9001@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Regressed in one of the last two releases. The problem was that `history.ToImmutableList()` ran on the projected `IVector<string>`. `ImmutableList.CreateRange` checks for `IReadOnlyCollection<string>`, and resolving that interface on a WinRT object requires a helper type that AOT can't generate. So we have to just _not do that_. Closes microsoft#48445
…48689) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Changed the icon from the sleep icon to the hibernate icon, which fixes the issue in microsoft#48535 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: microsoft#48535 ## Detailed Description of the Pull Request / Additional comments The icon was previously the sleep icon, and I have changed it to the hibernate icon. ## Validation Steps Performed I have visually checked that the icon is now updated to the correct icon.
This pull request makes minor adjustments to the `.github/workflows/auto-labeler.yml` GitHub Actions workflow, focusing on permissions and event triggers. Workflow configuration updates: * Added `pull-requests: write` permission to the workflow to ensure it has the necessary access for managing pull requests. * Removed the `edited` event from the list of triggers for `pull_request_target`, so the workflow will no longer run when a pull request is edited.
…rosoft#48682) This PR fixes Issue microsoft#48680 where the CmdPal dock performance meter shows '???' after restart. **Root cause**: The PerformanceWidgetsPage initially returns items with a placeholder title ('???') because ContentData hasn't loaded yet. The DataManager timer starts when the dock subscribes to ItemsChanged, and the Updated event fires 1 second later with real data. However, the Updated event handlers were updating ListItem.Title directly without calling RaiseItemsChanged() on the page, so the dock was never notified that the items had changed and continued to display the stale '???' title. **Fix**: Added a RaiseItemsChanged() call to each of the 5 Updated event handlers (CPU, Memory, Network, GPU, Battery) after the item titles are updated. This causes the dock to re-call GetItems() and refresh the displayed titles. Fixes microsoft#48680
This is a totally minor nitpick. I don't have the dock enabled on all my displays. But the current "pin to dock" dialog lets me pin it to a display I don't have the dock on. When that happens, it effectively results in _nothing_ happening. Not great. This PR mitigates that situation, but only listing the enabled docks when pinning.
This pull request updates the `auto-labeler.yml` GitHub Actions workflow to improve reliability and maintain compatibility. The most important changes are an upgrade to the `actions/github-script` version and improved error handling when applying labels, ensuring the workflow does not fail due to restricted permissions. **Dependency upgrade:** * Upgraded `actions/github-script` from version 7 to version 9 in the `Apply area labels with AI` step, ensuring continued support and access to the latest features and security updates. **Error handling improvements:** * Added a `try/catch` block around the label application logic to gracefully handle cases where the workflow lacks permission to write labels (e.g., due to restricted integration tokens), logging a message and skipping the operation instead of failing the entire workflow.
This pull request introduces a new, automated workflow for building and publishing the developer documentation website using [docmd](https://docmd.io/). The static site is now generated from `doc/devdocs`, built in the `doc/devdocs-website` folder, and deployed to GitHub Pages via a GitHub Actions workflow. The build output is not committed to the repository but is instead published as an artifact. Supporting configuration files, documentation, and `.gitignore` entries are also added to streamline local development and CI/CD. **Automated build and deployment:** * Added `.github/workflows/regenerate-devdocs-website.yml` to build the static site with docmd and deploy it to GitHub Pages automatically on changes to `doc/devdocs` or `doc/devdocs-website`, or via manual trigger. **Project setup and configuration:** * Added `doc/devdocs-website/package.json` to define the Node.js project, pin the docmd version, and provide scripts for local development and builds. * Added `doc/devdocs-website/docmd.config.json` to configure docmd (site title, source, output directory, base path). * Added `doc/devdocs-website/.npmrc` to disable lockfile generation, ensuring fresh dependency installs each build. **Documentation and housekeeping:** * Added `doc/devdocs-website/README.md` with instructions for editing, building, and publishing the docs website. * Added `doc/devdocs-website/.gitignore` to exclude the generated `site/` output from version control.
This pull request adds a custom `docmd` plugin to improve how documentation links to source files are handled, ensuring that repo-root-relative links work both when editing locally and on the published site. The main changes include introducing the new plugin, updating configuration to use it, and documenting its behavior. **Plugin integration and configuration:** * Added a new local plugin `github-source-links` in `docmd-plugins/`, which rewrites repo-root-relative links (e.g., `/src/.../Foo.cpp`) in Markdown files to absolute GitHub blob URLs during the documentation build process, ensuring links remain functional on the published site. [[1]](diffhunk://#diff-c2c746e6974a6cfdd229031c2977f2bb0dca37c6d5f598ed45dc0d9f0b74c7caR1-R52) [[2]](diffhunk://#diff-a97f3ce59c97313aacd716b9874b445d162c45ee2e6ef9fd2db59fe17235e1cfR1-R8) * Updated `docmd.config.json` to register the new plugin under the `plugins` key, enabling it for documentation builds. * Updated `package.json` to include the plugin as a dependency, referencing the local plugin directory. **Documentation updates:** * Updated `README.md` to document the new `docmd-plugins/` folder, explain the purpose of repo-root-relative links, and describe how the plugin rewrites these links for the published site.
…default (microsoft#48474) ## Summary Refines the **Grab and Move** drag/resize overlay so it matches the polish of **Always on Top (AoT)**, and lowers the AoT default border thickness. Created at the request of @crutkas. Two related border-refinement changes, kept in one PR because the Grab and Move "double layer" is designed around AoT's border. https://github.com/user-attachments/assets/0b605f92-60bd-44a0-a540-70e6d425146a ### 1. Always on Top - default border thickness 15 -> 4 The default highlight border was `15px`, which is visually heavy. Dropped to `4px` for a tighter, Fluent-style frame. - `src/modules/alwaysontop/AlwaysOnTop/Settings.h` (C++ default) - `src/settings-ui/Settings.UI.Library/AlwaysOnTopProperties.cs` (`DefaultFrameThickness`) - Existing users keep their configured value; only fresh installs / "reset" pick up `4`. Slider range (1-30) is unchanged. ### 2. Grab and Move - tight, warning-gold overlay (fill + border) Previously the overlay was a full translucent **white wash** sized to `GetWindowRect`, which includes the invisible resize-border / shadow margins (~7px) - so it sat *off* the visible window. It now hugs the visible frame, mirroring AoT: - **Keeps the translucent white wash** over the visible window (the familiar "grabbed" feedback) and adds a tight **warning-gold border on top**. Both hug the visible frame and are rounded to match the window corners. - **Tight geometry:** anchored to `DWMWA_EXTENDED_FRAME_BOUNDS` (inset by the invisible-border margins) instead of `GetWindowRect`. - **Corner detection:** matches the window's corner radius via `DWMWA_WINDOW_CORNER_PREFERENCE` (same mapping AoT uses); border thickness and radius scale with the target window DPI. - **Distinct accent:** Fluent **warning gold `#FFB900`** - the literal equivalent of WinUI [`SystemFillColorCaution`](https://learn.microsoft.com/en-us/windows/apps/design/style/color) (used as a `ThemeResource` for warnings across the Settings UI; a Win32 layered window can't resolve a `ThemeResource`, so a literal is required). Keeps Grab and Move visually distinct from AoT's accent-blue. - **Double layer, for free:** the Grab and Move border is drawn just **inside** the visible edge, while AoT draws its border just **outside** the visible edge. The two naturally stack into a clean double layer, so Grab and Move stays a constant **4px** with no AoT detection / window enumeration. Rendering keeps the existing GDI + `UpdateLayeredWindow` per-pixel-alpha path and adds **GDI+** (a Windows system library - no new third-party dependency) for the antialiased, rounded fill and border. Frame metrics are computed **once per drag/resize** (never in the mouse-move hot path). The optional geometry label is unchanged. ## Before / After | | Before | After | |---|---|---| | Grab and Move overlay | Full white wash, offset from the window edge | Same wash, now tight to the visible frame + gold border, corner-matched | | AoT default border | 15px | 4px | | AoT + Grab and Move together | white wash over AoT border | GM gold inside the edge + AoT accent outside it = double layer | ## Validation - Builds clean (exit 0, 0 warnings/errors) for **x64 Debug**: `GrabAndMove`, `AlwaysOnTop`, and `Settings.UI.Library` (Code Analysis / C26451 clean). - Smoke-tested live by running the standalone module exes: tight gold border + wash on Alt-drag / Alt-right-drag, AoT 4px border, and the inside/outside double layer on a pinned window. - WARNING: still **draft** pending broader visual validation (border tightness across DPIs, the exact gold, rounded vs square corners, AoT z-order during fast drags - AoT renders from a separate process and follows on a ~100ms timer). Screenshots to be added. ## Follow-up (not in this PR) AoT and Grab and Move remain **separate** overlay systems (AoT: persistent per-window Direct2D border; Grab and Move: transient GDI/`UpdateLayeredWindow` overlay). They can't share one runtime window, but the frame-geometry + corner-detection + DPI helpers are worth extracting into `src/common` (seeded by AoT's `WindowCornersUtil`/`ScalingUtils`). Tracked separately to keep this PR atomic (`src/common` is an ABI-careful area). ## Notes - No IPC/JSON schema changes; no new settings. - No new third-party dependencies (GDI+ is a system library). --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [X] Closes: microsoft#48443 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments The PR modifies the `CharacterMappings.cs` file by adding the Philippine peso symbol to the symbols for the "P" key under the Currency group. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed No validation steps were performed as I assume this would not create any breaking changes.
## Summary of the Pull Request Adds a Shortcut Guide manifest for **Greenshot**. - **New manifest:** `src/modules/ShortcutGuide/ShortcutGuide.Ui/Assets/ShortcutGuide/Manifests/Greenshot.Greenshot.en-US.yml`: 32 shortcuts for `Greenshot.exe`, grouped into five sections: * **Capture:** Capture region, Capture last region, Capture window, Capture fullscreen, Capture Internet Explorer tab * **While selecting a region:** switch region/window mode, select a child window element, toggle magnifier, confirm selection, cancel capture * **Editor - draw:** rectangle/ellipse/line/arrow/freehand/highlight/obfuscate/crop/text/selection tools, enlarge screenshot, crop to visible elements, paste image from clipboard * **Editor - text:** insert line break, delete previous word, select all text, finish editing * **Editor - export:** save, save as, copy image to clipboard, print, e-mail - **No code changes.** The manifest is auto-included via the existing `Manifests/*.yml` glob in `ShortcutGuide.Ui.csproj`. - `BackgroundProcess: true`, matching the bundled PowerToys-itself manifest, since Greenshot's core value is its global capture hotkeys, which work regardless of the currently focused window. - Introduces a `<PrtScn>` token for the Print Screen key (not previously needed by any bundled manifest, since Greenshot's capture shortcuts are all built around it) alongside the existing `<Space>`, `<Enter>`, `<Esc>`, `<Backspace>`, `<PageDown>` named-key tokens. ## PR Checklist - [ ] **Closes:** #ISSUE_NUMBER - [ ] **Communication:** discussed in the linked issue - [ ] **Tests:** N/A for data; relies on the existing manifest deserialization path - [x] **Localization:** all end-user-facing strings can be localized - [ ] **Dev docs:** N/A, no schema changes - [ ] **New binaries:** N/A - [ ] **Documentation updated:** N/A - [x] **Local run:** see issue screenshot ## Detailed Description of the Pull Request / Additional comments The Shortcut Guide displays per-app shortcuts from YAML manifests, matched to the foreground window (or shown continuously for background processes) via `WindowFilter`/`BackgroundProcess`. Adding support for an app is purely additive: drop a `<PackageName>.<locale>.yml` file in the `Manifests` folder and it's picked up by the existing build glob and index generator. - `PackageName: Greenshot.Greenshot` is the WinGet package identifier; `WindowFilter: "Greenshot.exe"` is the process name (confirmed against a signed 1.3.315 build). - `Name: Greenshot` is the display name shown in the Shortcut Guide app picker. - Shortcut names follow the repo's sentence-case convention (capitalize only the first word plus proper nouns/product names). - Five shortcuts are marked `Recommended`: Capture region, Capture last region, Capture window, Save, Copy image to clipboard — the capture and export actions used most often. - Shortcut source: Greenshot's official help page (https://getgreenshot.org/help/), cross-checked against the unofficial `defkey.com` reference. ## Validation Steps Performed - **Source fidelity:** every shortcut and modifier combination matches the official Greenshot help page one-to-one; no unofficial-source shortcuts were added without confirming them against the official page. --- Closes microsoft#49406 --------- Co-authored-by: Korb <korwin+git@pm.me> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Muyuan Li <116717757+MuyuanMS@users.noreply.github.com>
I guess if you set ExtendsContentIntoTitleBar, well, WinUI will offset your island by x,y=0,1. That's what happens if you don't actually set any titlebar content. * https://github.com/microsoft/microsoft-ui-xaml/blob/main/dxaml/xcp/components/WindowChrome/CWindowChrome.cpp#L202 * https://github.com/microsoft/microsoft-ui-xaml/blob/main/dxaml/xcp/components/WindowChrome/CWindowChrome.cpp#L171 * https://github.com/microsoft/microsoft-ui-xaml/blob/main/dxaml/xcp/components/WindowChrome/inc/CWindowChrome.h#L23 cause like, of course it does. I'm sure there are previous threads to xlink this too
Commented out branch filters for PRs to allow CI on stacked PRs.
## Summary of the Pull Request Quick Accent passes the owner letter's key-down to the rest of the low-level keyboard hook chain. When activation is canceled before the configured threshold, trigger-key modes currently swallow the matching key-up. This leaves downstream keyboard state reporting the letter as held and causes Keyboard Manager's shortcut-to-shortcut safety check to reject later remaps. This change forwards the owner letter's key-up on that false-start path, balancing the event pair for downstream hooks and applications. Successful Quick Accent activation behavior is unchanged. Partial fix: microsoft#38089 ## PR Checklist - [ ] Closes - [ ] **Communication:** Root cause, deterministic reproduction, and validation were posted on microsoft#38089; awaiting core-contributor review - [ ] **Tests:** No automated low-level keyboard-hook test seam is available; extensive manual validation is documented below - [x] **Localization:** No end-user-facing strings changed - [x] **Dev docs:** No developer documentation changes are required for this targeted bug fix - [x] **New binaries:** No new binaries were added - [ ] **Documentation updated:** No user-facing documentation change is required ## Detailed Description of the Pull Request / Additional comments The false-start path runs when the owner letter is released before Quick Accent's activation threshold. Its key-down was already allowed through by `OnKeyDown`, but `OnKeyUp` returned `true` for the Space/arrow activation modes. Returning `true` from the low-level hook prevents later hooks and the target application from receiving the release. Keyboard Manager intentionally checks that no unrelated key is held before applying a shortcut-to-shortcut remap. The missing release therefore makes several remaps stop together while both PowerToys processes remain responsive. It also explains why locking and unlocking the Windows session restores them: the stale keyboard state is reset. The fix is intentionally in Quick Accent rather than relaxing Keyboard Manager's safety check, which must continue to reject remaps when unrelated keys are genuinely held. Full captured evidence and source analysis: microsoft#38089 (comment) ## Validation Steps Performed - Built `PowerAccentKeyboardService` from current `main` in Release x64: 0 warnings, 0 errors. Spectre mitigation was disabled for the local build because the corresponding Visual Studio libraries were not installed. - Built and installed the same change against PowerToys 0.100.2 so the test DLL matched the installed release ABI. - Repeated dozens of false activations with E/N/O/Y by pressing Space and releasing the owner letter before the 500 ms threshold. - Interleaved successful Quick Accent selections to verify normal activation still worked. - Captured `GetAsyncKeyState` transitions and confirmed both the letter and Space changed from down to up; all sampled keys remained up after testing. - Continuously tested a Left Shift+O -> Left Alt+Tab Keyboard Manager remap; it remained functional throughout. - Completed an additional user soak test without recurrence; locking/unlocking was no longer required.
…easured width (microsoft#49633) ## Summary of the Pull Request Two defects in the WinUI 3 Quick Accent selector. They look unrelated but share a root: the overlay owns no layout of its own, so `MainWindow` sizes and shows it by hand — and both halves of that hand-rolled logic rest on an assumption that does not hold. * **microsoft#49489** — the bar appears blank, too wide and clipped on the right for a few frames, then snaps into place. A hidden WinUI 3 window renders nothing, so `ShowWindow(SW_SHOWNA)` puts the HWND on screen before the freshly rebuilt accent list has ever been laid out. * **microsoft#49488** — the window is sized narrower than its own content whenever a glyph is wider than the 48 DIP cell, so the list silently scrolls inside it and the trailing accents are pushed against the right edge. test result: https://github.com/user-attachments/assets/80d57aa8-5030-46c3-9ec8-6ed05ed00f03 ## PR Checklist - [x] Closes: microsoft#49489 - [x] Closes: microsoft#49488 - [x] **Communication:** bug fixes for two open, triaged issues in an existing module; no new feature surface - [x] **Tests:** added — 11 cases in `PowerAccent.Core.UnitTests` covering the new `Calculation.GetToolbarWidth`; the existing positioning/DPI suites are unaffected - [x] **Localization:** no new end-user-facing strings - [ ] **Dev docs:** N/A — the *Toolbar Sizing and Reveal* section was dropped from this PR; the reasoning lives in the code comments and in the commit messages instead - [x] **New binaries:** none — no new projects or outputs, so no `ESRPSigning_core.json`, `Product.wxs`, CI or release YML changes are needed - [ ] **Documentation updated:** N/A — internal rendering/layout fix with no user-facing behavior change beyond the bugs going away ## Detailed Description of the Pull Request / Additional comments ### microsoft#49489 — the blank, over-wide, clipped first frame The window is never actually repositioned or resized. Measuring the two frames in the issue shows the same HWND rect in both: identical left edge, and the bad frame's hard right cut sits exactly where the good frame's rounded corner plus its 24 DIP margin ends. What changes is the **content** — it is composed once from a stale layout, then re-laid-out. Two ordering problems produced that stale composition: 1. `TransientSurface` is `Collapsed` while hidden and is only flipped to `Visible` from the `Showing` event, which `TransparentWindow.RaiseShow` raises **after** `ShowWindow(SW_SHOWNA)`. The accent bar's subtree therefore provably has not been measured or arranged at the moment the HWND becomes visible. 2. The hide path called `ViewModel.Characters.Clear()` synchronously right after `Hide()` — but `Hide()` only *queues* the dismissal, so the still-visible window rendered an empty bar at the old width. That empty card is exactly what the next summon put back on screen. The fix mirrors what the WPF implementation did for the same symptom in microsoft#46593 (render off screen, then `SetWindowPos` into view), adapted to WinUI 3 where a hidden window does not render at all: * Show the bar with `Selector.Opacity = 0`, lay it out, and unveil it once `CompositionTarget.Rendering` confirms a couple of frames have elapsed. `Opacity = 0` still renders (unlike `Visibility.Collapsed`), which is exactly what is needed here. A 150 ms timeout backs it up — not because frames stop arriving (attaching a `Rendering` handler forces the UI thread to run every frame) but because the tick cadence carries no guarantee and can stop for a locked or fully occluded session; on that path the bar simply appears the way it used to, so it can never get stuck invisible. * Size the bar **twice** per summon: once before `Show`, and again after the first real layout pass. The first measurement runs while the surface is still `Collapsed` and, on the first summon of the process, before its template has ever been applied, so it can report less than the items need. The correction happens while the bar is still transparent, so it is never seen as a resize. * Leave the characters in the list on hide. The next summon clears and refills them anyway, and not clearing them removes the blank-bar frame at the source. * A generation counter drops a pending reveal when the summon is dismissed or superseded before its frame lands, and arming a new summon detaches the previous one's per-frame handler so it cannot unveil the new bar ahead of its own layout pass. ### microsoft#49488 — width derived from the item count instead of measured `MainWindow` computed the window width as `Characters.Count * 48`, while the XAML cell is `MinWidth="48"` — a *minimum*, not a fixed width. `ListViewItem` → `Grid MinWidth=48` with a `ContentPresenter Margin=12`, so a cell is `max(48, glyphWidth + 24)`: any glyph wider than 24 DIP (₹, ‰, ﷼, ៛, CJK fallbacks) grows its cell. With **All languages** selected, R and P each carry ~20 characters and the accumulated error is enough for the real content to overflow the window. The ListView's `ScrollViewer` (`HorizontalScrollMode="Enabled"`, `HorizontalScrollBarVisibility="Hidden"`) then absorbs the overflow invisibly, and `ScrollIntoView` starts scrolling a bar that should not scroll at all. The pre-migration WPF window used `SizeToContent="WidthAndHeight"` and only set `MaxWidth`, so the layout system measured the same item template and the window simply grew — which is why this never showed up before. `AppWindow` has no `SizeToContent` equivalent, and the migration replaced it with a constant model. Now: * `SelectorControl.MeasureContentWidthDip()` measures the list against an unbounded width and returns what the items actually need. Measuring explicitly, rather than reading a stale `DesiredSize`, addresses the concern recorded in the original comment: the bar is rebuilt on every summon while the window is still hidden, so no layout pass has run for the new items yet. * `Calculation.GetToolbarWidth()` — a pure function, hence the unit tests — floors that measurement at `itemCount * minItemWidth` (every cell is at least the minimum, so a list that could not be measured reports 0 and safely falls back to the old estimate instead of collapsing the bar), applies the description row's minimum width, and clamps to the display's usable width so long character sets still scroll on purpose. * The clamp's lower bound is `minItemWidth + chromeWidth` — one cell plus the space around it, the narrowest bar that can still draw a glyph — and its upper bound is `Math.Max(minItemWidth + chromeWidth, maxWidth)`, because a display narrower than that floor would otherwise invert the bounds and make `Math.Clamp` throw. `DescriptionMinWidthDip = 648` masked this bug whenever the Unicode description row was on and the character set short, which is likely why microsoft#49402 (description-row width) did not surface it. ## Validation Steps Performed * `PowerAccent.Core`, `PowerAccent.UI` and `PowerAccent.Core.UnitTests` build clean (Debug|x64). * `PowerAccent.Core.UnitTests`: 32/32 pass, including the 11 `GetToolbarWidth` cases — narrow glyphs hug the item count, wide glyphs win over the count estimate (the microsoft#49488 regression guard), the measurement winning by a single DIP, a partly realized list keeping the item-count floor, an unmeasured list falling back to the estimate, over-long content clamping to the display maximum, the description row widening a short bar but not a long one, the description minimum losing to a narrower display, and both ends of the clamp. The lower clamp bound was verified by mutation: rewriting it to `Math.Clamp(width, 0, ...)` fails only `GetToolbarWidth_EmptyList_FallsBackToOneCellPlusChrome`. --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
As it turns out, the robots are unbelievably stupid. When they build our projects to verify their changes, they will often just build the .csproj that they changed rather than building it in the context of the solution. On the surface, this feels like a good idea. Only build the thing that changed. However, because they're not building it in the context of a solution, the MSBuild variable `$(SolutionDir)` doesn't get expanded to the actual directory of the solution. Instead, it just gets treated as the *path to the project*. This creates terrible recursive loops where the output of a project gets dumped relative to the project itself, and then that gets taken as input to the project's package outputs, and eventually you're gonna end up with a max path overrun. The very easy solution here is to just replace `$(SolutionDir)` with `$(RepoRoot)`. If we use that variable, then the dumb robots will still get the correct value for that variable when they build just a project. And for all the actual humans, everything will work exactly as it did before.
… of a Flyout (microsoft#49161) ## Summary of the Pull Request Replaces the inline preset-edit **Flyout** on the Image Resizer settings page with a **ContentDialog**, matching the add/edit pattern already used on the **Color Picker** page. This aligns the experience with the Windows 11 / Fluent paradigm and fixes preset settings being saved on every intermediate change. Editing now happens on a **working copy** of the preset (`ImageSize.Clone()`), which is committed only when the user presses **Save/Update**. As a side effect, the intermediate width/height spinner changes no longer persist `settings.json` / `sizes.json` on every value change — resolving microsoft#36938. The per-row **delete** action moves from an inline trash button into a **"..." (More options)** `MenuFlyout`, again matching the Color Picker page. Historically this editing was a Flyout rather than a ContentDialog due to known `ContentDialog` / `XamlRoot` issues back when Settings was a UWP app. Now that Settings is on WinUI 3 / Windows App SDK, `ContentDialog` works reliably (as Color Picker's `ColorFormatDialog` demonstrates), so the original constraint no longer applies. https://github.com/user-attachments/assets/bf71b0a9-c3f8-4078-95c7-c7ee9dc7b24b ## PR Checklist - [x] Closes: microsoft#49157 - [x] Closes: microsoft#36938 - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized (added to `Resources.resw`; reused existing keys for the delete menu) - [ ] **Dev docs:** Added/updated - [x] **New binaries:** None added ## Detailed Description of the Pull Request / Additional comments - **Dialog:** Clicking a preset card (or **Add new size**) opens an `EditSizeDialog` `ContentDialog`. Fields are bound with compiled `{x:Bind}` against a working-copy `EditingSize`. The dimensions field header is dynamic — **"Width"** when height is used, **"Size"** for aspect-ratio-preserving percentage scaling — so the label isn't misleading. The dialog is widened for a less cramped layout. - **Save semantics:** - `ImageSize.Clone()` — builds the editable working copy. - `ImageResizerViewModel.CreateNewImageSizeModel()` — builds a default-valued model for the add dialog without adding it to `Sizes`. - `ImageResizerViewModel.AddImageSize(ImageSize)` — commits a new preset with the next unique ID. - `ImageResizerViewModel.UpdateImageSize(original, updated)` — applies edited values back onto the original, temporarily detaching the per-item `PropertyChanged` save handler so it persists **once** instead of on every property. This is what fixes the "saved too often" behavior in microsoft#36938. - **Delete:** per-row `Button` → `MenuFlyout` with a Delete `MenuFlyoutItem`; the `ImageSize` is passed via `CommandParameter="{x:Bind}"` (robust inside a flyout popup) and the Yes/No confirmation dialog is preserved. ## Validation Steps Performed - Built `PowerToys.Settings` (x64/Debug) — clean (exit 0). - Ran the runner from this build and manually validated in Settings → Image Resizer: - **Add new size** opens the dialog pre-filled; Save adds the preset; Cancel discards. - **Editing** a preset in the dialog and pressing Cancel leaves the original untouched (working-copy clone). - Selecting **Percent** shows the **Size** header (not a misleading "Width"). - Spinning width/height inside the dialog no longer writes settings files on each change; a single save occurs on Update (microsoft#36938). - The **"..."** menu shows **Delete**, with the confirmation dialog intact. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
) ## Summary of the Pull Request Fixes two local C++ build reliability problems: - Compiles all PowerToys C++ projects as UTF-8 through `Cpp.Build.props`, so builds do not depend on the active Windows code page. On code page 936, UTF-8 punctuation in BOM-less source files otherwise triggers C4819 and fails the build because warnings are treated as errors. - Uses `$(RepoRoot)` for Keyboard Manager repository paths and standardizes native/test output directories. This makes direct project builds find the resource conversion script and headers, places the Editor wrapper beside the WinUI app, and keeps the Engine test DLL under the repository test output directory. No runtime logic, end-user strings, dependencies, or binaries are added. ## PR Checklist - [x] Closes: microsoft#49573 - [x] Closes: microsoft#49574 - [x] **Communication:** Discussed the shared UTF-8 policy with a PowerToys collaborator in this PR - [x] **Tests:** Existing Keyboard Manager Engine tests pass; no new tests are needed for project-only changes - [x] **Localization:** No end-user-facing strings are changed - [x] **Dev docs:** No documentation changes are required for project configuration fixes - [x] **New binaries:** No new binaries are added - [x] **Documentation updated:** No user documentation changes are required ## Detailed Description of the Pull Request / Additional comments `Directory.Build.props` imports `Cpp.Build.props` for C++ projects. Defining `/utf-8 %(AdditionalOptions)` in its shared `ClCompile` settings makes source decoding deterministic across the native codebase and prevents future BOM-less UTF-8 source files from reintroducing the same locale-dependent failure. `/utf-8` explicitly sets both the source and execution character sets instead of suppressing C4819 or replacing valid Unicode text. `$(SolutionDir)` is only reliable when MSBuild is invoked through a solution. The repository's local build script builds `.vcxproj` files directly from their project directories, where `$(RepoRoot)` is the stable repository root property. The wrapper output now follows the existing `$(RepoRoot)$(Platform)\$(Configuration)\WinUI3Apps\` pattern used by other native WinUI dependencies. ## Validation Steps Performed All successful builds used the repository build scripts with `-Platform x64 -Configuration Debug`. - Ran `tools/build/build-essentials.cmd`: solution restore, Runner, and Settings all succeeded with empty errors logs. - Built `FancyZonesLib` successfully after it had failed with a resource-related CL exit during a full parallel build. - Built `WorkspacesModuleInterface` successfully, validating that existing UTF-16 BOM headers remain compatible with the shared option. - Built `ZoomItBreak` and `ZoomIt` successfully. - Built `KeyboardManagerEngineTest` successfully. - Built `KeyboardManagerEditor` and `KeyboardManagerEditorUI` successfully after the documented essentials prerequisite. - Confirmed the successful native build logs contain `/utf-8` compiler invocations and all corresponding `build.debug.x64.errors.log` files are empty. - Ran `vstest.console.exe` against the Keyboard Manager Engine test assembly: 103/103 passed. - Confirmed `PowerToys.KeyboardManagerEditorLibraryWrapper.dll` is emitted to `x64/Debug/WinUI3Apps`. - Confirmed `KeyboardManager.Engine.UnitTests.dll` is emitted to `x64/Debug/tests/KeyboardManagerEngine`. - Previously manually verified the x64 Debug PowerToys build can open Keyboard Manager Editor without 0x8007007E. A full `PowerToys.slnx` x64 Debug build was attempted twice. The first attempt exhausted the remaining 62 MB of disk space. After clearing 52.46 GB of ignored build outputs, the second attempt still exceeded the machine's temporary disk/commit limits (`CL.exe` exit `0xC000012D` and an out-of-space cppwinrt write). Before that resource failure, the log contained 4,642 `/utf-8` command entries and no character-set diagnostics. The full configuration matrix is left to PR CI rather than bypassing normal build settings locally. --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
…r message improvements (microsoft#46837) ## Summary of the Pull Request This fixes several critical validation issues with the Environment Variables utility, centralises the validation, guards registry writes, and improves error messages for validation failures. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: microsoft#46763 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments This PR fixes a reported critical vulnerability (microsoft#46763) where creating an environment variable with an equals sign in the name reportedly caused Windows to crash and enter a boot loop upon restarting. During the investigation of the issue, several other environment variable constraints were identified as missing, including there being no prevention of leading or trailing spaces in names (meaning variables could not be typed on the command line), no combined length checks and so on. This PR introduces a centralised, robust validation pipeline for UI and registry writes to prevent entering states which could corrupt the Windows environment block. ## Changes ### Centralised validation logic - All environment validation is now inside EnvironmentVariablesHelper.cs, rather than split between this code and the UI. - Both the UI (via model validate bindings) and backend registry writes now strictly evaluate against the same unified ruleset before applying changes or enabling/disabling controls. - Existing methods have been updated to report back their success or failure, to enable errors to be tracked more effectively. ### Blocked OS-breaking characters - In response to the user report, the equals character is now blocked from both Variable and Profile names. `=` being disallowed is [explicitly mentioned](https://learn.microsoft.com/en-us/windows/win32/procthread/environment-variables) in the Environment Variables Win32 documentation, so it's a surprise it wasn't caught previously. - All control characters (including `\0`, `\r` and `\n`) are also disallowed, both to protect the integrity of the environment block and the rendering of the strings in the UI. - Leading and trailing whitespace is rejected to prevent orphaned variables. ### Enforced Windows length constraints - Variable Names and Profile Names are restricted to 259 characters, to match the 260-character null-terminated string length limit in the Windows Environment Variables Editor (via sysdm.cpl) and RegEdit. To be clear: profile names may technically be longer, but we should choose to abide by this authoring tool limit to maintain compatibility with other editors. There was previously a 255-character limit on names in the code, and a comment indicating this was a registry limit, but that was incorrect and has been removed. The new limit constant is `MaxEnvironmentVariableNameAuthoringLength`. - In the prior code, there was no limit on the length of system variable names. This was incorrect. The limit for both System and User name fields is now the identical at 259 characters. - There is a length limit on the full environment variable entry `[VariableName]=[VariableValue]\0`, which is 32766 characters plus the null-terminator. This is now enforced and the constant is `MaxTotalEnvironmentVariableLength`. (There's no imposed limit on the number of environment variables.) ### Fixed User Profile backup "overflows" - Fixed a bug where a user could create a valid Profile Name and a valid environment variable name, but applying them would silently fail to apply the profile because the generated backup variable name `[VariableName]_PowerToys_[ProfileName]` exceeded the previous authoring limit of 255 characters. - Backup variables are excluded from the 259-character limit, as they are internal to the application, but the combined `[VariableName]=[VariableVavlue]\0` length is still strictly constrained to the 32767 environment variable length limit. There are now separate paths through the code to deal with backup variable persistence and validation. ### UI - If an applied user profile's name is now rejected because of the new rules (e.g. it contains `=`), the UI now shows a specific "Profile name is invalid" warning rather than the generic "not applicable" message from before, allowing the user to identify and fix the problem. - Fixed a small issue in the Add New Variable dialog where a vertical scrollbar was always present. There are other cases where this occurs, too, but I've left them for a future PR. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed New unit tests project added with coverage of the new validation functionality. Also, manual testing... Manual validation of each dialog: - Add variable - Edit variable - Add variable via Profile Edit dialog Test against: - `=` being in either the Variable Name or the Profile Name - A control character being present in the Variable Name or Profile Name - Either the Variable Name or Profile Name containing one or more trailing or leading whitespace characters - The length of the Variable Name being longer than 259 characters - The combined length of name + `=` + value being longer than 32766 characters The dialog tests can be confirmed by checking to see if the Save button is enabled: <img width="1099" height="843" alt="image" src="https://github.com/user-attachments/assets/685e561a-bd8d-4926-b9b2-a61dea4cc96a" /> Also confirm: - An invalid Profile Name is caught. This can be confirmed by: Editing the JSON file and adding an `=` character in the name: <img width="497" height="197" alt="image" src="https://github.com/user-attachments/assets/c6aa5d62-0672-499a-aac4-c639e8158b61" /> Then opening the application and trying to enable the profile: <img width="1117" height="371" alt="image" src="https://github.com/user-attachments/assets/bd887a44-5e65-4750-9c6f-9bf1b82a5ad6" /> Also confirm that in the Edit profile dialog, you can enable the profile, but the Save button is disabled: <img width="688" height="603" alt="image" src="https://github.com/user-attachments/assets/10d186d9-17a0-4210-93e3-23b1e2723f5f" /> - Confirm that control characters cannot be part of the Variable Name: First, run this from PowerShell, which adds a string containing the newline character to the clipboard: ```pwsh Set-Clipboard -Value "MyVar`nName" ``` Open the Add or Edit variable dialog and paste the value into the Name field. Confirm that the character is not pasted and the string truncates before it: <img width="1424" height="732" alt="image" src="https://github.com/user-attachments/assets/260ff728-57a2-438f-bb66-08d32a327b64" /> (For the null character specifically, use `Set-Clipboard -Value ("MyVar" + [char]0 + "Name")`.) - The initial dialog button state. Re-open the Add New variable dialog multiple times and confirm the Save button is disabled each time before making any input. - In the Add/Edit Variable dialogs, enter a valid variable name and then clear it, confirming that the Save button enables and disables correctly. ## Still outstanding There are some flaws I've found which I'm choosing to leave for now, mainly for expedience so the above issues can be prioritised: - Handling duplicate profile names - there is the potential there for duplicate variable names under identically-named profiles to conflict. - Profile JSON import is still not sanitised. These should be added in a future PR.
## Summary of the Pull Request Adds Simplified and Traditional Chinese translator guidance for both Find My Mouse double-Control activation options so the localized UI keeps the familiar `Ctrl` key label instead of using `控制键` or `控制鍵`. ## PR Checklist - [x] Closes: microsoft#46223 - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx ## Detailed Description of the Pull Request / Additional comments As discussed in [microsoft#46223](microsoft#46223 (comment)), Chinese users commonly identify this physical keyboard key by its `Ctrl` label. Translating it as `控制键` in Simplified Chinese or `控制鍵` in Traditional Chinese makes the Find My Mouse activation options harder to understand. PowerToys localized resources are generated through the CDPX localization pipeline, so this PR expands the translator comments for both the left and right Control activation strings. The English values, resource keys, settings schema, UI tests, and runtime behavior remain unchanged. ## Validation Steps Performed - Parsed the modified `Resources.resw` successfully as XML. - Verified both affected Find My Mouse entries contain Simplified and Traditional Chinese guidance. - Confirmed the diff changes translator comments only and passes `git diff --check`. - No build or automated tests were run because this is a comment-only localization guidance change with no runtime impact. --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Makes changes so Shoertcut Guide could be compiled ahead of time <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
## Summary of the Pull Request Updates Image Resizer preset descriptions in both the resize dialog and the Settings page from sentence fragments such as `Fits within 1920 × 1080 pixels` to CRUTKAS's proposed `Fit - 1920 × 1080 pixels` format. The UI reuses existing localized mode labels and removes the obsolete third-person resources. ## Screenshots ### Resize dialog  ### Settings page  ## PR Checklist - [x] Closes: microsoft#16790 - [x] **Communication:** Implements the pattern proposed and accepted by core contributors in microsoft#16790 - [x] **Tests:** Existing Image Resizer tests pass; the Image Resizer and Settings UI projects build successfully - [x] **Localization:** Reuses existing localized mode and unit strings; no new translatable text - [x] **Dev docs:** Not applicable - [x] **New binaries:** Not applicable - [x] **Documentation updated:** Not applicable ## Detailed Description of the Pull Request / Additional comments Preset details now use the infinitive resize mode followed by a neutral dash and the dimensions on both Image Resizer surfaces. This avoids requiring translators to make a sentence fragment agree grammatically with the dimensions. Accessible Settings descriptions use the same wording, and the obsolete third-person mode resources are removed from both resource sets. ## Validation Steps Performed - Built `ImageResizerUI.csproj` for x64 Debug - Built `ImageResizer.UnitTests.csproj` for x64 Debug - Ran all 149 Image Resizer unit tests successfully - Built `Settings.UI.csproj` for x64 Debug - Ran the PR-built resize dialog and Settings page and verified the new text in both surfaces --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: f058c3d9-38d8-4a35-8c5e-69100b2b673c
## Summary - keep the `File Explorer Add-ons` source string in the navigation view - use the same title on the File Explorer Add-ons settings page through `FileExplorerPreview.ModuleTitle` - add translator guidance to keep the navigation and page-title values consistent ## Validation - parsed `Resources.resw` as XML - ran `git diff --check` - verified both resource values resolve to `File Explorer Add-ons` Fixes microsoft#24414. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a53b4a7f-26bc-41e1-963a-c80ec33a4b1c Copilot-Session: 75064a4f-2237-4c2b-97de-c983de9e9ecd
As I threw in microsoft#49572 (comment): 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 microsoft#38333 Closes microsoft#40277 Closes microsoft#49572
…tor (microsoft#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: microsoft#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 ````
## 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: microsoft#35272 - [x] **Communication:** Requested in microsoft#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
## 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 microsoft#45598. Copilot-Session: a53b4a7f-26bc-41e1-963a-c80ec33a4b1c
<!-- 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 microsoft#49458 --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
…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
…osoft#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
…red ranker (microsoft#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 microsoft#49190 is merged into it.** >[!NOTE] > To test the final result, run the branch associated with PR microsoft#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. [microsoft#49189](microsoft#49189) introduces the new ranking foundation. Results are grouped by match strength, ensuring exact names, prefixes, and acronyms rank above loose fuzzy matches. 2. [microsoft#49190](microsoft#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. [microsoft#49191](microsoft#49191) lets users give each provider a Lower, Normal, or Higher search preference. This preference helps resolve close matches without overriding result relevance. 4. [microsoft#49194](microsoft#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. [microsoft#49195](microsoft#49195) adds a comprehensive relevance test suite. It verifies that common searches return the expected results and protects ranking quality from future regressions. 6. [microsoft#49197](microsoft#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. [microsoft#49246](microsoft#49246) adds a performance measurement suite. It identifies where search time is spent and provides a reliable way to evaluate performance improvements. 8. [microsoft#49247](microsoft#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. [microsoft#49249](microsoft#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 microsoft#49249 with this PR being the last. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
…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: microsoft#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
## 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
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 7b3fb20d-6e9d-4fef-a5cd-f8921d28c220
github-actions
Bot
requested a review
from Jessica Dene Earley-Cha (chatasweetie)
August 7, 2026 03:58
|
Thank you for contributing to PowerToys. We've detected that this PR might include a new or modified telemetry event. Please ensure the following before merging:
|
Boliang Zhang (LegendaryBlair)
merged commit Aug 7, 2026
1b54001
into
microsoft:stable
13 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
mainate403027451intostablefor the 0.101 release.v0.100.2.Conflict resolutions
The seven conflicting paths use the current
mainversions. Each overlapping stable fix already has a patch-equivalent commit onmain, followed by newer refactoring or feature work:MainWindowandTaskbarWindowfiles.Validation
origin/mainexactly.