Open cinnamon-msft opened 1 month ago
Unfortunately, there isn't really a way to do this reliably. Just my two cents, if a user explicitly selects don't restart on a modal dialog and gets confused later, it's on them. Most products that use these features will surface error messages about the feature not being enabled and that will hopefully prompt the user to remember that they ignored the restart prompt. We definitely don't want to force them to restart, and we can't deterministically query whether the feature is functional (querying for "Is Enabled" after enabling the feature, but before restarting will always say the feature is enabled rather than "restart required", arguably a shortcoming with the API). We could try to persist state across Dev Home launches and try to compare timestamps against restart times, but that gets overly complicated for a toggle that is already an advanced user scenario. The Windows settings app also has this behavior, so I'd argue we probably shouldn't do anything here.
Could the use of volatile registry keys help here? Set a volatile reg key saying a reboot is required, and query that on subsequent DevHome launches (the reg key itself would be deleted on reboot).
Could the use of volatile registry keys help here? Set a volatile reg key saying a reboot is required, and query that on subsequent DevHome launches (the reg key itself would be deleted on reboot).
yes, that's definitely an option. We risk the state machine getting more complex than the value benefiting the user. Currently this is stateless, we reflect exactly what the underlying feature management API reports, the banner is a tip/hint, that is supplementary. The user has to explicitly ignore the restart attempt, so maybe the best thing here is to simplify further, and just remove the banner.
Note too that any changes the user makes outside the context of Dev Home are not captured here, e.g. powershell, Windows Settings, etc.
So, the banner can still be incorrect if the user toggles a feature on in Dev Home, then toggles it off in Windows Settings. In this case, the banner will be hidden if Dev Home is the same instance as the first, but will show on the next launch if Dev Home is restarted.
@timkur / @cinnamon-msft - how do we make a decision here? We don't own this state, so building even more of a state machine on top of it doesn't seem appropriate, so tracking changes and reboots is not something I would recommend.
I would recommend leaving as-is, or if we don't care about the banner and just rely on the modal dialog, we can remove the banner entirely. I could go either way.
@timkur / @cinnamon-msft - how do we make a decision here? We don't own this state, so building even more of a state machine on top of it doesn't seem appropriate, so tracking changes and reboots is not something I would recommend.
I would recommend leaving as-is, or if we don't care about the banner and just rely on the modal dialog, we can remove the banner entirely. I could go either way.
Dev Home version
0.1501.547.0
Windows build number
No response
Other software
No response
Steps to reproduce the bug
Enable a setting in Windows customization that requires a restart (long file paths or WSL for example). A banner appears at the top saying I need to restart.
Expected result
If I close and re-open Dev Home, that banner should still be there until I've restarted.
Actual result
The settings appear enabled even though they actually aren't, and there's no banner.
Included System Information
No response
Included Extensions Information
No response