-
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
Clearly differentiate running elevated vs. drag/drop breaking #14946
Conversation
…/drop Credit where credit is due - @jboelter did literally all the hard work. I just separated this out to two elements: * Are we running elevated? * Can we drag drop? As we learned in #7754, the builtin administrator _can_ drag drop. But critically, they are also running as admin! The way we had this logic before, we're treat them as unelevated, because we had been overloading the meaning here. This splits these into two separate functions. Comes with the added benefit of re-adding the elevation shield to the Terminal window for users with UAC disabled (which was missing before) (and can _still_ be disabled). Closes #13928 Tested on a Win10 VM with `EnableLua=0`
This comment has been minimized.
This comment has been minimized.
…then it's not fine. Fine, fine.
Thanks God! Finally someone spotted this! But my tests on Windows 11 shows that drag&drop file is still not working (with EnableLUA=0) |
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.
Letting you handle merging this in case you want to apply my suggestions.
} | ||
}(); | ||
|
||
return !isDragDropBroken; |
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.
I mean, you did the hard part of writing the logic. Why not remove the double negative by...
isDragDropBroken
-->canDragDrop
- L681
false
-->true
- L693
true
-->false
- L697
!isDragDropBroken
-->canDragDrop
(pipe the !
into the returned results, basically)
_isElevated = ::Microsoft::Console::Utils::IsRunningElevated(); | ||
_canDragDrop = ::Microsoft::Console::Utils::CanUwpDragDrop(); |
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.
I guess this kinda isn't relevant to this PR but why do these two members exist? We're using magic statics in Utils, so what's the point in caching these values?
(I chose to merge without seeing your comments -- @zadjii-msft, mind tracking them?) |
Credit where credit is due - @jboelter did literally all the hard work. I just separated this out to two elements: * Are we running elevated? * Can we drag drop? As we learned in #7754, the builtin administrator _can_ drag drop. But critically, they are also running as admin! The way we had this logic before, we're treat them as unelevated, because we had been overloading the meaning here. This splits these into two separate functions. Comes with the added benefit of re-adding the elevation shield to the Terminal window for users with UAC disabled (which was missing before) (and can _still_ be disabled). Closes #13928 Tested on a Win10 VM with `EnableLua=0` (cherry picked from commit c5c15e8) Service-Card-Id: 88484047 Service-Version: 1.17
Credit where credit is due - @jboelter did literally all the hard work.
I just separated this out to two elements:
As we learned in #7754, the builtin administrator can drag drop. But critically, they are also running as admin! The way we had this logic before, we're treat them as unelevated, because we had been overloading the meaning here.
This splits these into two separate functions. Comes with the added benefit of re-adding the elevation shield to the Terminal window for users with UAC disabled (which was missing before) (and can still be disabled).
Closes #13928
Tested on a Win10 VM with
EnableLua=0