Terminal shouldn't be offered as an option in the context menu for Quick Access background #12578

zadjii-msft · 2022-02-25T14:32:38Z

When I right-click on the background of File Explorer "Quick Access," Terminal shouldn't be offered as an option because it doesn't do anything there

Presumably we can filter if we're visible based on the path that was provided to us.

zadjii-msft · 2022-02-25T18:51:38Z

From internal mail:

So, in their IExplorerCommand::GetState, I think they could have a check for that against the IShellItemArray that gets passed in.

bool IsFileSystemItem(IShellItem* shellItem)
{
    SFGAOF attributes;
    return (shellItem->GetAttributes(SFGAO_FILESYSTEM, &attributes) == S_OK);
}

We may also want to compare notes with MSFT:36909951

Shomnipotence · 2022-02-26T01:56:00Z

Open with... dialog cannot choose the All the Apps from Microsoft Store

This commit hides the "Open in Terminal" context menu option when the context menu is opened in a non-filesystem path like "Quick Actions". Closes #12578

This commit hides the "Open in Terminal" context menu option when the context menu is opened in a non-filesystem path like "Quick Actions". Closes #12578 (cherry picked from commit fb1491a) Service-Card-Id: 83524152 Service-Version: 1.14

ghost · 2022-07-06T18:06:01Z

🎉This issue was addressed in #13206, which has now been successfully released as Windows Terminal v1.14.186.:tada:

Handy links:

ghost · 2022-07-06T18:07:51Z

🎉This issue was addressed in #13206, which has now been successfully released as Windows Terminal Preview v1.15.186.:tada:

Handy links:

ghost · 2022-08-17T23:29:10Z

🎉This issue was addressed in #13206, which has now been successfully released as Windows Terminal v1.14.228.:tada:

Handy links:

ghost · 2022-08-17T23:29:52Z

🎉This issue was addressed in #13206, which has now been successfully released as Windows Terminal Preview v1.15.228.:tada:

Handy links:

zadjii-msft · 2022-08-18T11:48:13Z

Lol the bot thought that it should comment here because of the revert 😅

I'm reopening this cause we reverted this to fix #13523. I think there's an OS bug, at least on Windows 11, that doesn't let us know the difference between "My PC" and the desktop background. Both show up with an empty array and a null path from explorer. So that's useless.

zadjii-msft · 2022-08-22T21:42:20Z

Upstream issue is now MSFT:41029797

leejy12 · 2022-09-07T03:15:15Z

Regarding #13523

The reason that "Open in Terminal" isn't shown consistently when desktop is right clicked is that on Windows 11, the default context menu is made of fancy XAML controls, and the Window Class name of the foreground window is sometimes reported as XamlExplorerHostIslandWindow, not Progman or WorkerW.

In OpenTerminalHere::_GetPathFromExplorer(), I think we can add an additional check to work around this issue.

if (0 == StrCmp(szName, L"WorkerW") ||
    0 == StrCmp(szName, L"Progman") ||
    0 == StrCmp(szName, L"XamlExplorerHostIslandWindow"))

From #13206 (comment)

Okay I'm pretty sure this caused #13523. Turns out that there's a non-zero rate of the shell giving us 0 items in the array. I can check for that easy enough, but it seems like still returning ECS_HIDDEN for that results in the menu entry not always appearing for the desktop.

I'll need to noodle more

Is there a way to reproduce the case where psiItemArray is not nullptr but psiItemArray->GetCount returns 0? (I assume this is why OpenTerminalHere::GetState() was crashing often). I've never succeeded in observing this behavior.

Also, the PR that originally fixed this issue was reverted in the internal repo, right? Will the revert make its way to this public repo?

DHowett · 2022-09-07T15:40:26Z

Also, the #13206 that originally fixed this issue was reverted in the internal repo, right? Will the revert make its way to this public repo?

~~This PR~~ The revert was made against and merged into the public repository. There is no private/internal copy of the Windows Terminal source; we do all development right out here in the open! 😄

Edited to correct for me having misread your question. The commit that reverts it is 2d00432 on release-1.14 and 76daf71 on release-1.15. We kept it on in main so we could have builds to repro the issue with.

DHowett · 2022-09-07T15:44:34Z

Good find on the Xaml...Window thing! Do you think that the rest of the explorer lookup logic will work with that HWND as well?

leejy12 · 2022-09-07T17:06:12Z

Edited to correct for me having misread your question. The commit that reverts it is 2d00432 on release-1.14 and 76daf71 on release-1.15. We kept it on in main so we could have builds to repro the issue with.

Thanks for the clarification!

Good find on the Xaml...Window thing! Do you think that the rest of the explorer lookup logic will work with that HWND as well?

I think so. Even when the context menu is open in Explorer, the foreground window's class name is always reported as CabinetWClass.

