Command Palette: extension loses right to set foreground window

[jiripolasek]

Microsoft PowerToys version

0.90.1

Installation method

WinGet

Area(s) with issue?

Command Palette

Steps to reproduce

Scenario 1: Top-Level Command Loses Foreground Access After First Use

1. Open the Command Palette.
2. Invoke a top-level command from an external extension that brings a window to the foreground or starts another application.
3. Observe that the command executes correctly and the window appears in the foreground.
4. Reopen the Command Palette and invoke the same command again.
5. Observe that the command now fails to bring its window to the foreground.
6. Activate another extension (e.g. open All Apps).
7. Invoke the top-level command once more.
8. Observe that the command now regains the ability to bring its window to the foreground.

This behavior prevents the top-level command from being invoked twice in succession with full functionality.

Scenario 2: Commands from List Pages Lack Foreground Access

1. Navigate to a list page provided by an external extension.
2. Invoke a command from the list that brings a window to the foreground or starts another application.
3. Observe that the command is unable to bring its associated window to the foreground.

✔️ Expected Behavior

Commands invoked via the Command Palette—whether top-level or from list pages—should consistently retain the ability to set their associated window as the foreground window.

❌ Actual Behavior

Command invocations do not reliably have the ability to bring their window to the foreground.

• In Scenario 1, this ability is lost after the first invocation and only restored when another extension is activated.
• In Scenario 2, the ability is missing entirely when commands are invoked from list pages.

Additional Information

Windows 11 24H2

Other Software

No response

---

https://github.com/jiripolasek/Issue39255ReproExtension

[jiripolasek]

Hi,

I'm not entirely sure about the exact behavior of CoAllowSetForegroundWindow, but it's worth noting that the AllowSetForegroundWindow function is a one-off:

The process specified by the dwProcessId parameter loses the ability to set the foreground window the next time that either the user generates input (unless the input is directed at that process), or the next time a process calls AllowSetForegroundWindow (unless the same process is specified as in the previous call to AllowSetForegroundWindow).
— Microsoft Docs

As a quick workaround, I tried forcing a CoAllowSetForegroundWindow call before any command is invoked, and that seems to resolve the issue.