Context menu item for "File Smith" handle all the verbs which is not belongs to it

[zhuxb711]

Microsoft PowerToys version

0.69.1

Installation method

Microsoft Store

Running as admin

No

Area(s) with issue?

File Locksmith

Steps to reproduce

1. Try activating the context menu through Shell32.IContextMenu.InvokeCommand()
2. Use string verb, for example, verb "Edit" (on '.rdp' file)
3. See File Smith is launched unexpected

✔️ Expected Behavior

Verb "Edit" should launch the window that used to edit the .rdp file but File Smith

❌ Actual Behavior

1. If File Smith is enabled, all the string verb activate the file smith rather than its origin program
2. If File Smith is disabled or use MENUITEMINFO.wID instead of string verb will have correct behavior

Other Software

No response

[Aaron-Junker]

@stefansjfw Do we override some registry keys that we shouldn't override?

[zhuxb711]

@Aaron-Junker @stefansjfw Could please help take a look on this issue? Thanks.

[pauvt]

Any news on this?

I have the same issue. I use custom verbs in the software Everyting (https://www.voidtools.com/forum/viewtopic.php?t=2161) and when I have the File Smith enabled it activates the File Smith instead of my custom verb.

[stefansjfw]

I'll take a look. So this happens only with File Locksmith? PowerRename does not do this? /needinfo

[stefansjfw]

And to double check, this happens with the latest version of PowerToys as well (v0.75.1)?

[pauvt]

I'll take a look. So this happens only with File Locksmith? PowerRename does not do this? /needinfo

It looks like PowerRename does not do this. I have it enabled and it doesn't break my custom verb.

And to double check, this happens with the latest version of PowerToys as well (v0.75.1)?

Yes. It's still happening in v0.75.1.

[zhuxb711]

@stefansjfw Any progress?

[pauvt]

The issue remains in v0.81.0. In my case this makes the FileSmith unusable because it breaks all verbs which I am using for other purposes...

[iamcalledrob]

@stefansjfw

Seeing this in v0.82.1

Invoking almost any verb opens "File Locksmith".
Toggling File Locksmith to disabled in settings immediately fixes the issue, but re-enabling it brings it back.

Oddly, I'm seeing inconsistent results for which verbs trigger the issue. Yesterday, "properties" and "open" were both opening file locksmith. Today (after a reinstall of powertoys), only "open" is.

High-level what I'm doing:

1. SHGetDesktopFolder
2. ParseDisplayName to get a specific folder
3. BindToObject to get that folder as IShellFolder
4. ParseDisplayName on some child items to build an array of pidls
5. GetUIObjectOf( ... IID_IContextMenu) to get an IContextMenu for those items
6. QueryContextMenu to populate an HMENU
7. InvokeCommand(*CMINVOKECOMMANDINFO) to invoke a specific verb, e.g. "open"

When File Locksmith is enabled, invoking most verbs (open, print etc.) launch file locksmith.

Can also confirm that invoking using an integer ID for lpVerb invokes the correct behavior.

[iamcalledrob]

Related: #33470

[iamcalledrob]

@stefansjfw
Bumping this again, because this is breaking the windows API for other programs.

As a 3rd party developer, I can no longer reliably use IContextMenu to invoke commands by name if the user has File Locksmith installed.

This is such a strange issue, I'm wondering if this is exposing a bug in Windows itself?

[stefansjfw]

Hi @iamcalledrob, Thanks for pointing out this again! I will take a look this week! We are close to releasing a new version of PowerToys and as soon as it's out I will go back to this.

It is a strange issue, especially because we have 2 more context menu entries that do not introduce this issue. All should be based on the same logic. I doubt this is a Windows bug, to be honest.

[iamcalledrob]

Thank you for taking a look (and sorry for nudge!)

What makes me suspicious re: a Windows bug, is that I took a look at the code and associated PR and it was minimal and straightforward.
The manifest is registering for a single, custom verb only, so the IExplorerCommand COM server shouldn't even be invoked for anything but that custom verb (right... right?).

I didn't see anything happening with the registry either, so the appx manifest should be the only way this thing gets invoked?

[stefansjfw]

Would you be willing to try an unofficial test build to see if the issue is still there?

[iamcalledrob]

Absolutely, happy to help here

[stefansjfw]

https://github.com/stefansjfw/PowerToys/releases/tag/v0.0.1

Thanks a lot! you can find installers here. Looking forward to your feedback!

[iamcalledrob]

Hey @stefansjfw

I installed the release from above, and there is no longer an "Unlock with File Locksmith" option in the Windows 11 context menu (it's present in the legacy menu).

Verb invocation works properly with that release, with the caveat that there is no modern explorer integration any more.

Exactly what I did:

1. Check with v0.84.0 -> "open" verb launches File Locksmith
2. Uninstall PowerToys -> "open" verb works properly
3. Install your custom release -> "open" verb works properly, no Win11 explorer integration
4. Kill and re-launch all explorer.exe processes -> no change

[stefansjfw]

Hey @stefansjfw

I installed the release from above, and there is no longer an "Unlock with File Locksmith" option in the Windows 11 context menu (it's present in the legacy menu).

Verb invocation works properly with that release, with the caveat that there is no modern explorer integration any more.

Exactly what I did:

1. Check with v0.84.0 -> "open" verb launches File Locksmith
2. Uninstall PowerToys -> "open" verb works properly
3. Install your custom release -> "open" verb works properly, no Win11 explorer integration
4. Kill and re-launch all explorer.exe processes -> no change

Was the initial issue referring to win11 contex menu or legacy one? Or both?

[iamcalledrob]

The initial issue is related to invoking a verb programmatically by name on an IContextMenu, e.g. specifying "open" for lpVerb in CMINVOKECOMMANDINFO.

As opposed to invoking by position by setting lpVerb to MAKEINTRESOURCE(position).

There has never been an issue at the visible UI level -- perhaps because Explorer will always invoke by position rather than verb?

[stefansjfw]

ok. thanks. I was able to reproduce the issue with the context menu invoked from WizTree app. The debut build I attached above fixes the issue there as well - likely the root cause of the issue is the same, i.e. WizTree using IContextMenu in the background.

Thanks for checking, I'll open the PR with the fix soon. There's no Win11 context menu entry because the build I sent is not signed, i.e., a sparse msix package that adds context menu entry must be signed to work

[iamcalledrob]

Amazing. I'm so curious to learn what the root cause was!

[zhuxb711]

@stefansjfw The root cause is File Smith handle all the verbs that do not related incorrectly, right?

[stefansjfw]

@stefansjfw The root cause is File Smith handle all the verbs that do not related incorrectly, right?

yes, FileLocksmith with this change skips verbs as it does not use verbs at all.