Powertoys: [PowerToys Run] Enabling PT Run from settings takes a few seconds to reflect in the json file

Created on 17 Sep 2020  ·  10Comments  ·  Source: microsoft/PowerToys

ℹ Computer information

  • PowerToys version: master (https://github.com/microsoft/PowerToys/commit/85c0eaa5980cabab16089fea3a2c6f148242a368)
  • PowerToy Utility: Settings/PT Run
  • Running PowerToys as Admin: No
  • Windows build number: [run "winver"] 2004

📝 Provide detailed reproduction steps (if any)

  1. Enable PT Run and disable it.
  2. Check the general settings.json file

✔️ Expected result

_What is the expected result of the above steps?_
File gets updated immediately with "PowerToys Run":false.

❌ Actual result

_What is the actual result of the above steps?_
File takes a few seconds to get updated.

This bug seems to only occur for PT Run, and enabling works fine, its only disabling which has this delay. It seems like this happens because at the same time PowerLauncher.exe is loading, and it might be waiting for the load to complete for some reason. We should ideally ensure this update happens independently and isn't blocked by the update on PowerLauncher.
The end-user effect is that if a user disable PT Run and closes PT within 5 seconds the setting will not persist and PT Run will still be enabled on re-launching PT.

Issue-Bug Product-Launcher Product-Settings Resolution-Duplicate

All 10 comments

@crutkas @saahmedm @ryanbodrug-microsoft FYI

Is the enable disable bug fixed in master yet?

Not yet, but it's independent of that PR.

Look at #6620 and see what the impact of that fix will have on this.

620 doesn't fix this, I first reproduced this while testing that PR, but found that it is present on master as well.

Good to know, same area which is why I asked :)

I'm going to put this into the current release as it is unclear why this is having the issue but others are not which makes me wonder if there is some type of bug

@arjunbalgovind This issue is happening because WaitForSingleObject is used here , which blocks the calling thread until WPF app is terminated. Replacing it with RegisterWaitForSingleObject should fix this issue.

if that is the case, this should be a super easy fix if it is a single line #famousLastWords

Closing this as duplicate against #5860, since fixing that will also fix this issue.

Was this page helpful?
0 / 5 - 0 ratings