mirror of
https://github.com/microsoft/PowerToys.git
synced 2026-09-01 19:51:34 +02:00
1980ca5ecef4e9fd1b9af45ba6c18eb893900a40
9466 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Boliang Zhang
|
1980ca5ece |
[Runner][Interop] Authenticate Settings/Quick Access named-pipe clients before dispatch (CWE-732/CWE-862) (#49527)
## Summary of the Pull Request
The Runner is the **server** for the two-way named pipes it uses to talk
to `PowerToys.Settings.exe` and the Quick Access host, and it dispatched
privileged JSON commands (`killrunner`, `restart_elevation`,
`module_status`, `powertoys`, `language`, ...) **without authenticating
the caller**. When PowerToys runs elevated ("Run as administrator"), the
pipe DACL grants the shared **Logon SID**, so **any same-user Medium-IL
process could connect and inject commands** — a local privilege
escalation (CWE-732 / CWE-862). The pipe DACL cannot distinguish the
legitimate Medium-IL Settings child from a same-user attacker (identical
user SID, integrity level, and logon session), so this PR authenticates
the connecting process's **binary identity** before any dispatch.
## PR Checklist
- [x] **Tests:** Added/updated and all pass (native gate tests + C#
regression)
- [x] **Localization:** No new end-user-facing strings (only a
diagnostic runner log line)
- [x] **New binaries:** None — the new code compiles into the existing
`PowerToys.Interop` and `runner` binaries; tests were added to the
existing `Common.Utils.UnitTests` project
## Detailed Description of the Pull Request / Additional comments
New `src/common/interop/pipe_caller_auth.{h,cpp}` adds
`interop_auth::AuthenticateClient`, invoked from
`TwoWayPipeMessageIPC::handle_pipe_connection` **before** a message is
queued (fail-closed). A connecting client is accepted only if it is:
- under the **Runner-relative install directory**
(`get_module_folderpath()\WinUI3Apps`, so it adapts to installed and
dev-build layouts),
- an **allow-listed basename** (`PowerToys.Settings.exe` /
`PowerToys.QuickAccess.exe`),
- the Runner's **exact file version** (anti-downgrade), and
- **Microsoft Authenticode-signed**.
The signature is anchored to the **LOCAL MACHINE root store**
(`HCCE_LOCAL_MACHINE` +
`CertVerifyCertificateChainPolicy(AUTHENTICODE)`) rather than
`WinVerifyTrust`'s default user+machine union: the Runner runs as the
same user as a potential attacker and would otherwise trust a forged
signer added to `CurrentUser\Root`. Verdicts are cached per `(pid,
process-creation-time, policy)` with a short TTL so the check isn't
re-run on every message (each `send` opens a new connection). Rejections
are logged.
The gate is added via an **additive** `start(HANDLE, CallerPolicy)`
overload; the managed `start(nullptr)` path is unchanged (gate
disabled), so there is **no ABI break** to `PowerToys.Interop`.
`PIPE_REJECT_REMOTE_CLIENTS` is also set. In **Debug** builds only the
signature check is relaxed (directory/basename/version stay enforced) so
local unsigned builds still connect; the relaxation is compiled out of
Release.
**Scope:** this PR covers the two elevated Runner-server pipes (Settings
+ Quick Access), which are the actual EoP surface. The reverse
Runner->Settings response direction, the duplicated Workspaces
transport, and the AdvancedPaste/PowerDisplay module pipes are
intentionally out of scope and can be handled as follow-ups.
## Validation Steps Performed
**Automated**
- **Native unit tests** (`Common.Utils.UnitTests`,
`PipeCallerAuthTests`): legitimate self-caller accepted; wrong
basename/directory rejected with the reject-log callback firing; version
reading. 6/6 pass.
- **C# regression** (`Microsoft.Interop.Tests.TestSend`): managed
gate-disabled round-trip still works.
- **Builds:** runner Debug + Release, `PowerToys.Interop` Debug +
Release, and the test project all build/link clean.
**Official signed build (validates the Release-only signature path that
local Debug builds skip)**
- Queued the internal "PowerToys Signed YAML Release Build" for this
branch — **green** (`result: succeeded`). The produced installers are
Authenticode `Valid`, signer `Microsoft Corporation`.
**Manual testing on the signed installer (elevated Runner) — passed**
- Installed the signed build and ran the Runner **as administrator**.
Settings and Quick Access open and are fully functional; settings apply,
module toggles work, and the hotkey-conflict request/response
round-trips.
- **No** `Rejected unauthenticated ...` lines during legitimate use →
the genuine signed `PowerToys.Settings.exe` is accepted by the
machine-root signature + version + directory checks (verified in
`RunnerLogs\runner-log_*.log`, requests dispatched normally).
- **Security (negative) check:** a non-elevated `powershell.exe`
discovered the runner pipe via the pipe namespace and attempted
`{"killrunner":true}`; the write failed ("Pipe is broken") because the
Runner rejected the caller and disconnected before dispatch.
`PowerToys.exe` stayed running and logged: `Rejected unauthenticated
Settings pipe client: pid=... image='...\powershell.exe'
reason=bad-directory`.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 1d8f85ec-aaee-468a-9348-ba79b059cbaf
|
||
|
moooyo
|
ba2e89c428 |
PowerDisplay: Fall back to persisted VCP values when a monitor read fails (#49445)
## Summary of the Pull Request On a monitor whose DDC/CI engine answers intermittently, every discovery pass starts from nothing. A panel that reported its brightness a minute ago can lose that control — or drop out of the flyout entirely — because one pass happened to fail. This persists every range-valid VCP value read off a monitor, keyed by its canonical DevicePath. In Maximum compatibility mode a later discovery falls back to that value when the hardware will not answer. Scope is intermittent failure, not permanent failure: the cache can only replay a value the hardware answered at least once, so a panel that never reads a code successfully sees no change. This partially addresses #49342. ## PR Checklist - [x] Closes: #49342 - [ ] **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 — this PR adds none - [ ] **Dev docs:** Added/updated - [x] **New binaries:** Added on the required places — none added, so no signing JSON, installer WXS or CI YML change is required - [ ] **Documentation updated** ## Detailed Description of the Pull Request / Additional comments ### What is stored `MonitorStateManager` implements `IKnownGoodVcpStore`, so the cache rides in the existing `monitor_state.json` next to the user's saved brightness rather than in a new file. Each entry is a `KnownGoodVcpFeature`: code, current, maximum, and when it was last read. Only range-valid observations are stored, so the common `current=0 / max=0` garbage reply never enters — it fails `VcpFeatureValue.IsValid`. Writes are not gated on Maximum compatibility mode, only reads are. A monitor that reads cleanly today can start failing after a cable or dock change, and a lazily populated cache would be empty on exactly the first pass that needs it. ### How a cached value is used `VcpDiscoveryEvidence.Reconcile` gains the cache as a third source alongside the parsed capabilities string and this pass's probe: | this pass | cache | result | | --- | --- | --- | | read succeeded | — | live value wins, cache refreshed | | replied, range unusable | hit | cached value applied, `MonitorReadFlags` left clear | | no reply | hit | cached value applied, `MonitorReadFlags` left clear | | code never probed (caps parsed) | hit | value applied only after one live read is attempted | The last row matters: on the caps-parsed path nothing has confirmed the cached value this pass, so the hardware is asked first. On the probe path it has already been asked, and re-reading would be pure I2C noise. `MonitorReadFlags` stays clear for anything the hardware did not answer, so a cached value never masquerades as an observation — which #49577 depends on, since it made the restore path write whenever the flag is unset. One consequence is worth naming: the flyout draws a slider at the cached position while `powerdisplay get` reports that setting as unknown, because `MonitorDtoProjector` gates on `supported && read`. ### Keeping the cache current `RefreshKnownGoodAfterWrite` restamps an entry after a successful `SetVCPFeature`, so a slider move cannot leave the cache holding the pre-write value. It refreshes only an entry a real read established, and only when the value was scaled against the maximum that entry holds — a monitor whose discovery read failed still carries a placeholder max, and writing that back would mis-scale every later write. `RemoveKnownGoodFeatures` clears the cache for monitors a settings reconciliation observably dropped, leaving the user's saved values alone. Cleanup is driven by an observed drop, never by absence from the rebuilt list: a missing or corrupt `settings.json` yields a defaults object indistinguishable from a real one, and pruning by absence would wipe every monitor not connected at that instant. A re-observation that changes nothing refreshes the in-memory timestamp but does not mark the file dirty, so a discovery pass no longer rewrites `monitor_state.json` for a moved timestamp alone. ## Validation Steps Performed - `PowerDisplay.Lib`, `PowerDisplay.Lib.UnitTests` and `PowerDisplay` built for x64 Debug with VS MSBuild — 0 errors, 0 warnings; `PowerDisplay.Lib.UnitTests.dll` under `vstest.console.exe`: **301 passed, 0 failed** - **Affected-hardware validation on the AOC Q27G3XMN is still pending.** That monitor, or an equivalent controllable DDC/CI setup, was not available locally. The paths this PR changes are reachable only on hardware whose capabilities string is unusable or whose VCP reads fail intermittently, so this is the main outstanding risk. --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Copilot-Session: 6ea38c04-6f68-4c42-91d9-8a03b49bdd81 |
||
|
Muyuan Li
|
37d8729ac3 |
FancyZones: apply edited custom layout spacing/sensitivity/zone count to active work areas immediately (#49433)
## Summary of the Pull Request When a **custom layout** is edited in the FancyZones editor while windows are already snapped to it, changes to the layout's *scalar* properties — **spacing between zones**, **highlight/activation sensitivity radius**, and **zone count** (for canvas layouts) — were **not applied to already-active work areas** until PowerToys (or FancyZones) was restarted. Only the grid **shape/edges** refreshed live. This PR makes those scalar edits take effect immediately on existing work areas, resolving the remaining gap in issue 44058. ## PR Checklist - [x] Closes: #44058 - [x] **Communication:** This addresses the behavior tracked in the linked issue. - [x] **Tests:** Added `EditedCustomLayoutSpacingRefreshesExistingWorkArea` regression test; existing FancyZones unit tests pass. - [x] **Localization:** No new end-user-facing strings. - [x] **Dev docs:** N/A (no public API or doc surface change). - [x] **New binaries:** None added. ## Detailed Description of the Pull Request / Additional comments ### Root cause For a **Custom**-type layout, `WorkArea::CalculateZoneSet` builds its `Layout` from `AppliedLayouts::GetDeviceLayout()`, which returns a snapshot from `applied-layouts.json`. The zone **shape** is read live from the `CustomLayouts` store, but the scalar properties (`spacing`, `sensitivityRadius`, and `zoneCount`) were taken from that **stale applied-layouts snapshot**. So when the editor updated the custom layout and fired `WM_PRIV_CUSTOM_LAYOUTS_FILE_UPDATE`, the existing work areas re-laid-out their grid geometry but kept the *old* spacing/sensitivity/zone count. ### The fix In `WorkArea::CalculateZoneSet`, for Custom-type layouts, re-derive the scalar properties from the **live** `CustomLayouts` store instead of the stale snapshot: ```cpp if (const auto refreshed = CustomLayouts::instance().GetLayout(appliedLayout->uuid)) { appliedLayout = refreshed; } ``` `CustomLayouts::GetLayout` returns the canonical `LayoutData` used by the apply path (it derives grid zone count from `zoneCount()` and canvas zone count from `zones.size()`), so the refreshed values exactly match what a fresh apply would produce. **Why this is low-risk:** - Scoped strictly to **Custom** layouts; templated layouts (Grid/Columns/etc.) are untouched. - At initial apply-time, the live store and the applied-layouts snapshot are equal, so behavior is unchanged for the common case — only a genuine *edit* of an already-applied custom layout changes the outcome (which is the intended fix). This complements the editor-side `RefreshLayouts()` call (which refreshes zone shape) so that **all** properties of an edited custom layout now apply live. ## Validation Steps Performed **Automated:** Added `EditedCustomLayoutSpacingRefreshesExistingWorkArea` in `FancyZonesTests/UnitTests/WorkArea.Spec.cpp`. It creates a work area on a grid custom layout, asserts adjacent zones are flush, then edits the custom layout's spacing, re-initializes the layout via `InitLayout()`, and asserts the new spacing gap is present on the existing zones. Built the FancyZones unit tests and ran the `WorkArea` suite — all pass. **Manual (end-to-end):** 1. Create a **grid custom layout** in the FancyZones editor and apply it. 2. Snap a window into one of its zones. 3. Re-open the editor, edit the layout: change the **edge position** *and* the **space between zones** (and optionally sensitivity), then **Save**. 4. **Before this fix:** the zone edges move, but the spacing between snapped windows keeps the *old* gap until PowerToys is restarted. 5. **After this fix:** the new spacing (and sensitivity) are applied to the already-snapped/active work area immediately, with no restart. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 19f7171d-0ca4-48dc-95ef-e50f505a9097 |
||
|
moooyo
|
f4b3dcde03 |
PowerDisplay: Funnel both monitor-state saves through one locked write (#49629)
## Summary of the Pull Request
`MonitorStateManager` wrote `monitor_state.json` from two independent
paths: the debounced save used `File.WriteAllTextAsync`, `Dispose` used
`File.WriteAllText`. Both open the path with `FileShare.Read`, so
disposing while a debounced save had already passed its delay left the
two racing for the same handle — the loser was denied at `CreateFile`
and its payload was dropped whole, into a catch that only logged.
Both paths now go through one method that serializes and writes under a
single lock, and the file is published by rename instead of being
written in place.
## 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
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized —
this PR adds none
- [ ] **Dev docs:** Added/updated
- [x] **New binaries:** Added on the required places — none added, so no
signing JSON, installer WXS or CI YML change is required
- [ ] **Documentation updated**
## Detailed Description of the Pull Request / Additional comments
### The collision
`Dispose` disposes the debouncer before flushing, which cancels a
pending `Task.Delay` but cannot reach a save that has already passed it
and stopped observing the token. That save is inside
`File.WriteAllTextAsync` when `Dispose` reaches its own
`File.WriteAllText`. Both open with `FileMode.Create, FileAccess.Write,
FileShare.Read`, and Windows checks sharing in both directions, so the
second open fails with `ERROR_SHARING_VIOLATION`. The loser never gets a
handle and writes zero bytes — a torn or interleaved file was never
reachable, only a dropped write.
### Why the flush could actually be lost
A bare collision costs only a redundant write: both paths serialize the
same live `_states`, and `UpdateMonitorParameter` mutates it
synchronously before arming the debounce, so whichever writer wins
already has the user's latest value.
The case that loses data is narrower. The debounced save built its JSON
*before* the `await`, so:
1. the debounced save snapshots `{brightness: 60}` and opens the file;
2. the user moves a slider to 70 — `_states` is updated, a new debounce
is armed;
3. the user quits; `Dispose` snapshots `{brightness: 70}` and is denied
at `CreateFile`;
4. the async write completes, publishing 60.
70 is gone. The window is the few hundred microseconds the async write
holds the handle, but it is exactly the window in which the user is
quitting.
### The fix
Both paths call `WriteStateFile`, which takes `_writeLock` and does the
serialize-and-write inside it. `BuildStateJson` runs under the lock too,
so the last snapshot built is the one that lands — a writer that queues
behind another re-snapshots rather than replaying a stale payload.
The write is synchronous on both paths. `Dispose` has to flush without
awaiting, the file is a few hundred bytes, and the async API was the
only reason there were two write paths to collide in the first place.
That is also why the guard is a plain `lock` rather than a
`SemaphoreSlim`: with neither caller async there is no
blocking-on-an-async-method concern left to design around.
`Dispose` keeps its ordering — dispose the debouncer so nothing new is
scheduled, then flush if the state was dirty.
### Publishing by rename
The bytes go to a temp file and are renamed in, matching
`CrashDetectionScope` and `ProfileStore` in the same module. An in-place
write truncates at `CreateFile` before it writes anything, and two exit
paths never reach `Dispose` at all — `App.OnLaunched` registers
`TerminatePowerDisplayEvent` and the runner-exit watchdog, and both call
`Environment.Exit(0)` outright. An interrupted write there would leave a
zero-byte file, which `LoadStateFromDisk`'s catch turns into "no saved
state for *any* monitor" — total loss rather than the last change.
There is deliberately no `Flush(flushToDisk: true)` to go with it. The
threat here is process death, which the page cache survives, not power
loss; and this flush runs on the UI thread at shutdown, where a
`FlushFileBuffers` on a busy disk is the one change in this area a user
could actually feel.
### The dirty flag
`SaveStateToDisk` cleared `_isDirty` *after* the write. A change landing
between the snapshot and that assignment set the bit and had it
immediately cleared; `Dispose` then read `wasDirty == false`, cancelled
the debounce that change had scheduled, and skipped the flush — losing
exactly the last change this path exists to preserve. It is now cleared
before the snapshot and re-marked if the write throws, so a change that
lands mid-write either rides along in the snapshot or stays dirty.
### Testability
`MonitorStateManager` gains an internal constructor taking a state file
path, so tests can drive it against a temp directory instead of the real
LocalAppData location.
## Validation Steps Performed
- `PowerDisplay.Lib` and `PowerDisplay.Lib.UnitTests` built for x64
Debug with VS MSBuild; `PowerDisplay.Lib.UnitTests.dll` under
`vstest.console.exe`: **273 passed, 0 failed** (4 of them in
`MonitorStateSaveTests`)
- Removing `lock (_writeLock)` fails
`ConcurrentWrites_DoNotCollideOnTheStateFile` with the same "used by
another process" `IOException` the collision produces, so the test pins
the guard rather than the shape of the code
- `FailedWrite_LeavesTheExistingStateFileIntact` occupies the temp path
with a directory so the write fails at exactly the point an in-place
`File.WriteAllText` would already have truncated the published file;
against the previous in-place write the same test fails, since that
write would succeed and replace the file
- No end-to-end manual check was performed. The window is a few hundred
microseconds wide and only opens when a debounced save is mid-write at
the exact moment `Dispose` runs, so reproducing it by hand is unreliable
— the concurrency test drives the same contention deterministically
instead
### Known gap, not addressed here
`TerminatePowerDisplayEvent` and the runner-exit watchdog call
`Environment.Exit(0)` without ever running `Dispose`, so on those paths
up to a full `SaveDebounceMs` (2 s) of changes is dropped
unconditionally — no race required. That is a larger loss surface than
the one this PR closes, and the module already has the machinery to fix
it (`CrashDetectionScope` subscribes to `AppDomain.ProcessExit` through
an `IProcessExitHook` seam for precisely these paths). Left out to keep
this PR to one logical change; happy to open a follow-up issue.
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
|
||
|
chakrik73
|
d2c53bf386 |
[ZoomIt] Add DemoMirror feature (#49607)
Mirror the screen, a selected region (Shift), or the window under the cursor (Alt) onto a second monitor - including the mouse pointer - so a demo can be shown on a presentation display without leaving the current view. Adds the native MirrorWindow implementation, a DemoMirror options tab (Ctrl+9 default, plus Track window region), and the corresponding Settings UI (ZoomIt page group, view model, properties, and resources). ## Summary of the Pull Request Adds a **DemoMirror** feature to ZoomIt. It mirrors the screen, a selected region (Shift), or the window under the cursor (Alt) onto a second monitor — including the mouse pointer — so a demo can be shown on a presentation display without leaving the current view. This introduces the native `MirrorWindow` implementation, a new DemoMirror options tab (default hotkey **Ctrl+9**, plus a **Track window region** option), and the corresponding Settings UI wiring (ZoomIt page group, view model, properties, and localized resources). ## PR Checklist - **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 - [ ] [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] ## Detailed Description of the Pull Request / Additional comments DemoMirror lets a presenter keep working on their primary display while a second monitor shows a live mirror of a chosen source. Three capture modes are supported via the DemoMirror hotkey (default **Ctrl+9**): - **Full screen** — `Ctrl+9`: mirrors the entire source screen. - **Region** — `Ctrl+Shift+9`: mirrors a user-selected rectangular region. - **Window** — `Ctrl+Alt+9`: mirrors the window currently under the cursor. With the **Track window region** option enabled, the mirror follows the window as it moves/resizes. The mirror includes the mouse pointer so pointer movement and clicks are visible on the presentation display. **Native (C++ / `PowerToys.ZoomIt.exe`)** - New `MirrorWindow.cpp` / `MirrorWindow.h` implementing the mirror capture/render window. Mirror windows use `WS_EX_NOACTIVATE | WS_EX_TRANSPARENT` so they never steal focus from the source. - `Zoomit.cpp`: registers the DemoMirror hotkeys and wires the start/stop handlers; the stop path checks `g_MirrorWindow.IsActive()` and stops unconditionally (cursor-independent). - `ZoomItSettings.h`: new `MirrorToggleKey` (default `Ctrl+9`) and `MirrorTrackWindow` settings, added to the `RegSettings[]` table. Record default kept distinct at `Ctrl+5`. - `resource.h` / `ZoomIt.rc`: new DemoMirror options tab and controls (`IDC_MIRROR_HOTKEY`, `IDC_MIRROR_TRACK_WINDOW`). - `CaptureFrameWait.*` and `SelectRectangle.*` updated to support the mirror capture/selection flow. - `ZoomItSettingsInterop/ZoomItSettings.cpp`: exposes the new settings across the interop bridge. **Settings UI (WinUI 3)** - New DemoMirror group on the ZoomIt page (`ZoomItPage.xaml`), backed by `ZoomItViewModel.cs` and `ZoomItProperties.cs`. - Localizable strings added to `Resources.resw`. **Conflict resolution notes** (rebased on top of upstream `main`): - Control-ID collision resolved by assigning distinct IDs (`IDC_MIRROR_HOTKEY`, `IDC_MIRROR_TRACK_WINDOW`). - `SelectRectangle` border-color: kept upstream `m_borderColor = borderColor;`. - `WM_USER` message-ID collision resolved by using `WM_USER_MIRROR_STOP = WM_USER + 113`. ## Validation Steps Performed Manually validated on a real dual-display setup (Surface laptop extended to an external monitor): - **Full screen** (`Ctrl+9`): source screen mirrored to the second monitor, including the mouse pointer. - **Region** (`Ctrl+Shift+9`): selected region mirrored correctly. - **Window** (`Ctrl+Alt+9`): window under the cursor mirrored; with **Track window region** enabled, the mirror follows the window. - **Stop/cancel**: DemoMirror stops reliably regardless of cursor position; mirror windows never take focus (`WS_EX_NOACTIVATE | WS_EX_TRANSPARENT`). - **Hotkey defaults**: confirmed Record (`Ctrl+5`) and DemoMirror (`Ctrl+9`) defaults are distinct and read independently from their own registry/settings values (no cross-contamination). - **Settings UI**: DemoMirror hotkey and Track window region options round-trip correctly through the Settings UI and the interop bridge. |
||
|
Gordon Lam
|
a64c400b7e |
[MouseWithoutBorders] Increase PBKDF2 key derivation iterations to 100,000 (#49600)
## Summary Increases the PBKDF2 iteration count used to derive the Mouse Without Borders AES-256 session key from 50,000 to 100,000, strengthening the derived key against brute-force attempts. ## Changes - `Encryption.cs`: `KeyDerivationIterations` 50,000 -> 100,000 (used by `GenLegalKey` via `Rfc2898DeriveBytes.Pbkdf2`). The unrelated SHA-512 stretch loop in `Get24BitHash` is deliberately left unchanged - it is not a `Rfc2898DeriveBytes` key derivation and drives the connection framing/identity value. ## Compatibility This changes the derived key, so all paired machines must run this version. Mouse Without Borders already requires the same version on every machine (it surfaces *"make sure you run the same version in all machines"* on a key/handshake mismatch), consistent with the per-connection salt/IV change in #48742. The existing key and settings are preserved and the key is derived fresh per connection, so **no re-pairing is needed once every machine is updated** - only a transient, self-healing failure during a mixed-version window. ## Validation - Built `MouseWithoutBorders` (Release | x64) - clean, exit 0. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9e47bf2c-ee54-4de6-8ce0-9b8dd67d4128 |
||
|
moooyo
|
160492abcf |
docs(skills): recommend WindowEx for WinUI 3 migrations (#49303)
## Summary of the Pull Request Updates the WPF-to-WinUI 3 migration skill to make the established PowerToys windowing pattern explicit: - Default WinUI 3 top-level windows to `WinUIEx.WindowEx` or an existing PowerToys base derived from it, such as `TransparentWindow` for transient overlays. - Keep supported size, presenter, title bar, topmost, backdrop, and persistence behavior declarative in XAML instead of manual `AppWindow` / `OverlappedPresenter` code-behind. - Document the centrally managed `<PackageReference Include="WinUIEx" />`, WPF-to-`WindowEx` property mappings, and existing repository examples. - Add a value-converter decision guide that prefers `VisualStateManager`, direct `x:Bind` conversion, WinUI theme resources, and `CommunityToolkit.WinUI.Converters` over mechanically porting WPF converters. This follows the migration-skill feedback from @niels9001 in [PR #49174](https://github.com/microsoft/PowerToys/pull/49174#discussion_r3535181101). ## PR Checklist - [x] **Communication:** This change follows review feedback from a core contributor in PR #49174. - [x] **Tests:** The updated guidance passed 5/5 fresh agent migration scenarios. - [x] **Dev docs:** Added/updated. ## Detailed Description of the Pull Request / Additional comments `SKILL.md` now states the default PowerToys pattern and limits raw `AppWindow` / presenter code to behavior that `WindowEx` does not expose. The package mapping reference records the exact centrally managed dependency. The windowing reference adds a complete XAML example, a WPF-to-`WindowEx` mapping table, regular-window examples, and the `TransparentWindow` overlay exception. The XAML migration reference now also documents converter selection and reuse: control state belongs in `VisualState`s, count visibility can share one Toolkit `DoubleToVisibilityConverter` with `ConverterParameter=True`, and corner-radius converter resources come from `XamlControlsResources`. This is an atomic documentation-only change; no product code or dependencies are modified. ## Validation Steps Performed - Verified the documented `WindowEx` APIs and `TransparentWindow` inheritance against the repository and compiled WinUIEx assembly. - Verified all cited repository paths, the Markdown anchor, and central package management entry. - Ran five fresh current-branch agent scenarios; all selected `<PackageReference Include="WinUIEx" />` without a version, `WindowEx`, XAML-declared properties, and `CenterOnScreen()` only where required. - Ran a focused converter migration scenario before and after the guidance update; the updated skill selected `VisualState`s, one reusable Toolkit numeric converter, and existing WinUI corner-radius resources without custom converters. - Ran `git diff --check` with no errors. - Completed an independent read-only review with no findings. - Product builds and unit tests were not run because this change only updates agent guidance. --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: fe9b24eb-99f0-43e8-aaa4-839f4579f6f9 Copilot-Session: d5afc36b-3356-46af-b8cb-071b87a64532 |
||
|
moooyo
|
8f63402400 |
PowerDisplay: Adjust brightness by scrolling over the tray icon (#49446)
## Summary of the Pull Request Scrolling the mouse wheel over the Power Display tray icon adjusts brightness, without opening the flyout. - New **Tray icon mouse wheel** setting: `Off` / `Primary display` / `All displays`, defaulting to **`Off`**. It is scoped to the tray icon — the flyout sliders accept wheel input regardless, as they always have. The existing **Mouse wheel increment** setting supplies the per-notch step. - **Off by default.** The gesture consumes a wheel notch that would otherwise reach the window under the pointer, and acting on it installs a system-wide `WH_MOUSE_LL` hook. Neither is something an existing installation should acquire silently on upgrade. With the setting `Off` no hook is ever installed and no notch is ever consumed, so this PR changes no existing behaviour until the user opts in: 1958 insertions, 2 deletions, and both deletions are refactors of lines this feature reuses. - **No feedback UI.** Brightness is self-evidencing — you scroll and the screen changes — so the display itself is the feedback. The notification icon is untouched: same tooltip, same text, same legacy notification-icon protocol. ## PR Checklist - [x] Closes: #49410 - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [x] **Dev docs:** Added/updated - [ ] **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 No new binaries or projects — everything lands in existing assemblies. Communication is unchecked because #49410 is still Needs-Triage. ## Detailed Description of the Pull Request / Additional comments ### Why a low-level hook The Shell does not forward `WM_MOUSEWHEEL` to a notification icon's callback window under any `NOTIFYICON_VERSION`, and a click-through overlay placed over the icon cannot receive wheel input either. `TrayIconMouseWheelListener` therefore installs a `WH_MOUSE_LL` hook — but only transiently, and only when it will act on the result: - Nothing is installed at all while the setting is `Off`, which is the default. - Installed in `EnsureHook()` when the UI thread confirms the pointer is inside the rectangle from `Shell_NotifyIconGetRect` **and** `CanAdjustBrightnessFromTrayWheel` says some monitor can accept a brightness write. - Removed in `DisarmCore()` as soon as either condition stops holding, the pointer leaves the rectangle, or the mode changes. - A notch is consumed (the hook proc returns non-zero) only while armed and only for points inside the armed rectangle, so a wheel event Power Display will not act on still reaches the window under the cursor. The hook runs on a dedicated background thread with its own message loop; the proc itself only enqueues a sample and posts a drain request. Deltas are marshalled to the UI thread in batches, and `WheelDeltaAccumulator` folds high-resolution deltas (precision wheels, touchpads) into whole notches. Each sample carries the hover generation it was captured under, so samples from a hover the UI thread has already retired are discarded rather than applied late. ### Hover detection The Shell sends `WM_MOUSEMOVE` to the icon's callback window while the pointer is over it. `TrayIconService.HandleTrayMouseMove` resolves the rectangle with `Shell_NotifyIconGetRect` and caches it for a second, because that message repeats for every pixel of travel. `TrayIconService` gains nothing else: no protocol change, no new hover UI, no polling. The rest of the file — and `MainWindow.xaml` — is untouched. ### Linked brightness While linked brightness is on, a notch has to move the whole group, so it goes through `MainViewModel.LinkedBrightness` rather than the individual monitor setters. The new master value is taken from the planner's value for the monitor the wheel named, **not** from the current master. The master is positional only — `SeedInitialLinkedBrightness` takes it from the lowest-numbered linked monitor and never writes hardware, and every monitor-list rebuild re-seeds it — so it can sit arbitrarily far from the monitor the wheel is aimed at. Stepping it relative to itself would apply a wrong-sized or wrong-signed change, and a master already clamped at 0/100 would swallow the notch while writing nothing at all. The setting description calls out that linked brightness widens the scope, so `Primary display` is not literally a single display while it is on. ### What is deliberately not here An earlier revision of this PR showed the target and percentage in a custom overlay as you scrolled. Doing that meant the standard Shell tooltip would not do (it cannot be shown on demand), which meant an own window, which meant suppressing the Shell tooltip so the two did not collide, which meant `NOTIFYICON_VERSION_4`, which changed the callback packing and made the app responsible for all hover text — including for keyboard and touch users, who never reach a cursor-anchored overlay and would have been left with no visible tooltip at all. That chain was about half the diff, for a readout that adds little on top of watching the screen change. It is gone. If a readout is wanted later it can be argued on its own merits, separately from this feature. The same revision also gated the flyout sliders on this setting. That bundled two unrelated things behind one switch — turning off tray scrolling would also have stopped the contrast and volume sliders responding to the wheel — so the setting is now scoped to the tray icon and named accordingly. An earlier revision also routed the tray **Exit** action through `Shutdown()`. That fixes a pre-existing teardown leak which has nothing to do with this feature, so it now lives in #49580 and is out of scope here. This branch does not depend on it: the hook thread is a background thread and the process is ending either way. ## Validation Steps Performed - Unit tests: `PowerDisplay.Lib.UnitTests` 215 passed, `Settings.UI.UnitTests` 165 passed. - Builds: `PowerDisplay` and Settings UI, x64 Debug, no warnings. - Automated coverage is in `PowerDisplay.Lib.UnitTests`: target selection per mode, wheel accumulation including negative deltas, partial notches and direction reversal, half-open rectangle containment, and settings serialization and round-trip for the new mode, including that a settings file predating the feature loads as `Off`. `Settings.UI.UnitTests` covers the view-model index mapping and pins the enum values to the ComboBox item order. - The Win32 glue in `TrayIconService` and `TrayIconMouseWheelListener` is not unit tested. Manual passes performed: scrolling over the icon in both modes, the icon parked in the notification overflow, high-resolution wheel input, brightness boundaries, live monitor refresh while hovering, tray icon hidden and re-enabled, Explorer restart, the context menu and left-click, `Off` stopping tray scrolling while the flyout sliders keep working, and confirming a notch that Power Display will not act on still reaches the window under the cursor. Not verified, needing hardware this branch has not been run on: - Multiple taskbars, where the tray icon is on a secondary display and `Primary display` mode adjusts a monitor the user may not be looking at. - Mixed-DPI setups, for the `Shell_NotifyIconGetRect` rectangle and the hook's physical-pixel hit test. --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Copilot-Session: 5d7f36fe-d175-4aa9-a3c7-b370d952d1d3 |
||
|
moooyo
|
3cb3bdcd34 |
PowerDisplay: Reuse the values the max-compatibility probe already read (#49596)
## Summary of the Pull Request In Maximum compatibility mode, when a monitor's capabilities string is unusable, discovery probes each continuous VCP code directly to find out which ones the panel implements — and then **throws the values away**. `BuildMonitorFromPhysical` immediately re-reads every one of those codes. That doubles the I2C traffic on exactly the hardware that cannot take it, and the re-read is the one whose result the user actually sees: a panel that answered the probe a moment ago but fails the re-read shows its brightness slider parked at the never-read default instead of where the panel really is. This makes the probe's values survive into the build stage. Extracted from #49445, which bundles it with a persisted discovery cache it does not depend on. ## PR Checklist - [ ] Closes: #xxx — partially addresses #49342; the remaining cause is in #49445 - [ ] **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 — this PR adds none - [ ] **Dev docs:** Added/updated - [x] **New binaries:** Added on the required places — none added; no new project, so no signing JSON, installer WXS or CI YML change is required - [ ] **Documentation updated** ## Detailed Description of the Pull Request / Additional comments ### What the re-read costs Worth being precise about, because it is not the slider's *existence*: | decided by | set from | affected by a failed re-read | | --- | --- | --- | | slider visible (`MonitorViewModel.ShowBrightness`) | `Monitor.Capabilities`, via `UpdateMonitorCapabilitiesFromVcp` before the initializer runs | no | | slider position (`Monitor.CurrentBrightness`) | the read | yes — stays at the never-read default | | `powerdisplay get` reporting a live reading (`Monitor.ReadValues`) | the read | yes — reported as unknown | | relative `powerdisplay adjust` (`AdjustCommandExecutor`) | `Monitor.ReadValues` | yes — no before-value to adjust from | So the flyout keeps the control either way; what the second read decides is whether it is pointed anywhere real, and whether the CLI will admit to a value. Halving the transactions on a bus that is both slow and, on this hardware, unreliable is the other half of the win. ### The seam `FetchCapabilitiesWithFallbackAsync` used to return `(string capsString, VcpCapabilities? caps)` — capabilities only, no values. It now returns a `VcpDiscoveryEvidence`, which carries the same two things plus the values the probe already read and a flag for a handle that died mid-probe. `VcpDiscoveryEvidence.Reconcile` folds the probe observations into the parsed capabilities in one place: | observation | capabilities | value carried | | --- | --- | --- | | read succeeded | code marked supported | yes | | device replied, range unusable (e.g. `max=0`) | code marked supported | no — the initializer still owes it a read | | no reply | unchanged | no | | handle-class failure | everything discarded | — | The second row is why membership keys off `Replied` rather than the value being usable: an unimplemented code fails with `DDCCI_VCP_NOT_SUPPORTED` and never sets the flag, so a reply proves the opcode exists even when the reported range cannot scale a percentage. That is the same rule `BuildCapabilitiesFromProbe` used before this PR; it just moves next to the value handling. Like that method, `Reconcile` iterates the observations rather than `NativeConstants.ContinuousVcpCodes`, which `VcpFeatureProbeService` only takes as the default for its constructor-injected sweep list. That keeps a widened sweep from silently dropping a code that answered, but it is not sufficient on its own: the carried value is consumed only for codes `ContinuousVcpInitializer` walks, so widening the sweep still needs a matching edit there. The comment and `Reconcile_ProbedCodeOutsideTheDefaultSweepIsStillHonoured` both say so rather than claiming the seam alone covers it. On the normal path nothing changes: the probe only runs when the caps string is unusable, so `live` is empty and `Reconcile` is a pass-through. `Reconcile_ParsedCapabilitiesSurviveWhenNoProbeRan` pins that. ### Continuous-VCP initialization moves out of the controller `DdcCiController` carried six near-identical `Initialize*` methods. The three percent-scaled ones become **`ContinuousVcpInitializer`** — brightness, contrast, volume. It skips any code the evidence already has a value for, and returns `false` when a read fails with a handle-class error, because `Monitor.Handle` is captured once per discovery pass and never refreshed: a monitor kept alive on a dead handle would send every later read and write into the void. It reads through the `IVcpFeatureReader` seam introduced in #49579, so it is testable without hardware. The three discrete-enum ones — color preset, input source, power mode — stay in `DdcCiController`, unchanged. The probe sweeps only `NativeConstants.ContinuousVcpCodes`, so no discrete value is ever carried across the seam and extracting them would be a refactor this change does not need; see *What is deliberately left out*. Only the continuous stage discards the monitor. That is a policy choice, not a property of the stage: losing a whole display because `0xD6` answered badly is worse than showing it without a power control. `DdcCiController.TryGetVcpFeature` therefore still has three discovery callers plus `GetVcpFeatureAsync`, the runtime refresh path. ### Behaviour change outside Maximum compatibility mode **A handle-class error during continuous VCP initialization now discards the monitor.** Before, the failure was logged, the read flag left unset, and the monitor kept — so its handle reached `PhysicalMonitorHandleManager` and every later operation went to a handle already known to be dead. The cost is that the monitor stays out of the flyout until a rediscovery: `DisplayChangeWatcher` schedules one for device-arrival/removal and console-display-state notifications, and the flyout's Refresh button forces one on demand. Note this check is not on every path. A caps string that parses but advertises none of `0x10`/`0x12`/`0x62` leaves `ContinuousVcpInitializer` nothing to read and suppresses the probe, so such a monitor is still published with a handle no VCP read has exercised — and its first VCP read then happens in the discrete stage, which never discards. ### What is deliberately left out **Extracting the discrete-VCP initialization.** The probe sweeps only the continuous codes, so no discrete value is ever reused and moving `0x14`/`0x60`/`0xD6` out of the controller would be a drive-by refactor with no bearing on this change. It is worth doing on its own, where the added test coverage can be reviewed for what it is. **Remembering a probe value across discoveries.** A probe value is only useful for the pass that produced it. Carrying one forward — so a later failing pass can still show the control — is the persisted known-good cache in #49445, a much larger change with an open design question attached. This PR is complete without it. ## Validation Steps Performed - built `PowerDisplay.Lib.UnitTests` and `PowerDisplay` for x64 Debug with VS MSBuild — 0 errors, 0 warnings - ran `PowerDisplay.Lib.UnitTests.dll` with `vstest.console.exe`: **240 passed, 0 failed** — 16 of those cases are added here (8 in `ContinuousVcpInitializerTests`, 7 in `VcpDiscoveryEvidenceTests`, 1 in `DdcErrorClassifierTests`) - `VcpDiscoveryEvidenceTests` pins each row of the table above, plus that a probed code outside the default sweep is still honoured - `ContinuousVcpInitializerTests` pins that a probed code is never re-read (the reader is primed with a failure it must not reach), that a handle-class error stops the remaining codes, and that a feature-level refusal does not. `Initialize_EveryContinuousCodeIsReadAndApplied` walks the whole `ContinuousVcpCodes` array with a distinct range and percentage per feature, so a code added to that array without an arm in both `IsSupported` and `ApplyValue` fails rather than being silently skipped or silently discarded — checked by mutation: removing either volume switch arm fails that test and `Initialize_ProbedVolumeIsAppliedWithoutReadingAgain` - not covered by tests: the `DdcCiController` side of the contract — that `evidence.IsPhysicalMonitorUnavailable` skips the monitor and releases the physical, and that a `false` from `ContinuousVcpInitializer` does the same. That layer takes no injectable dependencies today - no hardware validation performed: this path is reachable only on a panel whose capabilities string is unusable, which needs an incomplete or unreliable DDC/CI implementation --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> |
||
|
Clint Rutkas
|
bb99c30edc |
New module: AltWindowCycle (#48281)
## Summary of the Pull Request Introduces a new utility: AltWindowCycle to quickly switch between windows from the same process using Alt + `. In release notes give @wzhudev coauthor credits as he also had an earlier PR It works like Alt + Tab, but scoped to the app you’re already in. Perfect for juggling multiple browser windows, terminals, or editor instances. https://github.com/user-attachments/assets/cd42f6af-fa5d-4f08-8f68-3c4e75c16d94 <img width="1835" height="971" alt="image" src="https://github.com/user-attachments/assets/adea59cb-6c8d-4b44-87e2-0a792c4c0b4f" /> ## PR Checklist - [x] Closes: https://github.com/microsoft/PowerToys/issues/278 - [ ] **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 This PR adds AltWindowCycle (in-proc module + Settings integration), then addresses follow-up check-spelling feedback without changing runtime behavior: - allow-list update for `ROOTOWNER` - comment text adjustment for forbidden-pattern compliance - local identifier rename (`wpx` → `whitePx`) for spelling compliance ## Validation Steps Performed - Verified `ROOTOWNER` is present in `.github/actions/spell-check/allow/code.txt` - Verified `wpx` is removed and updated occurrences in `src/modules/AltWindowCycle/AltWindowCycle.cpp` - Ran targeted diff/verification for both updated files - Ran final validation (code review + CodeQL trivial-change path) - Ran secret scan for changed files --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Clint Rutkas <crutkas@users.noreply.github.com> Copilot-Session: dd5080ea-5001-4efb-87f8-1e7218e10a4e |
||
|
Mike Griese
|
331f88a1a0 |
CmdPal: bump to 0.12 (#49586)
title |
||
|
Clint Rutkas
|
ffc839afea |
[PowerAccent] Fix injection hygiene and reset state on hide (#48572)
## Summary Keeps Quick Accent-injected keys from retriggering centralized shortcuts and clears native keyboard-listener state whenever the toolbar closes. ## What this changes - Tags backspace, Unicode, and arrow `SendInput` events with `dwExtraInfo = 0x110`, mirroring `CENTRALIZED_KEYBOARD_HOOK_DONT_TRIGGER_FLAG`. - Uses the existing `SendArrowKey(bool)` implementation as the single arrow-injection path, preserving `KEYEVENTF_EXTENDEDKEY` on key-down and key-up. - Checks the number of events sent by every `SendInput` call and logs incomplete sends. - Adds `ForceReset()` to the keyboard service WinRT API and invokes it from the core hide path immediately before `OnChangeDisplay(false)`. - Keeps listener state non-atomic because the low-level hook is installed on the WinUI thread and its callbacks execute on that same thread, as documented by `MainWindow.RunOnUiThread`. ## Testing - Built `PowerAccent.Core.csproj` in Release x64, including `PowerAccentKeyboardService`. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 122a9176-ce18-437c-8af4-c39f83fb2fa6 |
||
|
Mike Griese
|
70e0fc2295 |
CmdPal: when expanding compact mode, don't be too tall (#49532)
If you open command palette on one display and resize its expanded size to be very tall, then you move command palette to a monitor that is not that tall and expand it, we will still expand our control to fit the full size of our HWND, which is taller than this new monitor. This PR fixes that by making sure to measure the size that's available on the current monitor and limit the max height of our control when we're expanding it, so that the bottom of the control always fits on the current monitor. Closes: not filed I don't think |
||
|
chakrik73
|
7d1dde7aa5 |
[ZoomIt] Port recording/editing features from Mac ZoomIt (trim editor, snip-to-clipboard, recording border) and fix video trim reliability (#49553)
## Summary of the Pull Request Ports several recording and editing features from the Sysinternals **Mac ZoomIt** into the Windows PowerToys ZoomIt module, and hardens the video **trim/save** pipeline against a sporadic "Failed to trim the video" failure. Highlights: - **Video trim editor — interior "Delete Region" editing.** In the post-recording trim dialog you can now select and delete interior segments (not just trim the head/tail). Includes red timeline overlays with drag grips, right-drag to select, `Delete` to remove, `Ctrl+Z` to undo, and `Esc` to cancel a pending selection. - **Reliable trim/render.** Fixed a sporadic *"Failed to trim the video"* error. The live capture pipeline produces **fragmented** MP4s (moof/mdat) that play in preview but fail `MediaComposition` render/seek with `0xC00DA7FC`. The render path now (a) sources resolution from the clip's encoding properties first, (b) retries transient failures (0×0 dimensions from a fragmented-MP4 metadata race, `!CanTranscode()`, post-remux render failure), and (c) remuxes fragmented MP4s to a standard seekable MP4 via `MediaTranscoder` before rendering. - **Snip → Copy to clipboard.** New ZoomIt setting to copy a snip directly to the clipboard. - **Recording border color.** The screen-recording selection border now uses a distinct color, and turns orange while recording is active. - **GIF recording robustness.** First-frame timeout so GIF capture doesn't hang when no frames arrive. - **Audio hardening.** Stereo downmix handling and defensive guards in the audio sample generator. - **Opt-in diagnostics.** Recording diagnostics (`[RecDiag]`) are gated behind a registry DWORD `HKCU\Software\Sysinternals\ZoomIt\EnableDebugTrace` (off by default), and all module debug output is prefixed with `[ZoomIt]` for easy filtering in DebugView. - **Fix:** GDI bitmap leak in the snip-to-clipboard path when `SetClipboardData` fails. ## PR Checklist - [ ] **Tests:** ZoomIt is native Win32/WinRT with no unit-test harness; validated manually (see Validation Steps) - [ ] - [x] **Localization:** All end-user-facing strings can be localized <!-- new strings added to Settings.UI en-us Resources.resw --> - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** N/A: no new binaries/projects - [ ] JSON for signing — N/A - [ ] WXS for installer — N/A - [ ] YML for CI pipeline — N/A - [ ] YML for signed pipeline — N/A - [ ] **Documentation updated:** N/A ## Detailed Description of the Pull Request / Additional comments Files changed (17): **ZoomIt module (native)** - `VideoRecordingSession.cpp/.h` — interior delete-region trim editor; render/trim reliability (resolution from clip encoding properties, retry loop, fragmented-MP4 → seekable remux); registry-gated `[RecDiag]` diagnostics. - `GifRecordingSession.cpp` — first-frame timeout / no-frames handling. - `AudioSampleGenerator.cpp` — stereo downmix + defensive guards. - `SelectRectangle.cpp/.h`, `PanoramaCapture.cpp` — recording border color parameter. - `Zoomit.cpp` — snip → clipboard workflow; GDI bitmap leak fix on `SetClipboardData` failure. - `ZoomItSettings.h`, `ZoomIt.h`, `ZoomIt.rc`, `resource.h` — new setting + "Delete Region" button + message id. - `pch.h` — `[ZoomIt]` debug-output prefix wrapper. **Settings UI** - `ZoomItProperties.cs`, `ZoomItViewModel.cs`, `ZoomItPage.xaml`, `Resources.resw` — "Copy snip to clipboard" setting and localized strings. Note: ZoomIt is a Sysinternals port kept in its upstream code style, so it is intentionally exempt from the repo `.clang-format` (changed lines follow the surrounding Sysinternals convention). ## Validation Steps Performed Manual validation (no automated ZoomIt harness): - **Trim reliability:** Recorded multiple clips and used Trim → Save repeatedly (including 3-clip compositions produced by Delete Region); render now succeeds consistently (previously failed sporadically with "Failed to trim the video"). - **Delete Region editor:** Right-drag to select an interior segment, `Delete` to remove, `Ctrl+Z` to undo, `Esc` to cancel; saved output reflects the removed segments. - **Snip → clipboard:** Enabled the new setting; snip is placed on the clipboard and pastes correctly. Verified no GDI handle leak when clipboard set fails. - **Recording border:** Verified border color and the orange active-recording state (full-monitor and region). - **GIF:** Confirmed capture no longer hangs when no frames arrive. - **Diagnostics:** With `EnableDebugTrace` unset, no `%TEMP%\ZoomIt_RecDiag.log` and no `[RecDiag]` output; with it set to `1`, `[ZoomIt] [RecDiag ...]` traces appear. - **Style checks:** XamlStyler (clean), StyleCop via building `Settings.UI.Library` and `PowerToys.Settings` (no `SA####` warnings), ZoomIt x64 Release builds with exit code 0. |
||
|
Mike Griese
|
5803bc7ec5 |
BUILD: Fix the version.vcxproj FastUpToDate check (#49534)
This has been my personal enemy for a year now. VS will skip doing work for your build if it thinks everything is up-to- date. But this version project has been treated as dirty for a long time now. What that means is that incremental builds (READ: dev inner loop builds) end up building the world CONSTANTLY. Because VS thinks FOR SOME REASON that this project needs to rebuild. By setting the `Inputs`/`Outputs` for this `Target`, VS is smart enough to only re-run the task if the inputs actually changed since the last build. Tested by building the code, then building again, and observing that all the projects were successfully noted as up-to-date drive-by: fix some of the other `csproj` files for cmdpal. Closes #45296 |
||
|
moooyo
|
4b3f961b12 |
[PowerDisplay] Run the tray Exit through Shutdown so teardown is not skipped (#49580)
## Summary of the Pull Request PowerDisplay's tray context menu **Exit** ended the process with `Environment.Exit(0)`, skipping the teardown that `App.Shutdown()` already performs. Point it at `Shutdown()` instead — a one-line change. What Exit was skipping: - `TrayIconService.Destroy()` — `Shell_NotifyIcon(NIM_DELETE)`, the icon and popup-menu handles, and restoring the subclassed window procedure. Without the `NIM_DELETE`, the notification area can keep showing a stale PowerDisplay icon until the Shell next validates it, which in practice is when the pointer passes over it. - `MainWindow.Dispose()` — which cancels the CLI named-pipe server's `CancellationTokenSource` and disposes the hotkey service, the message hook and `MainViewModel` (monitor manager, display-change watcher, per-monitor view models). `Environment.Exit` does not run finalizers, so none of that happened by another route. The named-pipe terminate message (`PowerDisplayTerminateAppMessage`) has always gone through `Shutdown()`, so this only makes the tray menu agree with a path that is already shipping. The tray menu command is dispatched from the subclassed main-window procedure, so it already runs on the UI thread that owns these objects, and `Shutdown()` still ends with `Environment.Exit(0)` — the process exits unconditionally either way. ## PR Checklist - [ ] Closes: #xxx — no filed issue. Found while working on #49410; split out so it can be reviewed on its own. - [ ] **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 — none added. The change is process-exit wiring inside `App.OnLaunched`, which has no test harness; validated manually. - [x] **Localization:** All end-user-facing strings can be localized — no new or changed strings. - [ ] **Dev docs:** Added/updated — no doc change warranted for a one-line teardown fix. - [ ] **New binaries:** Added on the required places — none. - [ ] **Documentation updated:** no user-facing behaviour change. ## Detailed Description of the Pull Request / Additional comments ### Deliberately not in scope Two other paths still call `Environment.Exit(0)` directly, and both are pre-existing and unchanged here: - The runner **Terminate** event (`Constants.TerminatePowerDisplayEvent()`) — the module-disable and PowerToys-exit path. Its callback is already marshalled to the UI thread by `NativeEventWaiter`, so it *could* be routed the same way, but adding teardown work to the runner's shutdown path should be validated against the runner's shutdown timeout on its own rather than riding along with a tray-menu fix. - The `RunnerHelper.WaitForPowerToysRunner` watchdog, whose callback runs on a background thread and would need marshalling to the UI thread first. Happy to follow up on either if reviewers would rather see them fixed together. ## Validation Steps Performed - Tray icon → right-click → **Exit**: PowerDisplay exits, the notification icon disappears immediately rather than lingering until hover. - Re-launch from PowerToys Settings after a tray Exit: the tray icon comes back once, not twice. - `powerdisplay` CLI still works after a launch/tray-Exit/launch cycle, confirming the named pipe was released rather than left to process teardown. - Existing terminate paths unchanged: disabling PowerDisplay in Settings and quitting PowerToys both still exit the process. Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> |
||
|
moooyo
|
bc2d09abe8 |
PowerDisplay: Pace and retry the maximum-compatibility VCP probe (#49579)
## Summary of the Pull Request In Maximum compatibility mode, when a monitor's capabilities string is missing or unparsable, discovery falls back to probing each continuous VCP code directly. That probe issues **one** `GetVCPFeatureAndVCPFeatureReply` per code, back to back, and treats any failure as final. On a panel whose DDC/CI engine answers intermittently, a single transient I2C fault permanently drops that control for the whole discovery pass — and if every code happens to fault, the monitor disappears from the flyout entirely. This replaces the probe with `VcpFeatureProbeService`: - **paced** — 100 ms between transactions, instead of hammering the I2C bus back to back - **retried** — up to 3 attempts, but only for failures another attempt can plausibly get past - **classified** — `DdcErrorClassifier` decides what "transient" means, so the retry budget is not burned on a definitive `DDCCI_VCP_NOT_SUPPORTED` or on a dead physical-monitor handle - **aborted early** — a handle-class error stops the remaining codes rather than issuing more requests against a handle already known to be invalid Extracted from #49445, which bundles this with a persisted discovery cache and a discovery restructure it does not depend on. This piece stands alone and addresses one of the root causes in #49342 by itself. ## PR Checklist - [ ] Closes: #xxx — partially addresses #49342; the remaining causes are in #49445 - [ ] **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 — this PR adds none - [ ] **Dev docs:** Added/updated - [x] **New binaries:** Added on the required places — none added; no new project, so no signing JSON, installer WXS or CI YML change is required - [ ] **Documentation updated** ## Detailed Description of the Pull Request / Additional comments ### What is and is not retried `DdcErrorClassifier` names the DDC/CI error codes after `winerror.h` and splits them into two sets. `DdcErrorClassifierTests` pins both the membership of each set **and** the numeric value of every constant against `winerror.h`, so a typo cannot move production and tests together and leave the suite green. Retried — framing, arbitration and timing faults on the I2C bus: `I2C_ERROR_TRANSMITTING_DATA`, `I2C_ERROR_RECEIVING_DATA`, `DDCCI_INVALID_DATA`, `MCA_INTERNAL_ERROR`, `DDCCI_INVALID_MESSAGE_COMMAND`, `DDCCI_INVALID_MESSAGE_LENGTH`, `DDCCI_INVALID_MESSAGE_CHECKSUM`, `DDCCI_CURRENT_CURRENT_VALUE_GREATER_THAN_MAXIMUM_VALUE`, `ERROR_TIMEOUT`. Not retried, each for a stated reason recorded on the predicate: `DDCCI_VCP_NOT_SUPPORTED` is the device's final answer; `I2C_NOT_SUPPORTED` and `I2C_DEVICE_DOES_NOT_EXIST` are permanent bus-level facts; `MCA_INVALID_CAPABILITIES_STRING` belongs to the capabilities path, not to a VCP read; and the two handle-class codes must abort rather than retry. ### Behaviour preserved `FetchCapabilitiesWithFallbackAsync` keeps its signature and still returns `(string, VcpCapabilities?)`, so nothing outside the probe changes. `BuildCapabilitiesFromProbe` synthesizes the same shape `DdcCiNative.ProbeSupportedVcpFeatures` used to, and decides membership the same way: a code counts as supported when the device *replied*, not when the value was usable. A reply proves the opcode is implemented even if the reported range cannot scale a percentage — an unimplemented code fails with `DDCCI_VCP_NOT_SUPPORTED` instead. The set of probed codes moves from a private array in `DdcCiNative` to `NativeConstants.ContinuousVcpCodes`, where the follow-up work in #49445 also needs it. ### Cost The probe only runs in Maximum compatibility mode, and only when the capabilities string is already unusable — so this adds no I2C traffic to a monitor that parses normally. For a monitor that does reach it, the worst case grows from 3 transactions to 9 plus 900 ms of pacing, and it is bounded: a definitive refusal stops after one attempt, and a handle-class error stops the whole probe. ### What is deliberately left out The probe's values are still discarded — `BuildMonitorFromPhysical` re-reads each code immediately afterwards. Reusing them needs a carrier for the observed value, which is `VcpDiscoveryEvidence` in #49445. `VcpFeatureProbeService` already returns everything that needs (`VcpProbeObservation` carries the value, the attempt count and the last error); this PR simply does not consume it yet. ## Validation Steps Performed - built `PowerDisplay.Lib.UnitTests` for x64 Debug with VS MSBuild — 0 errors, 0 warnings - ran `PowerDisplay.Lib.UnitTests.dll` with `vstest.console.exe`: **223 passed, 0 failed** (186 on `main` + 37 added here) - `VcpFeatureProbeServiceTests` drives the pacing, the retry budget, the transient/definitive split, cancellation before and during the inter-transaction delay, a throwing native read, and that reads run off the caller's thread — all through an injected reader and an injected delay, so no hardware is needed - no hardware validation performed: reaching this path needs a panel whose capabilities string is unusable **and** whose VCP reads fail intermittently --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> |
||
|
Gordon Lam
|
efc0258cda |
Validate the update installer before PowerToys.Update launches it (#48903)
## Summary PowerToys' self-updater downloads the installer into `%LOCALAPPDATA%\Microsoft\PowerToys\Updates` and then launches it from `PowerToys.Update.exe` (Stage 2). This makes that launch path more robust: - Open the downloaded installer with a read-only share so the file stays consistent while we inspect and run it. - Confirm it is a valid, Authenticode-signed **Microsoft** PowerToys installer (valid signing chain + Microsoft organization) before executing it. This single chokepoint covers both freshly downloaded and previously downloaded installers. - If the check does not pass, log and skip the launch instead of running an incomplete or invalid file. ## Implementation - Added `updating::verify_installer_trust` to the shared `common/updating` library (`installer.h` / `installer.cpp`): `WinVerifyTrust` for the signing chain, and `CryptQueryObject` / `CertGetNameString` to confirm the signer's organization is `Microsoft Corporation`. `Wintrust.lib` / `Crypt32.lib` are linked via `#pragma comment(lib, ...)`. - `InstallNewVersionStage2` opens the installer with `FILE_SHARE_READ`, verifies it, and keeps the handle open across `MsiInstallProductW` / the bootstrapper launch so the file stays stable during install. ## Validation - `ApplicationUpdate` and `PowerToys.Update` build clean (x64 Debug). - Existing updating unit tests pass (30/30). - Checked end-to-end against real binaries: a Microsoft Authenticode-signed binary is accepted; a corrupted copy and an unsigned file are both declined. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Muyuan Li <muyuanli@microsoft.com> Co-authored-by: Boliang Zhang (from Dev Box) <bozhang@microsoft.com> Copilot-Session: d168a794-8cce-483d-9c46-10787893dbe2 |
||
|
moooyo
|
af5665eaa8 |
PowerDisplay: Always write the saved value when restoring monitor settings (#49577)
## Summary of the Pull Request `TryRestore` skipped writing a saved monitor value when it already equalled the value `MonitorViewModel` was showing. That displayed value is only an observation when the discovery-time VCP read succeeded. When the read failed it is a placeholder: | setting | value when the read failed | source | | --- | --- | --- | | brightness | `50` | `MonitorDiscoveryHelper` stamps it — *"Initial placeholder; overwritten if the VCP read succeeds"* | | contrast | `50` | `Monitor` backing-field default | | volume | `50` | `Monitor` backing-field default | | color temperature | `0x05` (6500K) | `Monitor` backing-field default | A saved value that happened to equal one of those silently suppressed the restore, and the monitor kept whatever it powered on with. `50` is the mid-slider value and `0x05` is the most common preset, so the coincidence is not rare. This drops the comparison: a restore now always writes. ## PR Checklist - [ ] Closes: #xxx — no issue; found while splitting up #49445 - [ ] **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 — none added; `TryRestore` is a private helper in the `PowerDisplay` app project, which has no test project - [x] **Localization:** All end-user-facing strings can be localized — this PR adds none - [ ] **Dev docs:** Added/updated - [x] **New binaries:** Added on the required places — none added; no new project, so no signing JSON, installer WXS or CI YML change is required - [ ] **Documentation updated** ## Detailed Description of the Pull Request / Additional comments ### Why remove the check rather than refine it The skip-if-equal check dates from PowerDisplay's first commit (#42642, where it read `// Restore brightness if different from current`); #47051 only refactored it into the shared `TryRestore` helper. It is day-one "obviously we shouldn't write twice" code, not a response to a reported problem. Removing it is correct by construction: with no skip branch there is no state in which a restore silently does nothing. Any narrower fix has to decide *when* the displayed value can be trusted, and gets that decision wrong in exactly the cases that are hardest to reproduce. ### Cost Two, both bounded: - **A redundant VCP write when the monitor already sits at the saved value.** Some panels surface a write on their OSD. Both paths that reach here are user-initiated: startup restore only runs when `RestoreSettingsOnStartup` is enabled, and a profile apply happens because the user invoked that profile. - **Time.** At most four writes per monitor, serialised on that monitor's I2C bus (~100 ms each). Monitors still run in parallel through the existing `Task.WhenAll`. The `isVisible` guard is untouched, so a monitor still never receives a write for a feature it does not expose — an unsupported VCP `0x14` is not written just because a profile carries a color temperature. Input source and power state are not restored here at all. ### If the redundant write turns out to matter The narrower fix is to keep the comparison and add one clause: also write when `(monitor.ReadValues & flag) != flag`, i.e. when the compared value was never read off the hardware. `MonitorReadFlags` already carries exactly that information, and `Monitor.ReadValues` is already maintained by the discovery-time `Initialize*` methods, so it is a small change on top of this one. I went with the simpler version first — happy to switch if a maintainer would rather keep the optimisation. ## Validation Steps Performed - built `PowerDisplay` and `PowerDisplay.Lib.UnitTests` for x64 Debug with VS MSBuild — 0 errors, 0 warnings - ran `PowerDisplay.Lib.UnitTests.dll` with `vstest.console.exe`: **186 passed, 0 failed** — unchanged from `main`; this PR touches only the app project and adds no tests - no hardware validation performed: the placeholder path this PR fixes is reachable only on a monitor whose VCP read fails during discovery Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> |
||
|
moooyo
|
32f738bd45 |
PowerDisplay: Release physical-monitor handles that discovery abandons (#49578)
## Summary of the Pull Request `DdcCiController.DiscoverFromHandleAsync` abandons a physical monitor on three paths without destroying its handle. Handles only reach `PhysicalMonitorHandleManager` through monitors that were successfully built: the map is rebuilt from the returned monitor list, and its cleanup pass only destroys handles that were in the *previous* map. A handle dropped on an abandon path therefore never gets destroyed. A discovery runs on every display-topology change, so a monitor that keeps failing leaks one more handle per discovery for the process lifetime — a docking-station user accumulates them. Extracted from #49445, where the same fix is bundled with maximum-compatibility-mode work it does not depend on. ## PR Checklist - [ ] Closes: #xxx — no issue; extracted from #49445 - [ ] **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 — none added; rationale below - [x] **Localization:** All end-user-facing strings can be localized — this PR adds none - [ ] **Dev docs:** Added/updated - [x] **New binaries:** Added on the required places — none added; no new project, so no signing JSON, installer WXS or CI YML change is required - [ ] **Documentation updated** ## Detailed Description of the Pull Request / Additional comments ### The three leaking paths | path | before this PR | | --- | --- | | more physical monitors than `QueryDisplayConfig` entries for the GDI name | `break` leaves `physicals[i..]` unreleased — the whole tail, not just the current one | | capabilities unavailable | `continue` | | `BuildMonitorFromPhysical` returned null (construction failed, or it threw and was caught) | no `else` branch at all | `ReleaseAbandonedPhysical` is null-handle safe and swallows a failing `DestroyPhysicalMonitor` at warn level: one handle that cannot be destroyed must not take down the rest of the discovery pass. ### Why there are no tests Reaching these call sites means faking the whole native enumeration surface — `EnumDisplayMonitors`, `GetMonitorInfo`, `GetPhysicalMonitorsFromHMONITOR` — which is a larger seam than a one-file leak fix should introduce. The paths were verified by reading instead. Happy to add the seam if a maintainer would rather have it covered. ### Known remaining leaks, deliberately out of scope - `GetPhysicalMonitorsWithRetryAsync`'s retry loop discards a whole array of live handles when it retries after seeing NULL handles. - Cancellation unwinds `DiscoverMonitorsAsync` before `UpdateHandleMap` runs, so that pass's handles never enter the map and are never destroyed. Both predate this change and are better addressed separately. ## Validation Steps Performed - built `PowerDisplay.Lib` and `PowerDisplay.Lib.UnitTests` for x64 Debug with VS MSBuild — 0 errors, 0 warnings - ran `PowerDisplay.Lib.UnitTests.dll` with `vstest.console.exe`: **186 passed, 0 failed** — no new tests; this only confirms nothing regressed - no hardware validation performed: reaching an abandon path needs a monitor whose capabilities fetch fails or whose construction throws Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> |
||
|
Noraa Junker
|
135291d456 |
[Shortcut Guide] Add Less Than and greater than characters and fix crash if key is empty or invalid (#49562)
<!-- 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: #49558 <!-- - [ ] 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 - [x] **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 |
||
|
Anthony Thompson
|
e6bbf4428e |
docs: add Quick Shell to third-party Run plugins (#49567)
## Summary Adds [Quick Shell](https://github.com/tonythethompson/QuickShell) to the community PowerToys Run plugins list. - **Plugin:** Quick Shell (`qs` keyword) - **Author:** [tonythethompson](https://github.com/tonythethompson) - **Description:** Open saved project folders in any terminal; shared shortcuts with the Quick Shell Command Palette extension ## Install - WinGet (bundled CmdPal + Run): `winget install tonythethompson.QuickShell` - Run-only ZIP: [`QuickShell.Run-x64.zip`](https://github.com/tonythethompson/QuickShell/releases/latest) / [`QuickShell.Run-ARM64.zip`](https://github.com/tonythethompson/QuickShell/releases/latest) - Run-only EXE: `QuickShellforRun-Setup-*-x64.exe` / `*-arm64.exe` from the same release Docs: https://github.com/tonythethompson/QuickShell/blob/master/docs/powertoys-run-plugin.md ## Validation - [x] Listed under General plugins - [x] Links to GitHub repo and author profile - [x] Release assets include Run plugin ZIP and installer Made with [Cursor](https://cursor.com) Co-authored-by: Anthony Thompson <> |
||
|
Clint Rutkas
|
d72fa2ea6e |
Update Monaco Editor from 0.47.0 to 0.52.2 (#48415)
## Summary of the Pull Request Updates the vendored Monaco Editor from 0.47.0 (Mar 2024) to 0.52.2 (Dec 2024). ## PR Checklist - [x] **Communication:** Discussed in #46692 review - [x] **Tests:** Headless-browser smoke tests pass (syntax highlighting, custom languages, context-menu hack, addAction registration) - [x] **Dev docs:** No doc changes needed (update process unchanged) ## Detailed Description ### What changed | Area | Detail | |------|--------| | `src/Monaco/monacoSRC/min/` | Replaced with `monaco-editor@0.52.2` from npm | | NLS layout | `editor.main.nls.*.js` / `simpleWorker.nls.*.js` removed upstream → `vs/nls.messages.*.js` added | | New language | `typespec` shipped upstream (+1 language, 100→101 total) | | `monacoSpecialLanguages.js` | Inline grammar snapshots (cpp/xml/razor/vb/ini/shell) refreshed from 0.52.2 shipped files | | `monaco_languages.json` | Regenerated; all PowerToys custom languages + extension mappings intact | ### Supply-chain verification - npm tarball SHA-512 verified against registry SRI: `sha512-GEQWEZmfkOGLdd3XK8ryrfWz3AIP8YymVXiPHEdewrUq7mh0qrKrfHLNCXcbB6sTnMLnOZ3ztSiKcciFUkIJwQ==` - Vendored tree hash-verified file-by-file (103 files, all match) ### Why 0.52.2 and not 0.55.1 (latest)? Monaco 0.53+ completely restructured the `min/` bundle: flat hashed chunks instead of per-language AMD modules, `vs/platform/actions/common/actions` removed, `vs/basic-languages/<id>/<id>` modules eliminated. PowerToys' `index.html` (context-menu stripping via MenuRegistry) and `monacoSpecialLanguages.js` (language cloning via AMD require) depend on these internals. **0.52.2 is the last release compatible without a glue-code rewrite.** The 0.55.x port is tracked separately. ## Validation Steps Performed - [x] Tarball SRI integrity verified against npm registry - [x] Vendored tree == tarball (SHA-256 per file, 103/103 match) - [x] `monacoSpecialLanguages.js` passes Node.js syntax check - [x] Headless smoke test (Edge via puppeteer-core): editor creates, tokenization paints (5+ classes), `addAction` entries register, `MenuRegistry` context-menu hack works - [x] Same smoke test passes identically on 0.47.0 baseline (no regressions) - [x] `monaco_languages.json`: 101 languages, all custom IDs present (reg, gitignore, srt, cppExt, xmlExt, txtExt, razorExt, vbExt, iniExt, shellExt) ## Related - Supersedes automation approach in #46692 (which has fatal bugs; will close separately) - 0.55.x port tracked as follow-up issue Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b6bd2181-eff3-4f2a-b25e-dcd1065ead6a |
||
|
Clint Rutkas
|
d127511c7d |
Fix runner APPLICATION_HANG_QUIESCE: handle WM_ENDSESSION and skip blocking shutdown cleanup (#48363)
## Summary The runner WndProc (`tray_icon_window_proc`) does not handle `WM_QUERYENDSESSION` / `WM_ENDSESSION`, **and** its `WM_DESTROY` teardown performs blocking cross-process cleanup. Both contribute to the Watson failure `APPLICATION_HANG_QUIESCE_cfffffff_PowerToys.exe!run_message_loop` on OS shutdown, sign-out, or restart: 1. Without a `WM_ENDSESSION` handler, `DefWindowProc` returns `0` without posting a quit message, so `run_message_loop` stays parked in `GetMessageW` until the OS quiesce timeout (~5 s) force-terminates the process. 2. Even once teardown starts, `WM_DESTROY` calls `close_settings_window()`, which blocks up to 1.5 s on `WaitForSingleObject` against `PowerToys.Settings.exe` (`src/runner/settings_window.cpp:712`), plus `Shell_NotifyIcon(NIM_DELETE)` during Explorer teardown. The Windows [shutdown guidance](https://learn.microsoft.com/windows/win32/shutdown/shutting-down) is explicit that handlers must not block. This PR fixes both issues for the always-on runner. Rollout to module-owned windows is intentionally separate and tracked in #49539. > Supersedes #48378 (same Watson bucket) by combining its no-blocking-cleanup fix with a reusable helper and unit tests. The cleanup-skip insight is credited to @yeelam-gordon. Related (same failure class, different binary): #41260. ## Root cause `src/runner/tray_icon.cpp` → `tray_icon_window_proc` had no case for `WM_QUERYENDSESSION` / `WM_ENDSESSION`, and `WM_DESTROY` unconditionally ran cross-process cleanup. On a full Windows session end, the OS delivers `WM_ENDSESSION` to child applications and reaps them independently, so the runner's waits consume the quiesce budget without helping shutdown complete. ## Fix ### 1. Explicitly stateless helper in `src/common/utils/window.h` `handle_stateless_session_end_message`: - `WM_QUERYENDSESSION` → returns `TRUE`. The name makes clear that this helper is only for processes with no unsaved user state. - `WM_ENDSESSION(TRUE)` → calls `DestroyWindow(window)`, driving the existing `WM_DESTROY → PostQuitMessage(0)` path so `run_message_loop` unwinds. - `WM_ENDSESSION(FALSE)` → leaves the window alone because another application cancelled shutdown. - The optional `out_system_session_ending` flag is set only when the full Windows session is ending. `ENDSESSION_CLOSEAPP` still closes the runner but leaves the flag false so Restart Manager requests retain normal child-process cleanup. Stateful modules must implement their own save/permission behavior rather than adopt this helper. `tray_icon_window_proc` calls it at the top of dispatch and returns immediately when the message is handled. ### 2. Skip blocking cleanup only for a full Windows session end `WM_DESTROY` branches on `g_system_session_ending`: - **User-initiated close or Restart Manager `ENDSESSION_CLOSEAPP`:** unchanged full cleanup (`Shell_NotifyIcon(NIM_DELETE)`, `close_settings_window()`, and `QuickAccessHost::stop()`). - **Full OS shutdown, sign-out, or restart:** posts `WM_QUIT` without waiting on child processes the OS is already reaping in parallel. ### Scope and follow-up This PR intentionally fixes the highest-volume contributor: the always-on runner. Native module processes with their own windows/message loops require module-specific review before adopting the pattern; that inventory and rollout is tracked in #49539. ### Why not centralize handling inside `run_message_loop`? `WM_QUERYENDSESSION` / `WM_ENDSESSION` invoke the WndProc directly during `GetMessage`; they do not appear as a `MSG` returned to the loop. Handling must therefore live in, or be called from, each relevant WndProc. ## Tests 8 focused tests in `src/common/UnitTests-CommonUtils/Window.Tests.cpp`: | Test | Guards | |---|---| | `HandleStatelessSessionEndMessage_QueryEndSession_AllowsShutdown` | `WM_QUERYENDSESSION` returns `TRUE`. | | `HandleStatelessSessionEndMessage_EndSessionCancelled_DoesNotTearDown` | `WM_ENDSESSION(FALSE)` does not destroy the window. | | `HandleStatelessSessionEndMessage_EndSessionConfirmed_TearsDownAndExitsLoop` | `WM_ENDSESSION(TRUE)` destroys the window and exits before the longer timer fallback. | | `HandleStatelessSessionEndMessage_UnrelatedMessage_NotHandled` | Unrelated messages fall through untouched. | | `HandleStatelessSessionEndMessage_EndSessionConfirmed_SignalsSystemSessionEnding` | A full session end enables the no-wait teardown path. | | `HandleStatelessSessionEndMessage_CloseApp_DoesNotSignalSystemSessionEnding` | Restart Manager closes the window while retaining normal child cleanup. | | `HandleStatelessSessionEndMessage_EndSessionCancelled_DoesNotSignalSystemSessionEnding` | Cancelled shutdown does not flag teardown. | | `HandleStatelessSessionEndMessage_QueryEndSession_DoesNotSignalSystemSessionEnding` | The query phase does not flag teardown. | **Build:** `runner.vcxproj` and `UnitTests-CommonUtils.vcxproj` build clean (`x64|Release`). The 8 focused tests pass. ## Manual validation 1. Build PowerToys and start the runner. 2. Initiate a sign-off (`logoff`) or restart. 3. Confirm Event Viewer (`Windows Logs → Application`) shows no `Application Hang` event for `PowerToys.exe`. 4. Right-click tray → Exit: confirm Settings.exe and the Quick Access host shut down gracefully and no ghost tray icon remains. (#48378 additionally captured real logoff/restart runs showing `WM_ENDSESSION → WM_DESTROY` completing in 1–8 ms with no hang events—the same full-session path used here.) ## Quality checklist - [x] Linked work item: AB#55588441 - [x] Module follow-up: #49539 - [x] Cross-references #41260; supersedes #48378 - [x] Unit tests (8 in `Window.Tests.cpp`) - [x] No new binaries - [x] Localization: no end-user strings changed - [x] Shared helper documents its stateless contract Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8d70b986-081a-43dd-bbfd-7e6351baef7a |
||
|
Clint Rutkas
|
6d89ade9ad |
Fix PT Run ThreadPool worker leak from stale query cancellation (#48394)
## Summary Fixes a ThreadPool worker leak in PowerToys Run that can eventually surface as `System.OutOfMemoryException` from `Thread.StartInternal` after rapid typing and repeated stale-query cancellation. Related: #36041 and duplicate reports #45704, #36587, #39942, #20264, and #8878. ## Root cause `MainViewModel.QueryResults` stored the active cancellation token in a mutable field. When a new query replaced that field, older workers could observe the new, non-cancelled token instead of the token belonging to their own query. The previous `CancellationTokenSource` was also disposed while its consumers could still be running. As stale queries accumulated, they continued invoking plugins and consuming ThreadPool workers until the process could no longer create another worker thread. ## Changes - Adds `QuerySession`, which owns one captured token and the complete task lifetime for a query. Superseded sessions are cancelled immediately and their token sources are disposed only after their work completes. - Uses a suspended session start so query state is published before workers can return results. - Adds generation checks before scheduling and applying work so superseded queries cannot enqueue stale plugin tasks or update current results. - Adds a per-plugin execution gate. Calls to the same plugin do not overlap, while unrelated plugins can execute independently; cancelled waiters do not occupy ThreadPool workers. - Preserves legacy `IResultUpdated` compatibility by correlating generation-0 events using `RawQuery`. - Preserves the original two-phase query contract: all non-delayed plugin queries complete and their results are applied before delayed queries start. Delayed queries remain globally parallel, and `noInitialResults` is computed from the complete non-delayed phase. - Cancels and performs a bounded wait for the active query during shutdown. ## Tests `Wox.Test`: **142/142 passing** locally. Coverage includes: - token ownership, cancellation, deferred disposal, shutdown timeout, and suspended session startup; - current-query generation matching and legacy generation-0 compatibility; - per-plugin execution gating and queued latest-query behavior; - deterministic verification that delayed queries cannot start until every non-delayed query completes. ## Manual validation 1. Hold a key in PowerToys Run for 10–15 seconds and confirm the PowerToys Run process thread count stabilizes instead of growing monotonically. 2. Exercise normal Calculator, file, web, and indexer queries. 3. Enable search query tuning and waiting for slow results; confirm results appear and final sorting completes. 4. Start a slow query and type again before it completes; only the newest query should update results. 5. Exit PowerToys with a query in flight; shutdown should complete cleanly without orphaned processes. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Copilot-Session: 54e1bb28-edae-496b-8211-0e1592ddc985 |
||
|
Clint Rutkas
|
44fd627c3a |
Tighten IContextMenu::GetCommandString in Image Resizer (#48399)
## Summary Corrects `IContextMenu::GetCommandString` handling in the Image Resizer shell extension. ## Changes - `GCS_VERBW` copies the Unicode canonical verb with `StringCchCopyW`, preserving copy failures. - Only `GCS_VALIDATEA` and `GCS_VALIDATEW` return `S_OK`. - ANSI verb requests, help-text requests, and unknown request types return `E_NOTIMPL`. - ANSI string verbs are intentionally not advertised because `InvokeCommand` cannot execute them. - Updates spell-check expectations for the Windows constants used by this implementation. ## Validation The authoritative local versions of all three changed files are pushed together. A Windows build was not run in this Linux environment. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> |
||
|
Clint Rutkas
|
0d335ffbbd |
Add Peek.Common unit tests (MathHelper, PathHelper) (#49105)
## Summary Adds a **Peek.Common.UnitTests** project (MSTest) with unit coverage for Peek.Common.Helpers: - **MathHelper.Modulo** — positive/zero results, negative-dividend wrap-around, large values, and the new non-positive-divisor guard. - **MathHelper.NumberOfDigits** — single/multi-digit, negative, and 9/10 & 99/100 boundary values. - **PathHelper.IsUncPath** — standard UNC, subfolders, dotted-server and IP hosts, plus negatives: drive-letter, relative, empty, HTTP URL, ile:// URI, single backslash, and null. Also adds a small correctness guard to MathHelper.Modulo: a non-positive divisor now throws ArgumentOutOfRangeException instead of silently throwing DivideByZeroException (b == 0) or returning a misleading result (b < 0). Registers the test project in `PowerToys.slnx` (ARM64 + x64). **37 tests pass** locally (x64 Debug). ## Context This is a clean, **tests-only split of #46684** (the Peek.Common portion), intentionally **without** the bundled global dependency bump from that PR. The PowerAccent.Core portion of #46684 was shipped separately in #49104. ## Test coverage | Area | Tests | |------|-------| | MathHelper.Modulo / NumberOfDigits | included | | PathHelper.IsUncPath | included | No production behavior changes beyond the Modulo argument guard, which is covered by the new tests. Co-authored-by: Clint Rutkas <crutkas@users.noreply.github.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> |
||
|
Clint Rutkas
|
7afcb8ce42 |
Fixing a WindowBase warning during compile (#49049)
Removing a warning that pops up a lot. **With fix:** <img width="694" height="674" alt="image" src="https://github.com/user-attachments/assets/2a496935-0d4b-45e6-97f2-62b8d4004faa" /> **Without fix:** here it is commented out to show the warning. <img width="1033" height="654" alt="Screenshot 2026-06-30 111523" src="https://github.com/user-attachments/assets/5d8f5df9-3c45-4155-a995-4b666df894fd" /> Found conflicts between different versions of "WindowsBase" that could not be resolved. There was a conflict between "WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" and "WindowsBase, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35". "WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was chosen because it was primary and "WindowsBase, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was not. References which depend on "WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" [C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\10.0.8\ref\net10.0\WindowsBase.dll]. C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\10.0.8\ref\net10.0\WindowsBase.dll Project file item includes which caused reference "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\10.0.8\ref\net10.0\WindowsBase.dll". C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\10.0.8\ref/net10.0/WindowsBase.dll References which depend on or have been unified to "WindowsBase, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" []. C:\Users\crutkas\.nuget\packages\microsoft.web.webview2\1.0.3719.77\lib_manual\net5.0-windows10.0.17763.0\Microsoft.Web.WebView2.Wpf.dll Project file item includes which caused reference "C:\Users\crutkas\.nuget\packages\microsoft.web.webview2\1.0.3719.77\lib_manual\net5.0-windows10.0.17763.0\Microsoft.Web.WebView2.Wpf.dll". C:\Users\crutkas\.nuget\packages\microsoft.web.webview2\1.0.3719.77\buildTransitive\..\\lib_manual\net5.0-windows10.0.17763.0\Microsoft.Web.WebView2.Wpf.dll |
||
|
Clint Rutkas
|
021ca6aee0 |
Add Runner C++ hotkey conflict unit test seed (#48352)
Adds the C++ counterpart to #48346: a focused Runner native unit-test seed for core hotkey conflict behavior. Why this one: - Runner is core infrastructure rather than another C# module test. - It adds the missing native C++ test-project path for Runner. - The seed test is deterministic and covers in-app hotkey conflict detection. - It keeps the active rollout to two PRs: one C# module-services PR (#48346) and one C++ core/runner PR. Validation: - `tools\build\build.ps1 -Platform x64 -Configuration Debug -Path src\runner\UnitTests` - `vstest.console.exe x64\Debug\tests\Runner\Runner.UnitTests.dll /Tests:HasConflict_TwoModulesSameHotkey_InAppConflict` → 1 passed --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Clint Rutkas
|
7f1cdece68 |
Update SharpCompress to 0.50.1 (#49520)
## Summary of the Pull Request Updates `SharpCompress` from **0.37.2** to **0.50.1** (latest listed stable) and migrates Peek's `ArchivePreviewer` to the renamed APIs. 0.37.2 is subject to [GHSA-6c8g-7p36-r338](https://github.com/advisories/GHSA-6c8g-7p36-r338) (moderate severity), which currently produces an `NU1902` warning on restore. This upgrade clears it. The bump also required a real behavioral fix: `.tar.gz` / `.tgz` previews break outright on 0.50.1 without it. Details below. ## PR Checklist - [ ] Closes: #xxx <!-- N/A: no tracking issue, this is a dependency/security bump --> - [ ] **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 <!-- See "Validation Steps Performed" - Peek has no unit test project today, so this was validated with a differential harness. Happy to add coverage if desired. --> - [x] **Localization:** All end-user-facing strings can be localized <!-- N/A: no strings added or changed --> - [ ] **Dev docs:** Added/updated <!-- N/A --> - [ ] **New binaries:** Added on the required places <!-- N/A: no new binaries. SharpCompress.dll already ships with Peek; only its version changes. --> - [ ] [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 <!-- N/A --> ## Detailed Description of the Pull Request / Additional comments Two files change: **`Directory.Packages.props`** - central version pin moves `0.37.2` to `0.50.1`. `Peek.FilePreviewer.csproj` needs no edit because its `PackageReference` is versionless under Central Package Management. **`src/modules/peek/Peek.FilePreviewer/Previewers/Archives/ArchivePreviewer.cs`** - the only SharpCompress consumer in the repo. ### API renames Verified by reflecting over the shipped 0.50.1 assembly rather than guessing: | 0.37.2 | 0.50.1 | |---|---| | `ArchiveFactory.Open(...)` | `ArchiveFactory.OpenArchive(...)` | | `ReaderFactory.Open(...)` | `ReaderFactory.OpenReader(...)` | | `IArchive.TotalUncompressSize` | `IArchive.TotalUncompressedSize` | `ArchiveEncoding`, `ReaderOptions.Forced`, and `IEntry.Key`/`Size`/`IsDirectory` are unchanged, so the existing zip CP437 encoding-probe logic ported over without modification. ### Behavioral fix: `.tar.gz` / `.tgz` The renames alone are not sufficient. On 0.50.1, `ArchiveFactory.OpenArchive` can no longer open a gzip-compressed tar as a random-access archive; it throws `ArchiveOperationException: Cannot determine compressed stream type`. On 0.37.2 the same call succeeded and returned `type=Tar`. I probed six alternatives before settling on a fix: `OpenArchive(path)`, `ExtensionHint="tar.gz"`, `ExtensionHint=".tar.gz"`, `LookForHeader=true`, the `FileInfo` overload, and `OpenReader`. Only `ReaderFactory.OpenReader` works. The branch is now forward-only through `OpenReader`, and the `OpenArchive` + `stream.Seek(0)` preamble is removed. This path is user-reachable, so the break would have shipped: `FileItem.Extension` returns `.gz` for `foo.tar.gz`, and `.gz` is in `_supportedFileTypes`, so Peek does preview these files. ### Incidental correctness fix While rewriting that branch, the reported size changes. The old code used `archive.TotalUncompressSize`, which for a `.tar.gz` reported the size of the intermediate **tar container** rather than the sum of the entries. It now accumulates `reader.Entry.Size`, so the footer count/size line is correct for these archives. ## Validation Steps Performed `Peek.FilePreviewer` builds clean (x64 Release) resolving SharpCompress 0.50.1. Peek has no unit test project, and the only archive coverage in `Peek.UITests` is `Peek.FilePreview.ZIPArchive`, which previews `TestAssets\7.zip` and asserts via screenshot comparison. There is no `.tar.gz` test asset, so nothing in the existing suite would have caught the regression above. Given that, I validated with a standalone differential harness that replicates `LoadPreviewAsync` verbatim and runs it against **both** 0.37.2 and 0.50.1 over the same set of archives, comparing entry names and sizes: | Archive | 0.37.2 | 0.50.1 | |---|---|---| | `test.zip` | `sub/nested.txt (19)`, `hello.txt (11)`, total 30 | identical | | `utf8.zip` | names correct | names correct | | `sjis.zip` | `日本語/テスト.txt` correct | identical | | `short.zip` | `caf‚.txt`, `na‹ve.md`, `a¤o.log` (mangled, detected windows-1252) | `café.txt`, `naïve.md`, `año.log` (correct, detected utf-8) | | `test.tar.gz` | opens, total 4096 (container size) | opens, total 30 (correct) | | `test.tar` | ok | ok | | `hello.gz` | ok | ok | All entry names and sizes match. 0.50.1 is strictly more correct on short non-ASCII entry names and on `.tar.gz` sizing. One subtle difference worth flagging for reviewers: on `utf8.zip`, 0.50.1 honors `ArchiveEncoding.Forced` even for UTF-8-flagged zips, so the strict CP437 round-trip no longer throws and `encodingDetermined` comes back `false` where it was `true` before. The decoded names are still correct, because charset detection then correctly identifies UTF-8. No tested case produced wrong output. Manual validation: previewed `.zip`, `.tar`, `.tar.gz`, and `.gz` files in Peek. `NOTICE.md` lists SharpCompress by name without a version, so it needs no update. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: cb1e58a5-de5b-420e-8153-ef9b15810211 |
||
|
moooyo
|
130a77907b |
[Keyboard Manager] Build the WinUI 3 editor self-contained to fix launch crash (0xC0000409) (#49524)
## Summary of the Pull Request `PowerToys.KeyboardManagerEditorUI.exe` fail-fasts with `0xC0000409` (`STATUS_STACK_BUFFER_OVERRUN`) during `MainWindow` construction, so the new Keyboard Manager editor never opens. `KeyboardManagerEditorUI.csproj` was the **only WinUI 3 executable in the repo missing `<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>`**, so it was built framework-package-dependent and mixed two Windows App SDK provenances in one process. ## PR Checklist - [x] Closes: #49399 - [ ] **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 <!-- no user-facing strings added --> - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places <!-- no new binaries --> - [ ] **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 ### Root cause The reporter's WinDbg capture shows a first-chance `Core::ApiException` carrying `0x800704DF` (`ERROR_ALREADY_INITIALIZED`): ``` MainWindow.SetTitleBar -> Microsoft.UI.Xaml.Window.set_ExtendsContentIntoTitleBar -> Microsoft.UI.Input!InputNonClientPointerSourceWinRTStatics::GetForWindowIdHelper -> Microsoft.UI.Windowing.Core!RegisterWindowFeature -> Core::NamedApiObject::Init -> Core::ApiException ``` `ExtendsContentIntoTitleBar` is the **site**, not the cause — it is simply the first user statement that crosses XAML -> Windowing -> Input. `microsoft.windowsappsdk.foundation/*/buildTransitive/Microsoft.WindowsAppSDK.BootstrapCommon.targets` turns the bootstrapper on precisely when this project's shape is hit: ```xml <PropertyGroup Condition="'$(WindowsAppSdkBootstrapInitialize)'=='' and '$(WindowsAppSDKSelfContained)'!='true' and '$(WindowsPackageType)'=='None' and ('$(OutputType)'=='Exe' or '$(OutputType)'=='Winexe')"> <WindowsAppSdkBootstrapInitialize>true</WindowsAppSdkBootstrapInitialize> </PropertyGroup> ``` That compiles in `MddBootstrapAutoInitializer.cs`, which joins the machine-wide `Microsoft.WindowsAppRuntime` MSIX framework package to the process package graph before `Main`. Meanwhile the exe's own directory — `WinUI3Apps` — is first in the Win32 DLL search order and already contains a complete app-local Windows App SDK payload, deployed there by the other 14 self-contained apps. One process, two Windows App SDK provenances, and the one-time feature-type registration in `Microsoft.UI.Input` collides. The omission was easy to miss: the project imports `src\Common.SelfContained.props`, whose name suggests it covers this — but it only sets the **.NET** `<SelfContained>` property, which is unrelated. This also explains why the reporter could not shake it off: the framework package is machine state, so uninstall/reinstall and wiping `%LOCALAPPDATA%\Microsoft\PowerToys` change nothing. The classic C++ editor is unaffected because it uses WinUI 2 XAML Islands and ships no Windows App SDK at all. `PowerToys.Settings.exe` ran healthily in the same elevated session on the same day while doing strictly more title-bar work (it sets `ExtendsContentIntoTitleBar` twice and drives `InputNonClientPointerSource.GetForWindowId` on every `SizeChanged`) — because it *is* self-contained. ### Two additional defects fixed Both were found while investigating why the crash left no diagnostics at all: 1. **`App.xaml.cs` initialized the logger via fire-and-forget `Task.Run`** — the only one of ~30 `Logger.InitializeLogger` call sites in the repo to do so. That races window creation, and `Logger` has no buffering or replay (`Trace.WriteLine` straight through, listener attached in `InitializeLogger`), so anything logged before the listener is attached is lost permanently. This is why the user's bug report bundle contains a `WinUI3Editor` log for the day it worked and **no log file at all** for the day it crashed. Made synchronous, ordered to match `FileLocksmithXAML/App.xaml.cs`, plus a log line before the window is constructed. 2. **`MainWindow` never called `WindowHelpers.ForceTopBorder1PixelInsetOnWindows10`**, unlike the other PowerToys WinUI 3 module windows (AdvancedPaste, EnvironmentVariables, FileLocksmith, Hosts, ImageResizer, Peek, RegistryPreview, Settings). It is a no-op on Windows 11 and fixes the black top border from microsoft/microsoft-ui-xaml#6901 on Windows 10 — the OS this issue was reported against. Happy to drop this hunk if reviewers prefer a minimal diff. Deliberately **not** done: wrapping `new MainWindow()` in `try/catch`. The failure is a WIL `RaiseFailFastException`, which managed code cannot intercept; and swallowing managed exceptions there would leave a windowless zombie process still holding the runner's `m_hEditorProcess` handle, making the runner take its "editor already open" branch and breaking every subsequent launch. That is why #49477 cannot work. ### Repo-wide audit All 15 WinUI 3 executables (`UseWinUI=true` and `OutputType=WinExe`) were checked. **KeyboardManagerEditorUI was the only one missing the property**; the other 14 already set it. Also verified as correct and unchanged: the 7 WinUI class libraries (property is app-level, N/A), `runner.vcxproj` and `PowerRenameUI.vcxproj` (native exes, both already `true`), and `PowerToys.MeasureToolCore.vcxproj` / `FindMyMouse.vcxproj` (deliberately `false` — in-proc module DLLs whose host already establishes the self-contained context). There is no repo-level default or build guard for this property; it is hand-copied into 17 project files, which is how the hole opened. A `Directory.Build.targets` guard that errors when an unpackaged Windows App SDK executable omits it would prevent recurrence, but it would catch nothing today, so I left it out of this PR to keep the diff scoped. Happy to open it separately. ## Validation Steps Performed Built `KeyboardManagerEditorUI.csproj` (x64/Debug) and diffed the build output before and after the change: | | before | after | `PowerToys.Hosts.exe` (reference) | |---|---|---|---| | `obj\x64\Debug\Manifests\` (created only by `CreateWinRTRegistration`) | absent | **present** | present | | `activatableClass` registrations embedded in the exe | **0** | **1912** | 1912 | | assembly references `Microsoft.WindowsAppRuntime.Bootstrap.Net` / `MddBootstrap` | **yes** | **no** | no | The editor now resolves every `Microsoft.UI.*` activation app-locally through registration-free WinRT instead of the machine framework package, which removes the mixing hazard. **Not yet validated on Windows 10.** I do not have a Windows 10 19045 machine, so the crash repro itself is unverified end-to-end. The deployment-mode change is verified from build output as above; confirmation from the issue reporter would be valuable. A useful discriminator if anyone has the reporter's ProcDump dump: `lm v m Microsoft.UI.*` — if `Microsoft.UI.Input.dll` is listed twice from two different paths, the mechanism is confirmed directly. Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Clint Rutkas
|
837fe46ed3 |
Add Awake module services unit test seed (#48346)
Adds an Awake module-services unit-test seed for runtime state creation from timed settings. This is product/module coverage, not Settings UI model serialization.\n\nValidation:\n- Restored and built Awake.ModuleServices.UnitTests x64 Debug\n- Ran the filtered test CreateState_TimedSettings_ReturnsTimedStateWithDuration: 1 passed Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Clint Rutkas
|
7ddfd2f3e0 |
[Updater] Open PowerToys handle before WM_CLOSE to avoid PID-recycle race (#46973)
Narrows this PR to @yeelam-gordon's review feedback. The wait-for-exit before launching the installer is **already in `main`** (landed separately), so the original change here is now redundant. What's **not** in main is the PID-recycle hazard Gordon flagged, so this PR applies just that fix: Open the PowerToys process handle **before** sending `WM_CLOSE`. PowerToys can exit inside its own `WM_CLOSE` handler, after which the OS may recycle its PID — opening by PID afterwards could then fail or attach to an unrelated process that reused it, and `WaitForSingleObject` would wait on the wrong thing. Holding the handle first anchors the kernel object to the original process, so PID reuse is impossible while we wait on it. Rebased onto latest `main` (resolves the previous merge conflict). Originally fixes #46966. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Jiří Polášek
|
e7b3346aff |
CmdPal: Improve performance of Window Walker extension (#49317)
## Summary of the Pull Request This PR improves performance of Window Walker, to make it faster (or at least make it look like it is faster). - Adds cached Window Walker list items and window snapshots for faster page loading. - Changes window enumeration to refresh asynchronously without blocking initial results. - Adds lazy, sequential icon loading with cached icon data. - Reuses existing list items when window metadata changes. - Fixes incorrect destruction of borrowed window icon handles. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #49315 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Niels Laute
|
346b498fb5 |
Shortcut Guide: Replace dual windows with single transparent overlay and add holding windows button (#48683)
## Summary Refactors Shortcut Guide from two separate `WindowEx` instances (`MainWindow` + `TaskbarWindow`) into a single full-monitor transparent `OverlayWindow` that hosts both surfaces as XAML UserControls. This enables shared animations and a more polished visual experience, and makes the taskbar shortcut indicators **edge-aware** for Windows 11's top/bottom/left/right taskbar positioning. https://github.com/user-attachments/assets/e40a25f6-4ab3-4073-b1a8-906ef7782877 <img width="507" height="968" alt="image" src="https://github.com/user-attachments/assets/2e06a3d9-32d9-482e-90fe-1f0f8a7d7598" /> ## Changes Closes: #48435 Closes #48491 Closes: #49200 Closes: #48552 (theme flash on Light/System theme + shortcut-list scroll flutter) Closes: #48773 ### Architecture - **OverlayWindow**: Single transparent host covering the full monitor work area, using `TransparentTintBackdrop` - **MainPaneControl**: The shortcut list pseudo-window, reusing the shared `TransientSurface` control for chrome (acrylic backdrop, theme shadow, rounded corners) - **TaskbarPaneControl + TaskbarIndicator**: Tooltip-style indicators with triangle tails, positioned above taskbar buttons ### Edge-aware taskbar indicators (Windows 11 top/bottom/left/right) - Detects the taskbar edge via the public, documented `SHAppBarMessage` / `ABM_GETTASKBARPOS` API (the same API CmdPal Dock uses) - Indicators lay out along the correct axis — horizontally for a top/bottom taskbar, vertically for a left/right taskbar — with the triangle tail always pointing toward the taskbar (4-direction tail + per-edge slide-in animation) - For a left/right taskbar, the main pane is inset so the order reads **taskbar | indicators | pane** - **Adaptive sizing**: each indicator's body size is derived from the actual measured UIA taskbar button rect, so the bubbles shrink when Windows uses small icons or combines buttons (many apps open). Uses the smallest button slot (clamped to a readable range) so neighbouring bubbles never overlap; the font scales with it ### Visual polish - Windows 11 system flyout entry/exit animations (slide + fade, ~367ms entrance / ~200ms exit with cubic easing) - Animation direction is position-aware (slides from left when left-aligned, from right when right-aligned) - Taskbar indicators slide in from the taskbar edge with the same timing - Close button on the main flyout title bar ### Robustness - Multi-monitor DPI handling via WM_DPICHANGED suppression (prevents double-scaling on cross-monitor moves) - Win11 phantom border elimination (comprehensive DWM/style stripping) - Click-outside-to-close with animated exit transition - Process lifetime fix (`Application.Current.Exit()` on close) ## Validation - Build clean (x64 Debug, exit 0, empty errors log) - Tested on multi-monitor mixed-DPI setup (150% + 100%) - Tested with the taskbar docked to each edge (top/bottom/left/right) and with small/combined taskbar icons --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Noraa Junker <noraa.junker@outlook.com> Co-authored-by: Clint Rutkas <clint@rutkas.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> |
||
|
Clint Rutkas
|
d7afa69048 |
Fix _snwprintf_s size argument in BugReportTool EventViewer (#48398)
## Summary Caught while reading through `BugReportTool` for an unrelated review: the two `_snwprintf_s` calls in `EventViewer.cpp` pass `sizeof(buff)` as the buffer-size argument, but `buff` is a `wchar_t[1000]`. `_snwprintf_s` measures its size and count arguments in **wide characters**, not bytes, so the current code advertises a 2000-wchar destination for a buffer that only holds 1000. `cpp wchar_t buff[1000]; // 2000 bytes, 1000 wchars memset(buff, 0, sizeof(buff)); _snwprintf_s(buff, sizeof(buff), fmt, ...); // <-- 2000 passed as wchar count ` If the formatted output ever exceeds 1000 wchars, the Secure CRT bounds check fires (in debug) and - depending on which `_snwprintf_s` overload the compiler selects against the safe template - it can write past the end of the stack buffer in release. Neither format string here is likely to produce 1000+ characters in practice (one substitutes a process name, the other a channel name + integer), so this is more of a latent footgun than a known crash, but the bounds are simply wrong. ## Fix Use `_countof(buff)` for the size argument (which is what `_snwprintf_s` actually wants - element count, not byte count) and pass `_TRUNCATE` for the count so output is safely capped at 999 wchars plus the null terminator: `cpp _snwprintf_s(buff, _countof(buff), _TRUNCATE, fmt, ...); ` Applied to both `GetQuery` and `GetQueryByChannel`. ## Scope Searched the rest of the repo for the same pattern (`_snwprintf_s(buf, sizeof(...))` / `_snprintf_s(buf, sizeof(...))`) - these two call sites are the only occurrences in the codebase. ## Validation - `BugReportTool.sln` rebuilds clean locally (Release|x64) and produces `PowerToys.BugReportTool.exe`. - No behavior change on the happy path - both formats are well under 1000 wchars in normal use. ## Risk Low. Two-line change in a single utility that builds event-log queries for bug reports. Truncation on overflow is strictly safer than the prior behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Jeremy Sinclair
|
354a43bd8c |
[Deps] Update .NET packages from 10.0.9 to 10.0.10 (#49419)
## Summary of the Pull Request Updates the centrally pinned .NET 10 `Microsoft.*` packages in `Directory.Packages.props` from `10.0.9` to `10.0.10`. ## 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 Bumps the .NET 10 `Microsoft.*` package pins from `10.0.9` to `10.0.10` to match the latest servicing release. ## Validation Steps Performed Not run locally here; change is a package version bump only. Co-authored-by: Copilot <copilot@github.com> |
||
|
John Surles
|
fc680d350f |
[Quick Accent] Fix window width when descriptions are disabled (#49402)
## Summary of the Pull Request Fixes Quick Accent clipping or horizontally shifting the last character when Unicode descriptions are disabled and the character list is short. The WinUI window width was calculated as `item count × 48 DIPs`, but the selector surface also has 24-DIP left and right margins and a 1-DIP border on each side. Those values reduced the usable list width. Fractional layout rounding at scaled display settings could then leave the viewport one physical pixel too narrow even after accounting for the nominal XAML dimensions. The sizing calculation now reads the surface's live horizontal margin and border thickness and includes them in the requested window width. It also adds a 1-DIP layout-rounding allowance so the character list is not truncated at fractional display scales. ## PR Checklist - [x] Closes: #49346 - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - The proposed root cause and approach were posted in the [contribution thread](https://github.com/microsoft/PowerToys/issues/28769#issuecomment-5013633279); maintainer confirmation is still pending. - [ ] **Tests:** Added/updated and all pass - No automated test was added because this fix connects runtime WinUI layout values and display scaling to the window-size calculation; a unit test that duplicated the XAML dimensions would not catch the integration regression. - [x] **Localization:** All end-user-facing strings can be localized - No strings changed. - [x] **Dev docs:** Added/updated - No developer documentation changes are needed for this focused layout correction. - [x] **New binaries:** Added on the required places - No binaries or projects were added. - [x] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries — not applicable - [x] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder — not applicable - [x] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects — not applicable - [x] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) — not applicable - [ ] **Documentation updated:** Not applicable; there is no user-facing behavior or documentation change. ## Detailed Description of the Pull Request / Additional comments `SelectorControl.xaml` gives the `TransientSurface` a `Margin=24,24,24,16`, and `DefaultTransientSurfaceStyle` supplies a 1-DIP border on each side. For the four-character reproduction in #49346, the previous calculation requested a 192-DIP window (`4 × 48`). After the 48 DIPs of horizontal surface margin, only 144 DIPs remained for the list, which is exactly three character cells. `SelectorControl` now exposes the computed left-plus-right surface margin and border thickness internally. `MainWindow.SizeAndPosition()` adds that live overhead to the character-driven width before applying the existing description minimum and monitor-width clamp. A further 1-DIP allowance covers fractional physical-pixel rounding at scaled display settings. With four characters, the calculation reserves the complete 192-DIP list width, the 50-DIP surface overhead, and the 1-DIP layout-rounding allowance. This leaves long-list scrolling, selected-character scrolling, description sizing, monitor clamping, DPI conversion, and window positioning unchanged. ## Validation Steps Performed - `git diff --check` passes. - Built `PowerAccent.UI` locally with Visual Studio 2026 in `Debug|x64`; the build completed successfully with 0 warnings and 0 errors. - Runtime-tested with Unicode descriptions disabled and only `SPECIAL` enabled. Holding `X` and pressing `Space` displayed all four mapped characters (`ẋ`, `×`, `ˣ`, `ₓ`) without clipping or scrolling. - Reproduced the one-pixel horizontal shift with all character sets enabled at 150% and 175% display scaling. - Retested the 1-DIP layout-rounding allowance at both 150% and 175%; all seven `F` characters remained stationary while cycling through the selection. - Verified the description minimum and maximum monitor-width clamp remain in the same order after the corrected content width is calculated. --------- Co-authored-by: Dave Rayment <dave.rayment@gmail.com> |
||
|
Jiří Polášek
|
b69bfe7f86 |
CmdPal: Replace custom sign(x) function with built-in sgn(x) function (#49392)
## Summary of the Pull Request This PR allow use of built-in `sgn` function in exprtk in Calculator and uses it to implement `sign` function. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #49391 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Jiří Polášek
|
c87ef67103 |
CmdPal: Ensure visual state groups set properties exclusively (#49319)
## Summary of the Pull Request This PR updates DockItemControl to ensure that visual state groups exclusively set properties and don't overlap to prevent unexpected and undeterministic result. - TextVisibilityStates and TextAlignmentStates shared SubtitleText.Visibility - TextVisibilityStates and IconVisibilityStates shared ContentGrid.ColumnSpacing <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #47980 - [x] Closes: #49156 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Jiří Polášek
|
bc32d4216c |
CmdPal: Prevent selection from overriding ListView scrolling (#49354)
## Summary of the Pull Request This PR make ensuring selected item visibility on the list view optional and avoids it when user scrolls list view viewport manually (using scrollbar or mouse wheel), without touching selection. - Implicitly keep selection when using incrementel loading (incrementel loading) - Make ensuring the selected item is visible optional, and skip it when the user scrolls the ListView viewport using the scrollbar or mouse wheel <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #46592 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Jiří Polášek
|
526216562b |
CmdPal: Deduplicate Windows Settings based on title and target (#49340)
## Summary of the Pull Request This PR prevent deduplication of Windows Settings items with the same name but different targets. For example, Display appears in both the System and Ease of Access sections, along with 16 other duplicated settings. - Deduplicates items based on both name and target. - Adds an extra scoring hint for items with duplicate names. - When the name matches, prefer Windows Settings over other sources. ## Pictures? Pictures! | Before | After | |--------|-------| | <img width="1298" height="1246" alt="image" src="https://github.com/user-attachments/assets/9ff67756-7f03-49f8-994c-cdb17fdd589b" /> | <img width="1286" height="1240" alt="image" src="https://github.com/user-attachments/assets/7105cfea-84c2-4edf-971d-c1b47859cc8e" /> | <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #49335 <!-- - [ ] 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 |
||
|
Rishabh Jain
|
ccb647b2f0 |
Spec: Power Display ambient-light (ALS) adaptive brightness for external monitors (#49199)
## Summary Design spec for **ambient-light (ALS) adaptive brightness for external monitors** in Power Display, as discussed and agreed in #49038. The feature continuously maps the device''s ambient light sensor reading (the same ALS **Light Switch** already reads) to each external monitor''s brightness over **DDC/CI** (the path **Power Display** already uses) — i.e. auto-brightness for external monitors, the continuous/sensor-driven counterpart to the schedule-based #47480. This PR adds only the spec doc (`doc/specs/power-display-adaptive-brightness.md`), per the repo''s spec-first process (`doc/specs/readme.md`). No code. ## What the spec covers - **Core model** — a single per-monitor formula: `target = clamp(curve(lux) + offset, min, max)`. - **Per-monitor calibration curve** — the mechanism that keeps differently-behaving panels visually matched across the whole ambient range. - **Per-monitor offset** — live, phone-style personalization; manual/CLI nudges become an offset (default) with an optional `pause` behaviour. - **Live slider UX** — when adaptive is on, the slider reflects the computed value and dragging it sets the offset. - **Sensor trust & lifecycle** — lid-closed / clamshell detection (`GUID_LIDSWITCH_STATE_CHANGE` + `QueryDisplayConfig`), hold-last-good instead of dimming to black, and honest fallbacks. - Smoothing/hysteresis/rate-limiting for flicker- and wear-safe DDC/CI writes, settings persistence, telemetry, a11y/localization, risks, and phased delivery. ## Discussion / sign-off Behaviour was reviewed with @moooyo on #49038 (configurability, CLI/manual +/- while adaptive, slider behaviour) — agreed to proceed. Closes nothing yet; tracks #49038. Related: #47480, #42566, #35564. --------- Co-authored-by: Rishabh Jain <14334305+MrRishabhJain@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Jiří Polášek
|
babf5792d2 |
CmdPal: Fix dock item titles and icons for bookmarks (#49336)
## Summary of the Pull Request This PR adds a specialized wrapper for bookmarks so they are displayed correctly in the dock's Add band flyout. Bookmark items are updated lazily. When a WrappedDockItem was created and its properties were locked in place, the bookmark's icon and title had not yet been resolved. - Adds BookmarkDockItem, a specialized version of WrappedDockItem that updates when the underlying bookmark changes. - Ignores the temporary "Reloading" bookmark icon and provides a fallback bookmark icon. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #49025 <!-- - [ ] 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 |
||
|
Subhro-ai
|
bf14ebcec9 |
[CmdPal Calculator] Add reciprocal/inverse trig functions and n-th log/root; fix inverse function parse errors (#49356)
## Summary of the Pull Request Adds the missing trigonometric functions requested in #47093 to the Command Palette calculator, and fixes a regression where **all inverse trig/hyperbolic functions (`arcsin`, `arccos`, `arctan`, `arsinh`, `arcosh`, `artanh`) silently failed with a parse error**. **Bug fix:** since the mages → exprtk migration (#39972), the user-facing inverse-function names have still been accepted by input validation (`CalculateHelper.cs`) — they are native Mages function names and worked before the swap — but nothing maps them to exprtk's built-in names (`asin`, `acos`, `atan`, `asinh`, `acosh`, `atanh`), so exprtk returns a compile error and the calculator shows no result. The existing unit tests only covered the string transformation (`UpdateTrigFunctions`), never evaluation, so this went unnoticed. This PR registers the user-facing names as engine aliases and adds evaluation-level regression tests. **New functions:** - `cot`, `sec`, `csc` — exprtk-native; unblocked in input validation and wired into the degree/gradian trig-unit conversion - `arccot`, `arcsec`, `arccsc` — added to the engine (`arccot` uses `atan2(1, x)` for the continuous (0, π) branch, so `arccot(0) = π/2` and negative inputs land in (π/2, π)); also wired into trig-unit conversion - `coth`, `sech`, `csch` and `arcoth`, `arsech`, `arcsch` — added to the engine (hyperbolic, so no angle-unit conversion, consistent with `sinh`/`arsinh`) - `logn(x, base)` and `root(x, n)` — exprtk-native, unblocked in input validation (covers the "logarithm of n-th power" / "root of n-th degree" asks in the issue) ## PR Checklist - [x] Closes: #47093 - [x] **Communication:** The issue is labeled `Help Wanted` ("We encourage anyone to jump in on these and submit a PR.") - [x] **Tests:** Added/updated and all pass - [ ] **Localization:** No new end-user-facing strings (error paths reuse existing localized messages) - [ ] **Dev docs:** n/a - [ ] **New binaries:** n/a - [ ] **Documentation updated:** The docs page listing calculator functions may need updating; happy to file the docs PR once this is reviewed. ## Detailed Description of the Pull Request / Additional comments - `src/common/CalculatorEngineCommon/ExprtkEvaluator.cpp` - Registers aliases `arcsin/arccos/arctan/arsinh/arcosh/artanh` → `std::asin/acos/atan/asinh/acosh/atanh` (the bug fix). - Adds `coth/sech/csch` (reciprocal hyperbolics), `arccot/arcsec/arccsc`, and `arcoth/arsech/arcsch`, which exprtk does not provide. - `Microsoft.CmdPal.Ext.Calc/Helper/CalculateHelper.cs` - Whitelists the new function names in the input-validation regex. - Adds `cot/sec/csc` (argument conversion) and `arccot/arcsec/arccsc` (result conversion) to the degree/gradian handling in `UpdateTrigFunctions`. The existing `(?<!c)` look-behind logic correctly keeps `cot`↔`arccot`, `sec`↔`arcsec`, `csc`↔`arccsc`, and `cot`↔`coth` etc. apart (covered by tests). - `Microsoft.CmdPal.Ext.Calc/Helper/NumberTranslator.cs` - Adds the new names to the function-arity table so argument-separator protection works in decimal-comma locales (e.g. `logn(8; 2)` in de-DE). - The `log(` → `log10(` remapping in `CalculateEngine.cs` does not touch `logn(` (regex requires `(` directly after `log`); covered by a passing check. Behavior at undefined points maps to the existing error messages: `cot(0)`/`csch(0)` → ∞ → "out of bounds" error; `arcsin(2)`, `arcsec(0.5)`, `arcoth(0.5)` → NaN → "not a number" error (all covered by tests). PowerToys Run is unaffected: it still uses the Mages engine, which already supports the inverse-function names natively. ## Validation Steps Performed - Unit tests added: - Evaluation tests (`Interpret_NoErrors_WhenCalledWithRounding`) for all new functions **and** for the previously broken inverse functions (regression tests). - `InputValid` acceptance tests for every new name and rejection tests for bare names. - `UpdateTrigFunctions` transformation tests for degrees and gradians, including nesting (`sec(arcsec(2))`) and confirming hyperbolics are untouched. - End-to-end `TrigModeSettingsTest` rows through `CalculatorListPage` (e.g. `sec(60)` = 2 in degrees, `arccot(1)` = 45°, `cot(50)` = 1 in gradians). - Error-path tests for `cot(0)`, `csch(0)`, `arcsin(2)`, `arcsec(0.5)`, `arcoth(0.5)`. - The modified `ExprtkEvaluator.cpp` was additionally exercised standalone against the vendored `exprtk.hpp` with the exact parser settings used in production: 27 evaluation cases (including degree-mode composites exactly as `CalculateHelper` emits them) all pass, and all expected values in the test `DataRow`s are taken verbatim from the engine output. ### Screenshots **Built and ran locally (Debug build — note the "DBG | NO AOT" badge in the shots).** **_Before (shipping 0.100.2 — these all fail):_** <img width="786" alt="failed-arcsin" src="https://github.com/user-attachments/assets/4116c428-2804-43d7-b04b-9b02f7d374cc" /> <img width="784" alt="failed-cot" src="https://github.com/user-attachments/assets/b81d39df-dffd-4e8d-8af8-9d21552c5e89" /> <img width="784" alt="failed-logn" src="https://github.com/user-attachments/assets/b2eec32c-95e8-4b0a-b44f-47a30193a012" /> **_After (this PR):_** <img width="766" alt="arcsin" src="https://github.com/user-attachments/assets/9d8b2235-1330-433d-b0d5-5ad2527c1c01" /> <img width="766" alt="cot" src="https://github.com/user-attachments/assets/c2a4454f-1e46-4022-8107-7e0c9aff5a7e" /> <img width="767" alt="logn" src="https://github.com/user-attachments/assets/e6476cb9-3bf5-40e0-9b45-08a0add42124" /> <img width="764" alt="root" src="https://github.com/user-attachments/assets/97036055-1ee0-4355-b99f-891f4129e463" /> <img width="764" alt="sec1" src="https://github.com/user-attachments/assets/b82119f4-e6bb-47a7-8da7-0c3fd1272d70" /> <img width="766" alt="sech" src="https://github.com/user-attachments/assets/6363f938-8cbf-4d86-8784-d8288953786e" /> **_Recording_** https://github.com/user-attachments/assets/42c11e25-c342-4461-a9d4-e40d836d060c Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Jiří Polášek
|
44ae9df5ef |
CmdPal: Prevent scaling empty icon size (#49385)
## Summary of the Pull Request This PR prevents a crash caused by attempting to apply DPI scaling to an empty icon. Size.Empty has width and height values of negative infinity. Scaling those values still produces negative infinity, which is not valid for a Size. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #49360 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Jiří Polášek
|
e6cd68e60e |
CmdPal: Remove [ComImport] from Bookmarks extension (#49357)
## Summary of the Pull Request This PR fixes invalid Native AOT code generation issue in Bookmarks built-in extension. CommandLauncher+ApplicationActivationManager was marked with [ComImport], not compatible with AOT. ``` 29> ILC: Method '[Microsoft.CmdPal.Ext.Bookmarks]Microsoft.CmdPal.Ext.Bookmarks.Helpers.CommandLauncher+ApplicationActivationManager+_ApplicationActivationManager..ctor()' will always throw because: Invalid IL or CLR metadata in 'Void _ApplicationActivationManager..ctor()' ``` <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #49355 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed |
||
|
Jiří Polášek
|
0425140cac |
CmdPal: Fix default alias mapping to commands (#49384)
## Summary of the Pull Request This PR fixes an invalid command ID for the **Run** page in the default alias map. - Updates the map to use the new command ID. - Adds a migration from the old command ID to the new one. - Introduces shared constants for command IDs to help prevent future regressions. - Adds unit tests for the migration and to guard against future regressions. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #49371 <!-- - [ ] 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 |
||
|
Jake Scott
|
c2d505dd4d |
[CmdPal][Performance Monitor] Add disk activity monitoring (#48844)
<!-- 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: #46724 <!-- - [ ] 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 - (All Cmd Pal tests passed, but there were none specifically for Performance Monitor) - [X] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [X] **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 Added the ability to see the Disk Stats in the Performance Monitor of Command Palette. It is also able to be pinned to the dock. It functions similarly to the Network Stats, in that you can cycle between different disks and can see the read & write speed. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Ran the dev version of Command Palette and cycled through my devices disk and compared them with Task Manager. Turned on the Dock and compared the values with Task Manager as well on all my disks. --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> |
||
|
Jiří Polášek
|
dc330354a0 |
CmdPal: Upgrade AdaptiveCards nuget packages (#49362)
## Summary of the Pull Request
This PR upgrade Adaptive Cards nugets packages to the latest versions:
- Upgrades the three Adaptive Cards packages:
- AdaptiveCards.ObjectModel.WinUI3: 2.0.0-beta -> 2.0.2-beta
- AdaptiveCards.Rendering.WinUI3: 2.1.0-beta -> 2.2.4-beta
- AdaptiveCards.Templating: 2.0.5 -> 2.0.6
- Upgrades Microsoft.Bot.AdaptiveExpressions.Core to 4.23.1.
- Since the new packages uses portable RIDs, nuget will automatically
handle the copying of matching dll and we can remove workaround for
that.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #49361
- [x] Fixes: #49359
- [x] Fixes: #48800
<!-- - [ ] 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
- I've opened the Settings pages for all built-in extensions.
- I've opened all forms.
- I've opened all sample forms and content pages.
|