search

microsoft / devhome

The new Dev Home experience for Windows!
https://aka.ms/devhomedocs
MIT License
3.54k stars 309 forks source link

Windows customization "restart" banner doesn't persist #3362

Open cinnamon-msft opened 1 month ago

cinnamon-msft commented 1 month ago

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

nieubank commented 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.

timkur commented 1 month ago

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).

nieubank commented 1 month ago

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.

nieubank commented 1 month ago

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.

nieubank commented 1 month ago

@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.

nieubank commented 1 month ago

@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.