When we first introduced the shell extension, it didn't work properly for some folders (such as the Desktop, or perhaps any "background" click) due to a bug in Windows. We worked around that bug with the help of an awesome community member, who contributed code that would pull up the topmost Explorer window and query its location. That Windows bug was eventually fixed, but we still had trouble with items appearing correctly. On Windows 11, the Open in Terminal menu item appears and disappears at random when you right-click the desktop, but it always appears when you right-click a folder. It sometimes appears for Quick Access, even though it shouldn't. We tried to fix that in #13206, but the fix caused more issues than it solved. We reverted it for 1.15 and 1.16. At the end of the day, it turns out that getting the path from the toplevel explorer window is fragile. Fortunately, the shell does offer us a way to get that information: the site chain. This pull request replaces GetPathFromExplorer() with an implementation of `IObjectWithSite`, which allows us to use the site chain to look up from whence a context menu request was initiated. It also makes item lookup generally more robust. ✅ Tested on Windows 11 ✅ Desktop ✅ Folder Background ✅ Folder Selected ✅ Quick Access (does not appear) ✅ This PC (does not appear) References #13206 References #13523 Closes #12578

When we first introduced the shell extension, it didn't work properly for some folders (such as the Desktop, or perhaps any "background" click) due to a bug in Windows. We worked around that bug with the help of an awesome community member, who contributed code that would pull up the topmost Explorer window and query its location. That Windows bug was eventually fixed, but we still had trouble with items appearing correctly. On Windows 11, the Open in Terminal menu item appears and disappears at random when you right-click the desktop, but it always appears when you right-click a folder. It sometimes appears for Quick Access, even though it shouldn't. We tried to fix that in #13206, but the fix caused more issues than it solved. We reverted it for 1.15 and 1.16. At the end of the day, it turns out that getting the path from the toplevel explorer window is fragile. Fortunately, the shell does offer us a way to get that information: the site chain. This pull request replaces GetPathFromExplorer() with an implementation of `IObjectWithSite`, which allows us to use the site chain to look up from whence a context menu request was initiated. It also makes item lookup generally more robust. * ✅ Tested on Windows 11 * ✅ Desktop * ✅ Folder Background * ✅ Folder Selected * ✅ Quick Access (does not appear) * ✅ This PC (does not appear) * ✅ Tested on Windows 10 * ✅ Desktop * ✅ Folder Background * ✅ Folder Selected * ✅ Quick Access (does not appear) * ✅ This PC (does not appear) References #13206 References #13523 Closes #12578 Co-authored-by: John Lueders <johnlue@microsoft.com>

When we first introduced the shell extension, it didn't work properly for some folders (such as the Desktop, or perhaps any "background" click) due to a bug in Windows. We worked around that bug with the help of an awesome community member, who contributed code that would pull up the topmost Explorer window and query its location. That Windows bug was eventually fixed, but we still had trouble with items appearing correctly. On Windows 11, the Open in Terminal menu item appears and disappears at random when you right-click the desktop, but it always appears when you right-click a folder. It sometimes appears for Quick Access, even though it shouldn't. We tried to fix that in #13206, but the fix caused more issues than it solved. We reverted it for 1.15 and 1.16. At the end of the day, it turns out that getting the path from the toplevel explorer window is fragile. Fortunately, the shell does offer us a way to get that information: the site chain. This pull request replaces GetPathFromExplorer() with an implementation of `IObjectWithSite`, which allows us to use the site chain to look up from whence a context menu request was initiated. It also makes item lookup generally more robust. * ✅ Tested on Windows 11 * ✅ Desktop * ✅ Folder Background * ✅ Folder Selected * ✅ Quick Access (does not appear) * ✅ This PC (does not appear) * ✅ Tested on Windows 10 * ✅ Desktop * ✅ Folder Background * ✅ Folder Selected * ✅ Quick Access (does not appear) * ✅ This PC (does not appear) References #13206 References #13523 Closes #12578 Co-authored-by: John Lueders <johnlue@microsoft.com> (cherry picked from commit 5027c80) Service-Card-Id: 85788409 Service-Version: 1.16

ghost · 2022-09-23T16:56:09Z

🎉This issue was addressed in #14048, which has now been successfully released as Windows Terminal Preview v1.16.2641.0.:tada:

Handy links:

