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.

Sign up for GitHub

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

Jump to bottom

Elevated applications can't be dragged into FancyZones #324

Closed
turnma opened this issue Sep 9, 2019 · 1 comment
Closed

Elevated applications can't be dragged into FancyZones #324

turnma opened this issue Sep 9, 2019 · 1 comment
Labels
Product-FancyZones Refers to the FancyZones PowerToy

Comments

@turnma
Copy link

turnma commented Sep 9, 2019

Environment

Windows build number: 18362.329
PowerToys version: 0.11.0
PowerToy module for which you are reporting the bug (if applicable): FancyZones

Steps to reproduce

Start an elevated command prompt
Attempt to drag it into a zone

Expected behavior

App should attach to a zone

Actual behavior

No zone highlights appear and the app cannot be attached to a zone. The issue appears to be common to all apps that are run elevated.

Screenshots

n/a
@turnma turnma changed the title Elevated applications can't be dragged into FancyZoes Elevated applications can't be dragged into FancyZones Sep 9, 2019
@enricogior enricogior added the Product-FancyZones Refers to the FancyZones PowerToy label Sep 10, 2019
@enricogior
Copy link
Contributor

@turnma
this is a system limitation due to security reasons.
To snap an elevated window to a zone, PowerToys/FancyZones should also run elevated.
We will not fix this problem since there isn't a way to fix it, but we will detect if the target window is elevated and notify the users if they want to run FancyZones elevated.
The work for that feature is tracked here #1015
I'm closing this issue since it can't be fixed.
Thanks.

ironyman pushed a commit to ironyman/PowerToys that referenced this issue Feb 17, 2025
@zadjii-msft
Hot (un)load extensions on (un)install (microsoft#375)
0fba556 
Closes microsoft#370 

The DevHome code was great for "I need something that can lookup extensions and enumerate all of them".

However, the DevHome code is a very blunt hammer when it comes to extensions. The only thing it tracks is "packages changed", and if it gets one of those, it just blows away all the extensions and rebuilds them. Yikes. 

This PR changes `ExtensionService` to be a scalpel. We'll keep `_installedExtensions` fresh. When we get a package install, we'll add only that package's extension to our cache, and let the `TopLevelCommandManager` know. Similarly for updates and uninstalls. 

That way, we can exactly change the top-level list as needed, rather than bluntly forcing all the extensions to reload. 

In the middle of all this, I fixed a bug where uninstalling an extension, then reloading would just fail to load extensions. This is because the old code would clear out the **whole** list of extensions when _one_ was uninstalled. That created a race where we'd be parsing the new list of all the extensions (from the reload), get an uninstall event, clear the list, then InvalidOperation as the list of extensions was modified during enumeration. 

There's a bunch more locking in here. This might drive-by microsoft#324 but hard to be sure. 

Related to microsoft#89
ironyman pushed a commit to ironyman/PowerToys that referenced this issue Feb 20, 2025
@zadjii-msft
Developer XAML version of TextToSuggest (microsoft#416)
93cad5d 
This is just a very rough prototype of "TextToSuggest", to make it do _something_. I'll link this to microsoft#358, but it's not clean enough to close it. 

I just slapped a TextBlock with the suggested text to the right of the input, just so users can see that there is a suggestion and that you can press `right` to accept it. 

The best extension to test this with is the Registry one, but that crashes heavily in `ListHelpers.InPlaceUpdateList`. I think it's for two reasons:
* a null item in the list? (we should ignore that!)
* and we're modifying the list as we're updating it (definitely shouldn't do that)

I'm guessing the second is actually the cause of microsoft#324, though I've had a hard time reproing that as of late.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Product-FancyZones Refers to the FancyZones PowerToy
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@enricogior @turnma