microsoft / microsoft/PowerToys
[Settings] Quick Access module toggle leaves already-open module page stale
- Dominant language
- C
- Stars
- 139k
- Forks
- 8.6k
- PR merge metrics
- PR metrics pending
Description
### Microsoft PowerToys version
0.101.2222.0
### Installation method
Public per-user installer
### Area(s) with issue?
Settings, Quick Access
### Steps to reproduce
1. Open PowerToys Settings and navigate to **Mouse Utilities**.
2. Ensure **Find My Mouse** is enabled and keep this page open.
3. Open Quick Access, select **All apps**, and disable **Find My Mouse**.
4. Return to the existing Mouse Utilities page without navigating to another Settings page.
5. Check the Find My Mouse toggle on that page and on Home.
6. Navigate to another Settings page, then return to Mouse Utilities.
7. Repeat in the opposite direction by enabling Find My Mouse from Quick Access.
### Expected behavior
The already-open module page should immediately reflect a module enable/disable change made through Quick Access, just as Home and Quick Access do. Re-enabling the module should update the same existing page without requiring navigation or page recreation.
### Actual behavior
The actual module state changes correctly:
- Quick Access shows the new state.
- The root `settings.json` value changes.
- The module action becomes available or unavailable as expected.
- Settings Home updates to the new state.
However, the toggle on the already-open Mouse Utilities page remains stale. Navigating away and back recreates the page and then displays the correct value.
This reproduced consistently in both directions:
- **On to Off:** the existing page remained visually On for at least eight seconds while Home and the recreated page showed Off.
- **Off to On:** the existing page remained visually Off for at least five seconds and after foregrounding Settings, while Home and the recreated page showed On.
This appears to be deterministic page-lifecycle behavior rather than a timing race.
### Regression and source analysis
The previous behavior explicitly supported live synchronization:
- The v0.96 Settings verification baseline required an already-open module Settings page to update when its state was changed from the flyout.
- In v0.96, the in-process flyout's `AllAppsViewModel.EnabledChangedOnUI` called `ShellPage.UpdateGeneralSettingsCallback`.
- That callback persisted and sent the state change, then called `ShellHandler.SignalGeneralDataUpdate()` to refresh the current `IRefreshablePage`.
PR #43840 moved Quick Access into a separate process to improve flyout launch performance. In the current path, Quick Access sends a `module_status` message to Runner; Runner updates the module and settings file, but the existing Settings page is no longer directly told to call `SignalGeneralDataUpdate()`.
The current code also explains the surface-specific result:
- `DashboardViewModel` subscribes to `SettingsRepository.SettingsChanged`, so Home refreshes.
- `MouseUtilsViewModel` reads the enabled state when created and supports explicit `RefreshEnabledState()`, but does not subscribe to `SettingsChanged`.
- Recreating the page therefore reads the correct current state.
PR #43840 did not document intentionally removing live page synchronization. Later PRs #44699 and #44734 addressed Quick Access sorting and module-status IPC reliability, respectively, but did not restore existing-page refresh behavior.
### Duplicate search
I searched open and closed issues for Quick Access/Settings synchronization, stale toggles, and Find My Mouse. I did not find an issue describing this existing-page synchronization failure.
### Additional information
This was found while running the Settings release checklist against the installed public build. The test state was restored after verification.
Contributor guide
Research direction
Start with the Quick Access `module_status` path through Runner, then compare `DashboardViewModel` and `MouseUtilsViewModel` handling of `SettingsRepository.SettingsChanged` and `RefreshEnabledState()`. Trace the existing `SignalGeneralDataUpdate()` entry point and the current-page refresh lifecycle. Done means an already-open Mouse Utilities page updates in both directions without navigation, while Home and recreated pages continue to show the correct state.
Written by the indexing model from the issue text.
Assessment
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 58/100