When we first introduced the shell extension, it didn't work properly for some folders (such as the Desktop, or perhaps any "background" click) due to a bug in Windows. We worked around that bug with the help of an awesome community member, who contributed code that would pull up the topmost Explorer window and query its location. That Windows bug was eventually fixed, but we still had trouble with items appearing correctly. On Windows 11, the Open in Terminal menu item appears and disappears at random when you right-click the desktop, but it always appears when you right-click a folder. It sometimes appears for Quick Access, even though it shouldn't. We tried to fix that in #13206, but the fix caused more issues than it solved. We reverted it for 1.15 and 1.16. At the end of the day, it turns out that getting the path from the toplevel explorer window is fragile. Fortunately, the shell does offer us a way to get that information: the site chain. This pull request replaces GetPathFromExplorer() with an implementation of `IObjectWithSite`, which allows us to use the site chain to look up from whence a context menu request was initiated. It also makes item lookup generally more robust. * ✅ Tested on Windows 11 * ✅ Desktop * ✅ Folder Background * ✅ Folder Selected * ✅ Quick Access (does not appear) * ✅ This PC (does not appear) * ✅ Tested on Windows 10 * ✅ Desktop * ✅ Folder Background * ✅ Folder Selected * ✅ Quick Access (does not appear) * ✅ This PC (does not appear) References #13206 References #13523 Closes #12578 Co-authored-by: John Lueders <johnlue@microsoft.com> (cherry picked from commit 5027c80) Service-Card-Id: 85788408 Service-Version: 1.15

ghost · 2022-10-18T21:50:31Z

🎉This issue was addressed in #14048, which has now been successfully released as Windows Terminal v1.15.2874.:tada:

Handy links:

ghost · 2022-12-14T20:44:25Z

🎉This issue was addressed in #14048, which has now been successfully released as Windows Terminal Preview v1.16.3463.0 and v1.16.3464.0.:tada:

Handy links:

zadjii-msft added this to the Backlog milestone Feb 25, 2022

ghost added the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Feb 25, 2022

zadjii-msft added good first issue This is a fix that might be easier for someone to do as a first contribution and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Feb 25, 2022

zadjii-msft mentioned this issue Mar 18, 2022

"open in terminal" context menu shows in "This PC" and does nothing #12717

Closed

leejy12 mentioned this issue May 30, 2022

Hide "Open in Terminal" context menu option appropriately #13206

Merged

ghost added the In-PR This issue has a related PR label May 30, 2022

ghost closed this as completed in #13206 May 31, 2022

ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels May 31, 2022

ghost pushed a commit that referenced this issue May 31, 2022

Hide "Open in Terminal" context menu option appropriately (#13206)

fb1491a

This commit hides the "Open in Terminal" context menu option when the context menu is opened in a non-filesystem path like "Quick Actions". Closes #12578

zadjii-msft reopened this Aug 18, 2022

zadjii-msft removed Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. good first issue This is a fix that might be easier for someone to do as a first contribution labels Aug 18, 2022

zadjii-msft mentioned this issue Sep 8, 2022

"Open with Windows Terminal" context menu not display on desktop (or right click without selected folder) #11839

Closed

DHowett mentioned this issue Sep 20, 2022

OpenHere: Replace explorer window lookup code w/ site lookup #14048

Merged

ghost added the In-PR This issue has a related PR label Sep 20, 2022

DHowett closed this as completed in #14048 Sep 21, 2022

ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. Needs-Tag-Fix Doesn't match tag requirements and removed In-PR This issue has a related PR labels Sep 21, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Terminal shouldn't be offered as an option in the context menu for Quick Access background #12578

Terminal shouldn't be offered as an option in the context menu for Quick Access background #12578

zadjii-msft commented Feb 25, 2022

zadjii-msft commented Feb 25, 2022

Shomnipotence commented Feb 26, 2022

ghost commented Jul 6, 2022

ghost commented Jul 6, 2022

ghost commented Aug 17, 2022

ghost commented Aug 17, 2022

zadjii-msft commented Aug 18, 2022

zadjii-msft commented Aug 22, 2022

leejy12 commented Sep 7, 2022

DHowett commented Sep 7, 2022 •

edited

Loading

DHowett commented Sep 7, 2022

leejy12 commented Sep 7, 2022

ghost commented Sep 23, 2022

ghost commented Oct 18, 2022

ghost commented Dec 14, 2022

Terminal shouldn't be offered as an option in the context menu for Quick Access background #12578

Terminal shouldn't be offered as an option in the context menu for Quick Access background #12578

Comments

zadjii-msft commented Feb 25, 2022

zadjii-msft commented Feb 25, 2022

Shomnipotence commented Feb 26, 2022

ghost commented Jul 6, 2022

ghost commented Jul 6, 2022

ghost commented Aug 17, 2022

ghost commented Aug 17, 2022

zadjii-msft commented Aug 18, 2022

zadjii-msft commented Aug 22, 2022

leejy12 commented Sep 7, 2022

DHowett commented Sep 7, 2022 • edited Loading

DHowett commented Sep 7, 2022

leejy12 commented Sep 7, 2022

ghost commented Sep 23, 2022

ghost commented Oct 18, 2022

ghost commented Dec 14, 2022

DHowett commented Sep 7, 2022 •

edited

Loading