## Summary of the Pull Request
This PR ensures that the list of recent searches in the Web Search
extension is updated immediately after a new item is added or when
settings controlling the number of items are changed.
- Refactors the Web Search extension history to keep it in memory after
being loaded at startup
- Adds an event to notify subscribers when the history changes
- Implements `IDisposable` to ensure that `WebSearchListPage`
unsubscribes from the event
- Moves responsibility for creating all list items to single class
(`WebSearchListPage`)
- Updated unit tests
-
## PR Checklist
- [x] Closes: #40548
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [x] **Dev docs:** nothing
- [x] **New binaries:** none
- [x] **Documentation updated:** nope
<!-- 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
## Summary of the Pull Request
For WebSearch extension:
- Replaces localized string identifiers with invariant literal keys to
ensure stable and consistent setting values, avoiding issues when
switching cultures or if display strings change.
- Renames the `ShowHistory` property to `HistoryItemCount`.
- Changes the type from `string` to `int` and centralizes parsing logic
in `SettingsManager`.
- Retains backward compatibility by preserving the legacy settings key
`"ShowHistory"` in `SettingsManager`.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #40547
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [x] **Dev docs:** none
- [x] **New binaries:** none
- [x] **Documentation updated:** none
<!-- 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
It would seem that the way we absorb the icons for built-in extension
into our package relies on the _extension_ package including WASDK. I
don't fully understand why.
This PR adds a common `.props` file we can use for all extensions, to
make sure they include it.
regressed in #41261Closes#41279
<!-- 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: #41241#41242
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Co-authored-by: Yu Leng <yuleng@microsoft.com>
What the title says. 😄
Rather than relying on the potentially overloaded `!=` or `==` operators
when checking for null, now we'll use the `is` expression (possibly
combined with the `not` operator) to ensure correct checking. Probably
overkill for many of these classes, but decided to err on the side of
consistency. Would matter more on classes that may be inherited or
extended.
Using `is` and `is not` will provide us a guarantee that no
user-overloaded equality operators (`==`/`!=`) is invoked when a
`expression is null` is evaluated.
In code form, changed all instances of:
```c#
something != null
something == null
```
to:
```c#
something is not null
something is null
```
The one exception was checking null on a `KeyChord`. `KeyChord` is a
struct which is never null so VS will raise an error when trying this
versus just providing a warning when using `keyChord != null`. In
reality, we shouldn't do this check because it can't ever be null. In
the case of a `KeyChord` it **would** be a `KeyChord` equivalent to:
```c#
KeyChord keyChord = new ()
{
Modifiers = 0,
Vkey = 0,
ScanCode = 0
};
```
This entirely rewrites the shell page. It feels a lot more like the old
run dialog now.
* It's got icons for files & exes
* it can handle network paths
* it can handle `commands /with args...`
* it'll suggest files in that path as you type
* it handles `%environmentVariables%`
* it handles `"Paths with\spaces in them"`
* it shows you the path as a suggestion, in the text box, as you move
the selection
References:
Closes#39044Closes#39419Closes#38298Closes#40311
### Remaining todo's
* [x] Remove the `GenerateAppxManifest` change, and file something to
fix that. We are still generating msix's on every build, wtf
* [x] Clean-up code
* [x] Double-check loc
* [x] Remove a bunch of debug printing that we don't need anymore
* [ ] File a separate PR for moving the file (indexer) commands into a
common project, and re-use those here
* [x] Add history support again! I totally tore that out
* did that in #40427
* [x] make `shell:` paths and weird URI's just work. Good test is
`x-cmdpal://settings`
### further optimizations that probably aren't blocking
* [x] Our fast up-to-date is clearly broken, but I think that's been
broken since early 0.91
* [x] If the exe doesn't change, we don't need to create a new ListItem
for it. We can just re-use the current one, and just change the args
* [ ] if the directory hasn't changed, but we typed more chars (e.g.
`c:\windows\s` -> `c:\windows\sys`), we should cache the ListItem's from
the first query, and re-use them if possible.
Just standardizing built-in extensions to use a `internal sealed class
Icons` for all their non-dynamic icons.
Looks like a LOT of changes, but it's icons all the way down.
## Summary of the Pull Request
Display full page message when the Web Search extension page is empty
<img width="786" height="473" alt="image"
src="https://github.com/user-attachments/assets/2d08d809-1127-44b3-9842-50969eb6bef7"
/>
<img width="786" height="473" alt="image"
src="https://github.com/user-attachments/assets/155374cc-3e13-4cc0-b7e5-b4fa2b371ba7"
/>
## PR Checklist
- [x] **Closes:** #38969
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** yay
- [x] **Localization:** nope
- [x] **Dev docs:** none
- [x] **New binaries:** zilch
- [x] **Documentation updated:** no need
## Detailed Description of the Pull Request / Additional comments
--
## Validation Steps Performed
Tested with and without enabled history.
## Summary of the Pull Request
Clears and hides fallback item for URL when query changes and URL is no
longer a valid URL. Fixes the situation when the item remains visible in
the list with generic text and pointing the last valid URL it was
updated with.
## PR Checklist
- [x] **Closes:** #40512
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** no new strings
- [x] **Dev docs:** nothing to update
- [x] **New binaries:** none
- [x] **Documentation updated:** none
## Detailed Description of the Pull Request / Additional comments
## Validation Steps Performed
Entered URL to search field. Observed the Open URL item is present.
Cleared URL. Observed that Open URL item is not present.
This adds settings to each provider to allow us to control if individual
fallback items are enabled or not, regardless of the provider being
enabled.
This is relevant to _all the threads where disabling fallback commands
came up_
This just adds another section to each provider's settings page, with a
list of the fallback commands.
This also has nothing to do with the "top-level apps search", which is
not really a fallback command - it's its own thing.
Ref #38288. Doesn't close that, because this only controls
enable/disable, not ranking.
From here, we should be able to add a dedicated page in the SUI that
shows all the fallbacks across all providers. That's where we'll enable
the ordering.
<!-- 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 actually fixes an issue with #39794. What I failed to mention in
the original issue was the additional path under the registry that the
new key is located under. Instead of the key being stored directly in
`UserChoiceLatest` in a key named `ProgId`, the path also includes a
second `ProgId` as well.
Copilot tried to fix this issue in #40035, but because I had failed to
mention the additional `ProgId` in the path, it was not included in
Copilot's fix.
Therefore, the true new path is
`.../UserChoiceLatest/ProgId`
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #39794
- [ ] **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
## Summary
This PR fixes an issue where PowerToys Web Search and PowerToys Run
would always open Microsoft Edge instead of the user's default browser
on Windows 11 24H2, even when a different browser like Firefox was set
as the default.
## Root Cause
Windows 11 24H2 introduced a change where default browser associations
are now stored in a new registry location:
- **New location**:
`HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoiceLatest`
- **Old location**:
`HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice`
PowerToys was only checking the old registry location, causing it to
fail to find the default browser and fall back to Microsoft Edge.
## Changes Made
Updated both `DefaultBrowserInfo.cs` files to check the new registry
location first, then fall back to the old location for backward
compatibility:
1. **Command Palette Web Search**:
`src/modules/cmdpal/ext/Microsoft.CmdPal.Ext.WebSearch/Helpers/DefaultBrowserInfo.cs`
2. **PowerToys Run**:
`src/modules/launcher/Wox.Plugin/Common/DefaultBrowserInfo.cs`
**Before**:
```csharp
var progId = GetRegistryValue(
@"HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice",
"ProgId");
```
**After**:
```csharp
var progId = GetRegistryValue(
@"HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoiceLatest",
"ProgId")
?? GetRegistryValue(
@"HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice",
"ProgId");
```
## Testing
- Verified the fallback logic works correctly with a test application
- Confirmed both affected files are updated with the same pattern
- Ensured backward compatibility with older Windows versions
## Impact
This fix ensures that:
- Users on Windows 11 24H2 will have their default browser respected
- Older Windows versions continue to work as before
- No breaking changes are introduced
Fixes#39794.
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: crutkas <1462282+crutkas@users.noreply.github.com>
**WARNING:** This PR will probably blow up all in-flight PRs
at some point in the early days of CmdPal, two of us created seperate
`Exts` and `exts` dirs. Depending on what the casing was on the branch
that you checked one of those out from, it'd get stuck like that on your
PC forever.
Windows didn't care, so we never noticed.
But GitHub does care, and now browsing the source on GitHub is basically
impossible.
Closes#38081
