Commit Graph

9439 Commits

Author SHA1 Message Date
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
2026-07-28 07:45:56 -07:00
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>
2026-07-28 07:45:20 -07:00
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
2026-07-28 07:44:33 -07:00
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>
2026-07-28 08:00:36 +00:00
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>
2026-07-28 15:24:28 +08:00
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>
2026-07-27 09:36:21 -07:00
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
2026-07-27 06:35:29 -05:00
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>
2026-07-27 12:21:35 +02:00
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>
2026-07-27 12:20:13 +02:00
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>
2026-07-27 10:48:20 +08:00
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>
2026-07-23 05:39:32 +08:00
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
2026-07-21 10:30:04 -05:00
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
2026-07-21 10:29:03 -05:00
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
2026-07-21 10:25:09 -05:00
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
2026-07-21 10:24:09 -05:00
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>
2026-07-21 09:21:44 +00:00
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
2026-07-17 15:41:08 -05:00
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>
2026-07-17 13:54:11 -05:00
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
2026-07-17 13:48:09 -05:00
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
2026-07-17 13:47:25 -05:00
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
2026-07-17 13:13:39 -05:00
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>
2026-07-17 12:56:24 -05:00
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.
2026-07-17 09:59:37 -05:00
Clint Rutkas
f81689de3a [PowerDisplay] Drop redundant hardcoded PlatformToolset (inherit Cpp.Build.props) (#49370)
## Summary

Remove the redundant hardcoded `<PlatformToolset>v143</PlatformToolset>`
from two C++ projects so they inherit the toolset from the shared
`Cpp.Build.props` like every other project.

## Why

`Cpp.Build.props` is force-imported into **every** C++ project via
`Directory.Build.props`:

```xml
<ForceImportBeforeCppProps>$(RepoRoot)Cpp.Build.props</ForceImportBeforeCppProps>
```

MSBuild imports it during `Microsoft.Cpp.props` — i.e. *after* each
project's own PropertyGroups — and it sets the toolset for the whole
repo:

```xml
<PlatformToolset>v143</PlatformToolset>
<PlatformToolset Condition="'$(VisualStudioVersion)' == '18.0'">v145</PlatformToolset>
```

Two projects set `<PlatformToolset>v143</PlatformToolset>` directly in
their Configuration PropertyGroups:

-
`src/modules/powerdisplay/PowerDisplayModuleInterface/PowerDisplayModuleInterface.vcxproj`
(Debug + Release)
- `src/common/UnitTests-CommonUtils/UnitTests-CommonUtils.vcxproj`

That value was dead config — the force-imported prop already overrode it
to `v145` on VS2026 (v18). The other module interfaces (Awake,
FancyZones, …) don't set `PlatformToolset` at all; these two were just
over-specified VS-template projects.

## Change

Delete the redundant `PlatformToolset` lines so both projects inherit
from `Cpp.Build.props`.

## Validation

Built both projects locally with VS2026 (v18), Release x64, with no
`PlatformToolset` in the vcxproj:
- Both resolve to the `v145` toolset (MSVC `14.51`, `VC\v180`) via the
force-imported prop.
- Both produce their DLLs with no errors
(`PowerToys.PowerDisplayModuleInterface.dll`,
`Common.Utils.UnitTests.dll`).

## Risk

Very low — no change to the produced binaries (effective toolset is
unchanged); this just removes dead config and makes these two projects
consistent with the rest of the repo.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-07-17 16:49:00 +08:00
Pratyush Nalam
9b654d21d2 Fix GPU Stats not cycling through multiple GPUs (#48503)
## Summary of the Pull Request

Command Palette's Performance Monitor dock band exposes "Previous GPU" /
"Next GPU" commands, but on multi-GPU machines they did nothing and only
one GPU was ever shown.

Root cause: `GPUStats` keyed GPUs by the `phys_N` token in the "GPU
Engine" perf-counter instance names, assuming it enumerated physical
adapters. On modern Windows that token is effectively always `phys_0`
(verified on a desktop with an RTX 4090 + AMD iGPU — all 1640 instances
were `phys_0`), so every adapter collapsed into one bucket and the
reported usage was the *sum* across adapters. The real per-adapter
identifier is the LUID.

----------
_Note from 6/24 after latest rebase on top of #48710_: Rebased onto
latest main, which now includes #48710 ("CmdPal: Accurate GPU usage in
Dock"). The two changes overlap in GPUStats.GetData(), so I merged them
rather than picking a side — #48710's accuracy fix is fully preserved,
just re-keyed.

#48710 buckets utilization by (physId, engineId), takes the max engine
per adapter, and clamps to [0, 100]. The catch is that phys_N is
effectively always phys_0 on modern Windows (the exact reason this PR
switched to LUID keying), so on a multi-GPU machine #48710 alone still
collapses all adapters into one bucket. So I kept its max-per-engine +
clamp + NaN/negative filtering verbatim and only changed the key from
(phys, engine) to (LUID, engine). Net result: each adapter is tracked
separately and reports a correct, bounded 0–100% value.

Verified on a desktop with an RTX 4090 + AMD Radeon iGPU:

Prev/Next GPU cycles between the two adapters (WARP hidden).
GPU usage stays ≤ 100% under load and matches Task Manager.
Load on the 4090 doesn't move the idle iGPU's reading (per-adapter
independence holds).
No other behavior from #48710 changed.

----------

## PR Checklist

- [x] Closes: #47583 
- [x] **Communication:** Posted in #28769
- [x] **Tests:** No tests exist for
`Microsoft.CmdPal.Ext.PerformanceMonitor` so did not add any.
- [ ] **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

- Key GPUs by **LUID** (parsed from the instance name) instead of
`phys`.
- Resolve friendly adapter names via DXGI
(`IDXGIFactory1`/`IDXGIAdapter1` through CsWin32, AOT-safe) and **filter
out software adapters** (Microsoft Basic Render Driver / WARP).
- Discover adapters on each tick as well as at construction, so a GPU
that registers counters later still appears.
- Show the active GPU's name in the dock band subtitle so cycling is
visible.
 
## Validation Steps Performed

Tested on a desktop (RTX 4090 + AMD Radeon iGPU). Prev/Next GPU now
cycles between "NVIDIA GeForce RTX 4090" and "AMD Radeon(TM) Graphics",
each showing its own utilization; WARP is hidden.
2026-07-16 21:44:53 -05:00
moooyo
5c9c93d56d feat(powerdisplay): add CLI for monitor control (#48632)
## Summary of the Pull Request

Adds `PowerToys.PowerDisplay.Cli.exe`, a scriptable interface for
controlling monitors through the running PowerDisplay process. It
supports `list`, `get`, `set`, `up`, `down`, `capabilities`, `profiles`,
and `apply-profile`.

The CLI communicates over an authenticated, per-session named pipe;
PowerDisplay remains responsible for DDC/CI and WMI access.

## PR Checklist

- [x] Closes: #48713
- [x] **Communication:** Discussed with core contributors
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** Core errors are localizable; some help and
output text remains English-only
- [ ] **Dev docs:** N/A; built-in CLI help is the command reference
- [x] **New binaries:** Added on the required places
- [x] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
- [x] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetupVNext/Resources.wxs)
- [x] **YML for CI pipeline:** N/A; test assemblies are auto-discovered
- [x] **YML for signed pipeline:** N/A; signing is driven by
`ESRPSigning_core.json`
- [ ] **Documentation updated:** N/A

## Detailed Description of the Pull Request / Additional comments

- Adds an AOT-compatible CLI and shared request/response contracts.
- Uses a secured named-pipe server in PowerDisplay, with stable exit
codes and a bounded request timeout.
- Supports saved profiles by their existing stable profile IDs.
- Adds solution, signing, installer, and unit-test project integration.

## Validation Steps Performed

- PowerDisplay Lib, Contracts, CLI, and IPC unit-test suites pass.
- Native AOT publish completes without analyzer warnings.
- Manually validated the CLI on two DDC/CI monitors, including the
PowerDisplay-unavailable path.
- Rebuilt the PowerDisplay GUI after the shared-library changes.

---------

Co-authored-by: Yu Leng <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-07-16 23:08:27 +08:00
Moli
85d0c890de Docs: Fix broken links and incorrect source file references (#49294)
## Description

Fixes #49285

This PR fixes three documentation files with broken links or incorrect
source file references:

### 1. `doc/devdocs/modules/fileexploreraddons.md` — broken source code
link

The "Source code folder" link pointed to
`src/modules/fileexplorerpreview`, which does not exist in the
repository. Changed to `src/modules/previewpane` (the actual directory).

### 2. `doc/devdocs/modules/launcher/plugins/calculator.md` — broken
unit test links (10 occurrences)

All 10 links in the "Unit Tests" section pointed to
`Microsoft.PowerToys.Run.Plugin.Calculator.UnitTests` (plural), but the
actual test project directory is
`Microsoft.PowerToys.Run.Plugin.Calculator.UnitTest` (singular). All
link references have been corrected.

### 3. `doc/devdocs/core/runner.md` — incorrect file reference

The "Centralized Keyboard Hook" section referenced
`centralized_keyboard_hook.cpp`, but the actual file is
`centralized_kb_hook.cpp` (at `src/runner/centralized_kb_hook.cpp`).

## Validation

Each fix was verified against the actual repository structure:

| Fix | Verified path exists |
|-----|---------------------|
| `fileexploreraddons.md` | `src/modules/previewpane/` (contains
`powerpreview/` subproject) |
| `calculator.md` |
`src/modules/launcher/Plugins/Microsoft.PowerToys.Run.Plugin.Calculator.UnitTest/`
(contains `BracketHelperTests.cs`, `ExtendedCalculatorParserTests.cs`,
`NumberTranslatorTests.cs`, `QueryTests.cs`) |
| `runner.md` | `src/runner/centralized_kb_hook.cpp` |

## PR Checklist

- [x] Docs-only change — no code or tests affected
- [x] Links verified against actual repository structure
2026-07-16 12:50:09 +00:00
Noraa Junker
8746378762 [Monaco] Fix .uproject and .uplugin extensions registration (#49300)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request

Fixes some wrong procedure in #47931

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

- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2026-07-16 13:55:29 +02:00
moooyo
2b8e6247fc [PowerDisplay] Add stable profile IDs (#49175)
## Summary of the Pull Request

Gives every saved PowerDisplay profile a stable, auto-incrementing
integer ID and makes the app address profiles by that ID instead of by
name. Duplicate profile names are allowed, renames preserve identity,
and LightSwitch stores stable profile references.

> Split out of the PowerDisplay CLI branch (#48632). CLI-specific
contracts and commands remain in that stacked PR.

## PR Checklist

- [x] **Closes:** N/A - split from #48632.
- [x] **Communication:** Discussed with core contributors.
- [x] **Tests:** Added and passing in `PowerDisplay.Lib.UnitTests`.
- [x] **Localization:** The composed profile label uses a shared
localized format resource.
- [x] **New binaries:** None.
- [x] **Documentation updated:**
`doc/devdocs/modules/powerdisplay/design.md`.

## Implementation

### Profile model and persistence

- `PowerDisplayProfile.Id` is the stable JSON `id`; `0` means
unassigned.
- `PowerDisplayProfiles.NextId` is monotonic and IDs are never reused.
- `SetProfile` assigns IDs to new profiles and replaces existing
profiles by ID.
- Duplicate names are supported; name lookup remains only for migration
of legacy references.
- `ProfileStore` serializes cross-process load/modify/save operations
with a named mutex and atomically replaces `profiles.json`.
- Production callers use asynchronous `ProfileHelper` APIs.

### Migration and application

- Initial PowerDisplay discovery assigns missing profile IDs and
migrates legacy monitor IDs.
- LightSwitch legacy name references are reconciled to IDs and written
back to the current typed settings schema.
- Native LightSwitch publishes pure light/dark theme events;
PowerDisplay exclusively validates profile enablement and stable IDs.
- Settings UI and Named Pipe ApplyProfile actions send invariant
positive profile IDs.
- PowerDisplay validates the ID, loads the current profile, and applies
its monitor settings.

### Settings UI

- Create, edit, apply, and delete operations use stable IDs.
- LightSwitch selectors store profile IDs and keep legacy name fields
only for migration.
- Profile lists use a localized name-and-ID label so duplicate names
remain distinguishable.

## Accepted Trade-offs

- Profile ID migration remains dependent on the initial monitor
discovery; a failed or delayed discovery can temporarily hide legacy
ID-less profiles.
- The one-time PowerDisplay LightSwitch migration rewrites the complete
current typed settings object and does not add a new cross-process
settings transaction.

## Validation

- Built the affected x64 Debug projects with the repository build
scripts.
- `PowerDisplay.Lib.UnitTests`: 186 passed, 0 failed.

---------

Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-07-16 14:33:21 +08:00
Dave Rayment
ec0830396b [QuickAccent] Clarify, expand and correct currency symbol mappings (#49343)
<!-- 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
After a review of the current currency-related mappings, this PR makes a
few corrections, adds explanatory comments where certain mappings may be
confusing, and adds a small number of new mappings to fill gaps and to
complete euro area country coverage for `€`.

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

- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Changes:

1. Removed `z` from the Currency set. I think this was mistakenly added
alongside `ł` for the Polish Złoty (`zł`), but it's just a plain `z`
character so does not need to be present.
2. Added comments for all the characters in the currency set which do
not independently represent a currency. For example, c with caron `č` is
required for Czech Koruna (`Kč`), but `K` is a standard letter.
3. Added the Euro `€` character to the **E** key for the Greece set. It
has been the currency in Greece since 2001, so this was a real gap. Now
all the eurozone countries represented in Quick Accent have the same
mapping.
4. Added the Shekel (or NIS/ILS) `₪` to the Hebrew set.
5. Added the Dong `₫` to the Vietnamese set.

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Compiled and ran locally to confirm new additions were present:

<img width="750" height="108" alt="image"
src="https://github.com/user-attachments/assets/ce30e425-446f-4288-bb52-72e29768ef76"
/>


Confirmed all Quick Accent unit tests still ran successfully:

<img width="348" height="78" alt="image"
src="https://github.com/user-attachments/assets/b275a966-65d9-406e-838e-675b9dcd2c50"
/>
2026-07-16 14:29:24 +08:00
Dave Rayment
1f00859680 [Quick Accent] Correction and additions to Bulgarian key mappings (#49344)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This corrects the short I being present on the **I** key, and adds the
euro and common punctuation characters for the Bulgarian set.

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

- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
`й` was present in the Bulgarian set, which made no sense because every
Bulgarian keyboard layout includes the short I. This must have been a
mis-type for `ѝ`, which is present on most layouts, but absent on the
traditional non-BDS layout. This update replaces the short I with `ѝ`.

Bulgaria adopted the euro currency in January 2026, replacing the lev,
so including it on **E** makes sense, as it will become more and more
common in written communication and is not present on one of the
keyboard layouts.

Finally, Bulgarian typographic quotes (the `„` low-9 and `“` high-6) are
added, along with the double angle quotes for compatibility with other
Belarusian sets.

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

Compiled locally and checked that the new characters were available:
<img width="750" height="110" alt="image"
src="https://github.com/user-attachments/assets/d5ac0ac1-5814-492e-b2ba-e7747204e668"
/>

Confirmed that all unit tests still pass:

<img width="336" height="75" alt="image"
src="https://github.com/user-attachments/assets/eb4360c1-ac7e-4e5c-9cfb-a51a95c41c2a"
/>
2026-07-16 14:29:19 +08:00
Jiří Polášek
0bc78235cc CmdPal: Reorder CommandPalette.slnf (#49337)
## Summary of the Pull Request

This PR reorders the items in CommandPalette.slnf lexicographically
because:

1. It is easier to read.
1. Visual Studio goes bonkers and reorders them anyway, creating extra
noise in the diff.

Regressed in #49252

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

- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2026-07-15 11:18:44 -05:00
Jiří Polášek
e62a41c53a CmdPal / Settings: Prevent shortcut dialogs invocation from crashing the parent app (#49334)
<!-- 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

It looks like, when the stars align, changing the system theme can cause
the ContentDialog to open multiple times, especially if the user
repeatedly clicks the button that opens it.

- Adds a ThreadStatic flag to ensure the dialog is opened only once.
- Adds a try/catch guard in case my assumption about the flag is wrong.

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

- [x] Closes: #49310
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2026-07-15 10:00:03 -05:00
Aditya Raj Thakur
a291b43df4 CmdPal: Add Control Panel tasks to Windows Settings search (#49252)
## Summary of the Pull Request

The Command Palette's Windows Settings extension only matches queries
against the
static `WindowsSettings.json` list, so Control Panel tasks that Windows
itself
exposes — "Set up USB game controllers", "File History", "Adjust the
appearance and
performance of Windows" — can never be found, even though Control
Panel's own
search finds them instantly.

This adds a second, dynamic source. At startup the extension enumerates
the Control
Panel tasks from the shell's "All Tasks" folder (the same data Control
Panel search
uses, ~150 tasks) and merges them into the searchable set, de-duplicated
against the
existing entries.

## PR Checklist

- [x] Closes: #48539
- [x] **Communication:** Discussed in #48539
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places

## Detailed Description of the Pull Request / Additional comments

**Enumeration.** `ControlPanelTasksHelper` binds the shell "All Tasks"
folder
(`shell:::{ED7BA470-8E54-465E-825C-99712043E01C}`) to `IEnumShellItems`
and reads each
item's display name. Those names come from the shell **already
localized**, so the merge
deliberately runs *after* `TranslationHelper.TranslateAllSettings` —
they must not go
through resx translation. Merged entries are typed as Control Panel, so
their subtitle
reuses the existing localized string.

**Launching.** Control Panel task items have no executable command line,
and they cannot
be re-parsed from their parsing name (`SHParseDisplayName` fails on
them). Their shell id
list (PIDL) is therefore captured during enumeration via
`SHGetIDListFromObject` and
stored on the entry; invoking the result launches it with
`ShellExecuteEx(SEE_MASK_IDLIST)`.

**AOT.** All interop is source-generated (`LibraryImport` +
`GeneratedComInterface` with
`StrategyBasedComWrappers`), so the extension stays `IsAotCompatible`.

**Startup.** Enumeration runs on a background task so the provider
constructor never
blocks, and it degrades gracefully — if the shell namespace is
unavailable the helper logs
a warning and returns an empty list, leaving search exactly as it is
today.

**UX.** Merged entries get `AppHomepageScore = 0`, so they never appear
on an empty query.
De-duplication checks both `Name` and `AltNames` of existing settings.

**No pipeline changes needed:** the new unit test project follows the
same pattern as
`Microsoft.CmdPal.Ext.Registry.UnitTests` — registered in
`PowerToys.slnx` and the CmdPal
solution filters, and picked up by the existing `**\*UnitTest*.dll`
glob. No sibling CmdPal
unit test project is listed in `.pipelines`.

## Validation Steps Performed

**Automated** — added `Microsoft.CmdPal.Ext.WindowsSettings.UnitTests`
(this extension's
first test project). 8 tests, all passing:
- 7 unit tests over the merge: adds new tasks; skips duplicate names
case-insensitively;
skips names matching an existing entry's `AltNames`; skips entries
missing a name or
command; de-duplicates within the incoming list; returns 0 for an empty
list; preserves
  the shell command prefix.
- 1 functional test that enumerates the real shell folder and asserts
every task has a
name, a `::{`-prefixed parsing name, a non-empty id list, and the
expected settings path.

**Manual (Windows 11, x64 Debug)** — built `Microsoft.CmdPal.UI` and
drove the real palette:
- `Windows Settings` → `game controllers` returns **Set up USB game
controllers**,
  subtitle **Control Panel**.
- The File History and "appearance and performance" tasks are found.
- Invoking the result opens the real Windows **Game Controllers**
dialog; the performance
  task opens **Performance Options**.
- Typing the exact task name at the root surfaces it via the fallback
item, without
  entering the page.
- Regression: existing `power` → **Power and sleep** still resolves, the
empty query still
  shows only the homepage entries, and there are no duplicate rows.
- No perceptible delay — results were available as soon as CmdPal
finished loading.

<img width="1000" height="600"
alt="01-windows-settings-game-controllers"
src="https://github.com/user-attachments/assets/04d6ad8e-a69d-4c95-b480-05146aef8784"
/>
<img width="1000" height="600" alt="02-existing-power-result"
src="https://github.com/user-attachments/assets/62e75ea8-4a99-489a-8e7c-f7bf5813185f"
/>
<img width="1000" height="600" alt="03-root-fallback-game-controllers"
src="https://github.com/user-attachments/assets/03eb8908-b8f9-4635-a02e-29b413f0ff24"
/>
<img width="581" height="1080" alt="04-game-controllers-dialog"
src="https://github.com/user-attachments/assets/c8fa24ec-7e41-4da4-b862-e888a88dab7b"
/>

---------

Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2026-07-15 09:44:42 -05:00
Mike Griese
7c5a384c61 CmdPal: Manually set the clock band icon to blank (#49309)
When we added a primary command to open the notification center, that
changed the icon of the clock band. It now defaulted to using the
"OpenLink" icon, from the command.

By manually setting the icon to blank, we remove that icon we didn't
want.
2026-07-14 13:15:17 -05:00
Jiří Polášek
1bbcf27296 CmdPal: Hide separator between search bar and context grids when collapsed (#49313)
## Summary of the Pull Request

This PR updates a conditional visibility of a border/separator line
between search bar and page content to hide it when the ShellPage is in
collapsed mode.

## Pictures? Pictures!

<img width="472" height="108" alt="image"
src="https://github.com/user-attachments/assets/eebc6be2-7dbf-4861-812e-d06ab1d42257"
/>

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

- [x] Closes: #49312
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2026-07-14 10:30:56 -05:00
I am the .batMan
3a1e642db5 [Monaco] Add .uproject and .uplugin support for Unreal Engine files (#47931)
## Summary of the Pull Request

Register `.uproject` and `.uplugin` (Unreal Engine project and plugin
files) as JSON in Monaco preview, enabling syntax highlighting, folding,
and structured navigation for these files in the Monaco preview pane and
Peek.

This supersedes #45523, which mixed an unrelated de-minification
refactor with the feature change.

## PR Checklist

- [x] **Communication:** Single-line change, no design decisions
- [x] **Tests:** Manual validation only (preview/highlighting feature,
no automated tests in this area)
- [x] **Localization:** N/A (no end-user-facing strings)
- [x] **Dev docs:** N/A
- [x] **New binaries:** N/A

## Detailed Description of the Pull Request / Additional comments

A single-line edit in `src/Monaco/monaco_languages.json`: `.uproject`
and `.uplugin` are appended to the existing built-in `json` language
entry. `MonacoHelper.GetLanguage()` then returns `"json"` for these
files, and Monaco renders them with its full built-in JSON mode
(tokenizer, brace matching, folding, schema validation).

Follows the same pattern as #39246, which added `.shproj`/`.projitems`
directly to the built-in `xml` entry.

No change is needed in `monacoSpecialLanguages.js`: Monaco's JSON
support is provided by the language service (`vs/language/json/`), not
by a `vs/basic-languages/json/json` module, so the
`registerAdditionalLanguage(...)` helper used for other alias languages
doesn't apply here.

### About the force-pushes on this PR

Apologies for the churn. The original commit tried to register a
`jsonExt` alias via `registerAdditionalLanguage("jsonExt", [...],
"json", monaco)`. Copilot correctly pointed out that this can't work:
the helper requires a `vs/basic-languages/<id>/<id>` module, and
Monaco's JSON support lives under `vs/language/json/`, not
`vs/basic-languages/json/` — so the alias would have been registered
with no tokenizer attached and `.uproject`/`.uplugin` would have
rendered as plaintext.

While iterating I also overthought the regeneration concern around
`monaco_languages.json` (generated by
`src/Monaco/generateLanguagesJson.html`) and pushed a couple of
intermediate approaches that touched `monacoSpecialLanguages.js` as
well. After checking the repo history (#39246, #36499) and confirming
there's no CI/pipeline that regenerates this file, the convention here
is to edit `monaco_languages.json` directly when the change is purely an
extension association on a built-in language — hence the final minimal
diff.

## Validation Steps Performed

- Verified \`MonacoHelper.GetLanguage(".uproject")\` and
\`GetLanguage(".uplugin")\` both return \`"json"\`.
- Manually previewed \`.uproject\` and \`.uplugin\` files in Explorer's
Monaco preview pane and in Peek after a local Debug build: JSON syntax
highlighting, brace matching, folding, and structured navigation all
work as expected with text highlighting:
<img width="2107" height="829" alt="arestoys-20260516-174242011"
src="https://github.com/user-attachments/assets/b5a53ccd-e7f4-4452-b989-782605196c5e"
/>
2026-07-13 14:28:22 +08:00
Jiří Polášek
89db81d058 CmdPal: Add a new setting for toast window location (#49262)
## Summary of the Pull Request

This PR adds a new settings card to General page in Settings window that
allows user to select position of the toast notifications, with options
that matches the system setting (Bottom center, Top Left, Top center).

- Adds a new drop-down to General page in Settings.
- Teaches ToastWindow to position itself to match the new settings.
- Adds a default option "Use system settings" that looks into registry
what the OS is using right now.

## Pictures? Pictures

<img width="1832" height="436" alt="image"
src="https://github.com/user-attachments/assets/e973db8e-8d2a-45f6-b518-100e84bc2ac9"
/>

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

- [x] Closes: #49261 
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2026-07-11 23:23:09 +00:00
Jiří Polášek
bfce606af9 CmdPal: Fix breadcrumb navigation in Settings in non-English locales (#49253)
## Summary of the Pull Request

This PR fixes Settings window breadcrumbs in non-English locales.

For some reason localized strings leaked as navigation identifiers.

- Replaces localized titles in Crumb.Data with const names.
- Adds PageTags constants for settings page navigation tags.
- Uses new constants in Navigate() switch, initial navigation, and
Internal Tools nav item.

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

- [x] Closes: #45855 
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2026-07-11 18:21:21 -05:00
Jiří Polášek
a1bef58c7f CmdPal: Add an optional icon and an optional action button to toasts (#49260)
## Summary of the Pull Request

This PR adds new options to toast notifications in Command Palette.

- Adds `IToastArgs2` interface (based on `IToastArgs`) with optional
Icon and Command; backwards compatible both ways.
- Toolkit `ToastArgs` class implements IToastArgs2.
- `ToastWindow` renders the icon and an action button; action toasts
stay up 5s and hover pauses auto-hide.
- The action runs through the normal PerformCommandMessage pipeline; new
opt-in ShowWindowIfPage flag summons the palette for page commands
(default false).
- New samples for both new properties.

## Pictures? Pictures!

Action command:

<img width="548" height="144" alt="image"
src="https://github.com/user-attachments/assets/aa0e50fa-baa6-43e1-a761-a9a43be0afb0"
/>

Icon:

<img width="704" height="132" alt="image"
src="https://github.com/user-attachments/assets/2424a946-ffb5-4928-818c-6cb24453b34d"
/>


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

- [x] Closes: #49259
- [x] Closes: #49258
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2026-07-11 18:19:52 -05:00
Jiří Polášek
9d09e50372 CmdPal: Add Settings and Help menu items to the search bar context menu (#49266)
## Summary of the Pull Request

This PR expands context menu of search bar with new options: Settings
and Help so user can find them and access them more easily.

It builds on existing context menu, so all default items are kept in
place.

## Pictures? Pictures!

<img width="1284" height="366" alt="image"
src="https://github.com/user-attachments/assets/cb0b47db-f7bf-43a2-b6fe-b86a8dbc04c6"
/>

<img width="510" height="392" alt="image"
src="https://github.com/user-attachments/assets/f16f2083-8dc2-4ded-834e-4568d5777eea"
/>


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

- [x] Closes: #49265 
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2026-07-11 18:11:56 -05:00
Jiří Polášek
fc5ef38326 CmdPal: Recognize internet shortcuts for Origin, UPlay and XBox as apps (#49241)
## Summary of the Pull Request

This PR extends allow list of protocols that are recognized as valid
apps with
- Origin (`origin://game` and `origin2://game`)
- UPlay (`uplay://launch/`)
- XBox (`msgamelaunch://shortcutLaunch/`)

As a flyby it improves readability of the regex and replaces it with
regular expression source generator.

## Pictures? Pictures!

<img width="1256" height="1478" alt="image"
src="https://github.com/user-attachments/assets/efbb319a-b9a3-4603-b0df-24622f63cc8e"
/>


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

- [x] Closes: #49236
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2026-07-10 13:17:38 -05:00
Gleb Khmyznikov
d5fe397b05 Follow-up: UITest framework Next - stability improvements (#49242)
This pull request addresses several CI flakiness and reliability issues
in the UI test automation harness, especially around foreground window
handling and build artifact resolution. The main improvements ensure
that UI interactions (like real mouse clicks) reliably target the
correct window, even in complex CI and build environments, and that test
code accurately locates module executables regardless of output layout.

**Foreground window handling and input reliability:**

* Added `Session.EnsureForeground()` and improved
`WindowControl.TryBringToForeground()` to reliably raise the target
window above others, defeating the Win32 foreground lock using
`AttachThreadInput` and related APIs. This prevents coordinate-based
clicks from landing on the wrong window, a common cause of CI test
flakiness. (`src/common/UITestAutomation.Next/Session.cs`,
`src/common/UITestAutomation.Next/WindowControl.cs`,
`src/common/UITestAutomation.Next/Element/Element.cs`,
`.github/skills/ui-tests-migration/references/ci-stability.md`,
`src/modules/MeasureTool/Tests/ScreenRuler.UITests.Next/TestHelper.cs`)
[[1]](diffhunk://#diff-713524f4ead9951000b3578248f2740088729981051b68c3fa3655ebb548f20fR91-R118)
[[2]](diffhunk://#diff-60be6ec24a99f8974cff00414fc47ea1e60e3ab9aee706b5d6845eb8df19165fR59-R76)
[[3]](diffhunk://#diff-60be6ec24a99f8974cff00414fc47ea1e60e3ab9aee706b5d6845eb8df19165fL247-R332)
[[4]](diffhunk://#diff-3c00581cb1d2b6a4302b8378b87c27cdad2f87c2aefc37eec0bdc6c39af9291aR100-R103)
[[5]](diffhunk://#diff-98e5aea12baaac99aba10e7dd341ed3f2efdd24cb80b29306bb500816de09e2fR96-R114)
[[6]](diffhunk://#diff-d8766b48614fe4a99e3f100e69e611ca2464de6ba0be257586c12d51f9278ed0L498-R504)

**Build artifact and executable path resolution:**

* Refactored `ModuleInfo.GetDevelopmentPath()` to dynamically walk up
from the test assembly and find the module executable in various build
output layouts, including CI artifacts and local builds. This eliminates
hardcoded path offsets and makes test launches robust to different build
structures. (`src/common/UITestAutomation/ModuleInfo.cs`)
* Updated `ModuleConfigData.GetModulePath()` to use the improved path
resolution and fall back to installed builds if necessary, ensuring that
test runs can always locate the correct executable.
(`src/common/UITestAutomation/ModuleConfigData.cs`)
* Simplified `SessionHelper` so that `locationPath` is always empty,
leveraging the fact that module paths are now absolute.
(`src/common/UITestAutomation/SessionHelper.cs`)
[[1]](diffhunk://#diff-c001f0fd3432c8b6102c3120597fc48f24902eaa0d755f51adfa7646344b3833L7-L10)
[[2]](diffhunk://#diff-c001f0fd3432c8b6102c3120597fc48f24902eaa0d755f51adfa7646344b3833L46-R54)

These changes collectively improve test reliability, especially in CI
environments, and make the harness more resilient to changes in build
output structure.

---------

Co-authored-by: Boliang Zhang (from Dev Box) <bozhang@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-07-09 20:57:18 -07:00
Muyuan Li
18edd52239 Fix Peek Ctrl+W shortcut not working after clicking preview (#48293)
## Summary

Fixes #48274

When previewing a file with Peek, clicking inside the preview content
(PDF, text/code, markdown, HTML) makes **Ctrl+W unable to close the
window**. This happens because the preview controls (WebView2 for most
file types, native shell handlers for others) capture keyboard focus in
their own message loop, bypassing the XAML keyboard accelerator system
entirely.

## Problem

Peek defines keyboard shortcuts (Ctrl+W to close, Escape to close, arrow
keys to navigate) as `KeyboardAccelerator` elements on the main XAML
Grid. These only fire when keyboard input flows through the XAML input
system. However:

- **WebView2** (used for PDF, text/code via Monaco, markdown, HTML):
Runs Chromium in a separate process that consumes all keyboard input
when focused. Ctrl+W is particularly problematic because Chromium treats
it as "close tab."
- **Shell Preview Handlers** (native HWND): Run in a child Win32 window
that handles keyboard messages independently.

Once either of these controls gets focus via a mouse click, keyboard
shortcuts stop working.

## Solution

Added a **low-level keyboard hook** (`WH_KEYBOARD_LL`) that intercepts
key events at the OS level, regardless of which control has focus:

- **Ctrl+W** and **Escape** → close the Peek window
- **Arrow keys** (Left/Right/Up/Down without Ctrl) → navigate between
files

The hook is installed only while the Peek window is visible and only
acts when Peek is the foreground window, so it has no impact on other
applications.

As additional defense-in-depth, `AreBrowserAcceleratorKeysEnabled` is
set to `false` on the WebView2 control, preventing Chromium from
consuming browser-specific shortcuts like Ctrl+W.

## Changes

| File | Change |
|------|--------|
| `Peek.UI/PeekXAML/MainWindow.xaml.cs` | Install/uninstall keyboard
hook in Initialize/Uninitialize; hook callback handles Ctrl+W, Escape,
and arrow keys |
| `Peek.UI/Native/NativeMethods.cs` | P/Invoke declarations for
`SetWindowsHookEx`, `UnhookWindowsHookEx`, `CallNextHookEx`,
`GetAsyncKeyState` |
| `Peek.FilePreviewer/Controls/BrowserControl.xaml.cs` | Disable browser
accelerator keys on WebView2 |

## Validation

- [x] Ctrl+W closes Peek after clicking inside PDF preview
- [x] Ctrl+W closes Peek after clicking inside text/code preview
(Monaco)
- [x] Escape closes Peek after clicking inside preview
- [x] Arrow keys navigate between files after clicking inside preview
- [x] Normal typing/interaction inside previews still works (Ctrl+C,
scrolling, etc.)
- [x] Shortcuts still work without clicking (existing behavior
preserved)

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
2026-07-09 17:14:26 +08:00
David Gardiner
3fd6a03ed4 Make PowerShell script invocation more reliable (#46729)
## Summary of the Pull Request

- Protect against issues caused by loading PowerShell profile scripts
- Ignore any warnings that may be generated by auto-loaded PowerShell
modules. Warnings are written to stderr which the Exec then interprets
as an error

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

- [x] Closes: #46618
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **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

The build contains PowerShell invocations. The issue with these prior to
this change is that they are vulnerable to what ever may be in the
current user's PowerShell profile script.

They are also vulnerable to any auto-loaded PowerShell modules that may
generate warnings, as the warning output is interpreted as an error by
the MSBuild `Exec` task.

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

1. Built successfully from command line and in Visual Studio
2. Tested locally and also tested MouseWithoutBorders against second
machine.
2026-07-09 08:55:21 +00:00
Muyuan Li
4881f23545 Add PR Needs-Author-Feedback lifecycle to fabricbot configuration (#49151)
## Summary

Adds fabricbot rules to manage the `Needs-Author-Feedback` label
lifecycle for **pull requests**, complementing the existing issue
management rules in `resourceManagement.yml`.

This is a **simpler alternative** to the GitHub Actions workflow
approach (PR #48812), trading advanced features (draft conversion,
author-specific activity tracking) for zero-maintenance fabricbot
automation.

## Behavior

### Flow diagram

```
┌──────────────────────────────────────────────────────────────────────┐
│  Maintainer adds "Needs-Author-Feedback" label to a PR              │
└──────────────────────────────────────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────┐     ┌──────────────────────────────────┐
│  7 days, no activity                │────►│  Add "Status-No recent activity" │
│                                     │     │  + post warning comment          │
└─────────────────────────────────────┘     └──────────────────────────────────┘
         │                                               │
         ▼                                               ▼
┌─────────────────────────────────────┐     ┌──────────────────────────────────┐
│  7 more days (14 total), no activity│────►│  Close PR + post closing comment │
└─────────────────────────────────────┘     └──────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────────┐
│  Author pushes commits OR comments on PR (at any point)              │
└──────────────────────────────────────────────────────────────────────┘
         │
         ▼
    Remove "Needs-Author-Feedback" → Add "Needs-Triage"
    Remove "Status-No recent activity" (if present)
```

### Scheduled searches (every 6 hours)

| Condition | Action |
|-----------|--------|
| PR + `Needs-Author-Feedback` + 7 days inactive + no `Status-No recent
activity` | Add `Status-No recent activity` label + warning comment |
| PR + `Needs-Author-Feedback` + `Status-No recent activity` + 7 more
days inactive | Post closing comment + close PR |

### Event responders

| Trigger | Action |
|---------|--------|
| Author comments on PR (`Issue_Comment` + `issueAuthor`) | Remove
`Needs-Author-Feedback`, add `Needs-Triage` + `Needs-Team-Response` |
| Author pushes commits (`Pull_Request` + `Synchronize` + `issueAuthor`)
| Remove `Needs-Author-Feedback`, add `Needs-Triage` |
| Any PR update activity | Remove `Status-No recent activity` |

### Bot messages

**Warning (at 7 days):**
> This pull request has been automatically marked as stale because it
has been marked as requiring author feedback but has not had any
activity for **7 days**. It will be closed if no further activity occurs
**within 7 days of this comment**. To keep this PR active, please push
your changes or leave a comment.

**Closing (at 14 days):**
> This pull request has been automatically closed because it has been
marked as requiring author feedback but has not had any activity for
**14 days**. If you would like to continue working on this, please
reopen the PR and push your changes.

## Comparison with GitHub Actions workflow (PR #48812)

| Feature | This PR (fabricbot) | PR #48812 (Actions) |
|---------|-------------------|-------------------|
| Convert to draft at 7 days |  Not supported |  Via GraphQL |
| Close at 14 days |  |  |
| Author-specific activity tracking |  Any activity resets timer | 
Only author activity counts |
| Bot comment resets timer | ⚠️ Yes (fabricbot limitation) |  No
(filtered out) |
| Maintenance burden | None (fabricbot managed) | Low (workflow file) |
| Testing before merge |  No local testing |  `workflow_dispatch` +
dry-run |
| Review comment detection |  Only issue comments |  Reviews + inline
comments |

## Trade-offs

**Pros:**
- Zero maintenance — fabricbot is a managed service
- Consistent with existing issue management patterns in the same file
- No workflow YAML to debug or maintain

**Cons:**
- No draft conversion (fabricbot cannot call GraphQL)
- `noActivitySince` counts **all** activity — bot comments, maintainer
comments, and label changes all reset the inactivity timer
- Cannot distinguish author activity from other activity
- No way to test locally or with dry-run before merge

## Relationship to existing automation

Mirrors the existing issue rules (lines 11-43) which use the same
pattern:
- Issues: 5 days → warning, 5 more days → close
- PRs (this change): 7 days → warning, 7 more days → close

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-07-09 15:37:19 +08:00
Gleb Khmyznikov
85f698677a [UITests] AI migration skill + ScreenRuler tests example port. (#48842)
This PR is build on top of
https://github.com/microsoft/PowerToys/pull/48717 and
https://github.com/microsoft/PowerToys/pull/48467

It adds the ui-tests-migration skill which should be used to migrate the
old UITest module by module to use new .Next UI framework.

As an example, the screen ruller tests was ported here.

---------

Co-authored-by: Boliang Zhang (from Dev Box) <bozhang@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-07-09 11:02:54 +08:00
Boliang Zhang
4395b1d0ca [skill] Generalize verification skill into 2 scenarios (module checklist / PR validation) (#48848)
## Summary of the Pull Request

Generalizes the `powertoys-verification` agent skill from "one module
checklist" into a **single shared engine that serves two verification
scenarios**, using the *shared engine + per-scenario reference docs*
design (no duplication of the winapp mechanics):

- **A — Module checklist**: verify a supplied module checklist against
the installed build.
- **B — PR validation**: derive each PR's checklist from its description
+ diff, then drive it. A single **bits sub-decision** picks the target —
drive the **installed** build when the PR's code is already shipped (a
merged PR, or a whole release/hotfix set, e.g. the 0.100.1 14-PR
sign-off), or **build + sideload** the affected module when it isn't (an
unmerged or not-yet-released PR, e.g. #45242).

Both scenarios share the same `winapp ui` drive techniques, helper
scripts, per-module profiles, taxonomy, and report format. They differ
mainly on **what bits you run**, so the only new content is a thin
scenario layer.

## PR Checklist

- [ ] **Closes:** N/A (follow-up to the merged `powertoys-verification`
skill)
- [x] **Communication:** design discussed and agreed before
implementation
- [x] **Tests:** N/A — docs/skill-only change; validated link/constraint
checks (see below)
- [x] **Localization:** N/A
- [x] **Dev docs:** this PR *is* skill documentation
- [x] **New binaries:** none

## Detailed Description of the Pull Request / Additional comments

**`SKILL.md` (shared engine)** — broaden `description` + "When to use"
to cover both scenarios, add a **Step-0 scenario router** (plus, for B,
the bits sub-decision "is the PR's code in the build under test?"), keep
the supplied-checklist read **Scenario-A-only**, and make the
bootstrap/placeholders/"What NOT to do" scenario-aware.

**`references/scenarios/`:**
- `index.md` — router table (A/B); the **"bits under test" contract**
(the one real conflict: installed-and-immutable, vs build-and-sideload
when the PR's code isn't in the build, echoed in the report header so
the evidence chain is trustworthy); and a verdict-vocabulary mapping
(engine `PASS/FAIL/BLOCKED` <-> legacy labels).
- `module-checklist.md` (A) — supplied checklist, installed bits.
- `pr-validation.md` (B, **new — merges the former release-PR and
active-PR docs**) — derive each PR's checklist from `gh pr view/diff`;
the **bits sub-decision**; a **PR-discovery model with a size gate**
(auto-verify hotfix-sized sets <=25; for full ~100-PR releases,
scope-and-confirm instead of blind-looping) and a non-runtime-PR
pre-filter; per-PR folders + roll-up; and the **build + sideload**
front-end (in-repo worktree helper + build commands), unpackaged (run
the built runner, dismiss the expected partial-build dialogs) vs
packaged/CmdPal (`Add-AppxPackage -Register`) deploy recipes,
prove-your-bits, and restore-to-shipped cleanup.

Removed the separate `release-pr-signoff.md` and
`active-pr-validation.md` (folded into `pr-validation.md`). The existing
engine docs (`winapp-ui-testing.md`, `pre-flight.md`,
`reporting-format.md`), per-module profiles, and helper scripts are
reused unchanged — single source of truth. The `BITS:` header version is
a `<version>` placeholder (not pinned to a release).

## Validation Steps Performed

- `SKILL.md` within authoring limits: **331 lines** (< 500) and
**description 999 chars** (< 1024).
- All relative markdown links in `references/scenarios/*.md` resolve,
and every engine doc they cite exists.
- Scenario B exercised end-to-end both ways: the 0.100.1 14-PR sign-off
(8 PASS / 6 BLOCKED, installed bits) and PR #45242 (Advanced Paste, 3/3
PASS, build + sideload).

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-07-08 14:53:38 -07:00
Alex Mihaiuc
6b5c21000f Align ZoomIt dialog controls (#49210)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This change deals with ZoomIt standalone texts.

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

- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2026-07-08 20:18:36 +02:00
Jiří Polášek
99d01dc37b CmdPal: Fix "Open Command Palette" dock item (#49095)
## Summary of the Pull Request

This PR fixes the "Open Command Palette" dock item.

Dock only opens Command Palette for page commands (see
DockControl.InvokeItem). The recent dock home change introduced
`GoHomeDockCommand` as an invokable command, so the Palette no longer
opened from the dock item.

- Restores dock home to use the shared root page.
- Adds a deferred root page accessor to avoid DI cycles.


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

- [x] Closes: #49089
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2026-07-08 11:09:55 -05:00