-
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
Windows Terminal not 100% shown in context menu #13523
Comments
Maybe related to powertoys as it happens just after powertoys updated to 0.60.x |
Hmm, that sure is weird. Can you file feedback using the Feedback Hub, under the "Desktop Environment > Right Click Context Menu" area/? I'm not sure there's much we can do to investigate here, but getting this to the team that owns the context menus might help the investigation. If you "Share" the |
I am very sure this problem is related to the latest version powertoys. If you want to fix it, you just need turn off Power Rename and Image Resizer. |
2 of 3 reasons I use powertoys are power rename and image resizer. So your fix seems painful for me... |
I'm gonna tentatively say that this is tracking upstream. If this comes back as not a PowerToys AND not an OS issue, then we can reopen if there's something for us to fix here. Thanks for following up! |
This comment was marked as outdated.
This comment was marked as outdated.
I'm actually gonna reopen this. We've got like, a LOT of crashes in There's no internal bug for this yet (weird), but it is in terminal/src/cascadia/ShellExtension/OpenTerminalHere.cpp Lines 100 to 129 in 4e5a0c1
Maybe there's a way for the array to be non-null but have 0 items in it? |
Promoted to MSFT:40872815 probably regressed in #13206 |
I'm pretty sure that we fixed this in https://github.com/microsoft/terminal/releases/tag/v1.15.2282.0 by reverting #13206. Thanks all! |
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
Windows Terminal version
1.14.1861.0
Windows build number
10.0.22622.290
Other Software
No response
Steps to reproduce
Expected Behavior
The "open in terminal" should display every time.
Actual Behavior
The "open in terminal" don't display every time. I can see it 1 time when I right click every around 6 times.
The text was updated successfully, but these errors were encountered: