-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hide "Open in Terminal" context menu option appropriately #13206
Conversation
invalid location Closes #12578 Validated on my machine
@check-spelling-bot ReportUnrecognized words, please review:
Previously acknowledged words that are now absentazurewebsites Checkin condev Consolescreen css cxcy DCompile debolden deconstructed devicefamily dxp errno FARPROC GETKEYSTATE guardxfg HPAINTBUFFER HPROPSHEETPAGE iconify ipa LLVM LPCHARSETINFO MAPVIRTUALKEY MSDL mspartners ned newcursor nlength NOWAIT PENDTASKMSG pgorepro pgort PGU Poli PPORT redistributable SOURCESDIRECTORY Timeline timelines toolbars unintense UWA UWAs VKKEYSCAN wddmconrenderer wdx windev WResult xfgTo accept these unrecognized words as correct (and remove the previously acknowledged and now absent words), run the following commands... in a clone of the git@github.com:leejy12/terminal.git repository
✏️ Contributor please read thisBy default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.
If the listed items are:
See the 🔬 You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The check-spelling action will run in response to your push -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. 😉 🗜️ If you see a bunch of garbageIf it relates to a ... well-formed patternSee if there's a pattern that would match it. If not, try writing one and adding it to a Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines. Note that patterns can't match multiline strings. binary-ish stringPlease add a file path to the File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.
|
if (psiItemArray == nullptr) | ||
{ | ||
const auto path = this->_GetPathFromExplorer(); | ||
*pCmdState = path.empty() ? ECS_HIDDEN : ECS_ENABLED; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can psiItemArray
be nullptr
? If it's usually never nullptr
, we should probably just return ECS_ENABLED
. This would at least not be worse than the previous solution.
And I believe _GetPathFromExplorer
might be too slow for fOkToBeSlow == FALSE
. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that if we open the context menu on a blank area of Explorer (no items selected), then psiItemArray
is nullptr
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lhecker there's also an issue in older versions of Windows where psiItemArray
would be nullptr
even when the user had selected an item.
FYI I've slightly edited your pull request message to include a brief description and to remove the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to consider checking fOkToBeSlow
before doing _GetPathFromExplorer
. 🤔
(After measuring how long _GetPathFromExplorer
needs on average.)
I just checked locally, and On my PC, I think on less performant devices, the context menu could flicker for a split second because the verb is initially "Loading..." in gray, which eventually gets replaced with "Open in Terminal" or gets hidden. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! Thank you!
@msftbot merge this in 5 minutes |
Hello @carlos-zamora! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
Thanks for fixing this @leejy12! |
🎉 Handy links: |
🎉 Handy links: |
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 |
Yea, unless I get something more clever to actually re-enable this, then I think we're going to have to revert this. I suspect that having it hidden on the desktop is just more painful than having it visible in "My PC". I've got a line out to try and learn more about why there might be 0 entries, but unless we come up with something fast, I think we should revert this. |
We used to always return |
Alas, it seems that the "This PC" case AND the Desktop BG case both hit the null array path from my limited testing. I wish there was a better way to debug attach to the dllhost that spawns for this 😕 |
🎉 Handy links: |
🎉 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) 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
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
…crosoft#13206)" This reverts commit 93b5dff.
…crosoft#13206)" This reverts commit 93b5dff.
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