Skip to content
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

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

Merged
merged 2 commits into from
Sep 21, 2022

Conversation

DHowett
Copy link
Member

@DHowett DHowett commented Sep 20, 2022

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)

References #13206
References #13523
Closes #12578
@ghost ghost added Area-ShellExtension For issues related to the explorer right-click context menu Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) Product-Terminal The new Windows Terminal. labels Sep 20, 2022
@DHowett
Copy link
Member Author

DHowett commented Sep 20, 2022

/cc @leejy12 :) thanks for looking at this with us! I'd appreciate your review and signoff, if you can, since you're the most familiar with this code.

@DHowett
Copy link
Member Author

DHowett commented Sep 20, 2022

I have to test this on Windows 10 19041!

@DHowett DHowett changed the title OpenHere: Replace the fxplorer Window lookup code with site lookup OpenHere: Replace the explorer window lookup code with site lookup Sep 20, 2022
Copy link
Contributor

@leejy12 leejy12 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! 🎉

src/cascadia/ShellExtension/OpenTerminalHere.h Outdated Show resolved Hide resolved
@DHowett DHowett changed the title OpenHere: Replace the explorer window lookup code with site lookup OpenHere: Replace explorer window lookup code w/ site lookup Sep 21, 2022
@DHowett DHowett merged commit 5027c80 into main Sep 21, 2022
@DHowett DHowett added this to To Cherry Pick in 1.15 Servicing Pipeline via automation Sep 21, 2022
@DHowett DHowett added this to To Cherry Pick in 1.16 Servicing Pipeline via automation Sep 21, 2022
@DHowett DHowett moved this from To Cherry Pick to Cherry Picked in 1.16 Servicing Pipeline Sep 21, 2022
DHowett added a commit that referenced this pull request Sep 21, 2022
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
@lhecker lhecker deleted the dev/duhowett/shellext-site-chain branch September 21, 2022 18:49
@ghost
Copy link

ghost commented Sep 23, 2022

🎉Windows Terminal Preview v1.16.2641.0 has been released which incorporates this pull request.:tada:

Handy links:

@DHowett DHowett moved this from To Cherry Pick to Cherry Picked in 1.15 Servicing Pipeline Sep 27, 2022
DHowett added a commit that referenced this pull request Sep 27, 2022
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
@DHowett DHowett moved this from Cherry Picked to Validated in 1.15 Servicing Pipeline Sep 28, 2022
@ghost
Copy link

ghost commented Oct 18, 2022

🎉Windows Terminal v1.15.2874 has been released which incorporates this pull request.:tada:

Handy links:

@ghost
Copy link

ghost commented Dec 14, 2022

🎉Windows Terminal Preview v1.16.3463.0 and v1.16.3464.0 has been released which incorporates this pull request.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-ShellExtension For issues related to the explorer right-click context menu Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) Product-Terminal The new Windows Terminal.
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

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