Shell extension not available in folders which have "Libraries" as a root

[AlphaModder]

Windows Terminal version (or Windows build number)

1.9.1523.0

Other Software

No response

Steps to reproduce

• Go to a folder where the address bar displays This PC as the root in explorer (e.g. This PC > OS (C:) > MyFolder)
• Right click on the background. Verify that the Open in Windows Terminal menu item is present.
• Switch to a directory that is located inside a library (e.g. Libraries > Documents > MyFolder).
• Right click on the background (not a subfolder). The menu item no longer appears.

Expected Behavior

For a context menu like this to appear:

Actual Behavior

A context menu like this appears:

Notes

• This issue does not occur if the library is accessed through This PC, as in This PC > Documents > MyFolder
• With a registry-based shell extension, I think the solution would be to add a subkey under HKEY_CLASSES_ROOT\LibraryFolder\background\shell\, in addition to HKEY_CLASSES_ROOT\Directory\background\shell\. I'm not sure how this translates to the COM-based shell extension API.

[DHowett]

Good catch. Thanks!

[KalleOlaviNiemitalo]

On a related note… the Windows Terminal shell extension is available when I right-click the "Libraries" node in the navigation pane, but if I try to use it, I just get an error: "The parameter is incorrect."

[zadjii-msft]

Filed this upstream at MSFT:35409337. I'm not sure we're ever even getting Invoked in this scenario, so we might not have any chance at hacking our way around this one.

[zadjii-msft]

On Windows 11, I've seen that this will work when trying a folder inside a library, but not directly within the library itself. For example:
In "Libraries/Pictures"

but in Libraries\Pictures\screenshots (which does get resolved to %userprofile%\onedrive\pictures\screenshots):

---

The Explorer team did get back to me on this:

Libraries are not an actual location. They are virtual. They represent a merge of multiple locations. This is why you don't see "open in terminal" at the root of a library. There is not a place to open to in this case. Likewise, once you navigate into a folder within a library, you are now in an actual folder location, which is why you do see the option there.

Therefore, this is working as designed.

So, I guess we're gonna close this one out.

[AlphaModder]

@zadjii-msft Are there plans to backport the fix for the case for folders within a library (e.g. Libraries/Pictures/Screenshots) to Windows 10?