[UWP App Model] Proposal: Improve register-app-for-start-at-log-in Experience #46
Comments
Does this mean that if the app is disabled in settings, the app has no way to re-enable itself and has to get the user to go back to the settings dialog? |
|
@michael-hawker Yes. Just as with UWP/DesktopBridge apps today, the moment the permission is disabled in Settings by the user themself the app can no longer programmatically give itself that permission. The user will first have to allow the app to start at log-in via the Settings app again. |
|
@jesbis Should I move this issue to Project Reunion? |
|
I think that makes sense - if no objections I can just directly move this issue to that repo? |
|
@jesbis No objections from me 🙂 |
|
One for @andreww-msft ... @Felix-Dev , I think you're saying that "if the app itself disables its task, then calls enable, do not show a prompt at all." So we'd only only ever show the prompt once on first request, then either (a) the app has disable/re-enabled it so no prompt (b) the user has toggled back on the task in startup so there's no prompt. That correct? Correct, #10 is about providing a similar API for Win32 apps that want startup task behavior without having to write it themselves. |
|
@jonwis Yes, that is correct. Essentially, what I'm proposing here is to bring over the current DesktopBridge Startup Task API behavior to UWP apps minus the ability of DesktopBridge apps to set their initial startup behavior to "enabled" in their manifest. (If the user disabled startup for the app in Windows Settings, all bets are off for the app and the user will have to enable startup for this app in Windows Settings again.) |
|
Let me see if I understand:
If the foregoing is accurate, the problem is that calling Disable also changes the setting. That means there's a chance that in the meantime the user could've gone to Settings to disable it and found it already disabled, and they rely on the fact that if the app tried to enable it later they'd get a prompt. Given this, I believe we should err on the side of caution, and we should not change this behavior. |
|
@andreww-msft Yes, you understood it correctly.
Good point. I guess it's reasonable then to keep the current behavior. |
Do you still have the project file for this or on Github so I can see how this works? The Github example from MS only comes in UWP which can be found here. https://github.com/microsoft/AppModelSamples/tree/master/Samples/TestRestart/TestRestart Apologies for not seeing the |
Proposal: Improve register-app-for-start-at-log-in Experience (UWP App Model)
Summary
Using the StartupTask API app developers can register their app to automatically start at log-in. The API is available for both UWP apps and DesktopBridge apps (MSIX-packaged Win32 apps). Depending on the "app model" this API has a different User Experience and I want to highlight one major difference in this proposal.
The linked documentation above states the following:
It is this user-consent dialog which is at the heart of this proposal.
If the user has granted an UWP app start at log-in permission in the Windows Settings app, every subsequent API pair call of
StartupTask.Disable()and permission-grantingStartupTask.RequestEnableAsync()will trigger this user-consent dialog (*1). You can observe this behavior in the following GIF below. In this GIF the app initially has its start at log-in permission granted in the Settings app.(*1) (If the user has denied the app this permission in the Settings app or denies the request using the user-consent dialog, the next call to
StartupTask.RequestEnableAsync()will fail and show no such dialog.)Now observe how the API behaves when calling it from a DesktopBridge app given the documentation above. Again, the app already was granted start at log-in behavior by the user in the Settings app (or the Task Manager):
As stated in the documentation, as long the app start at log-in has been disabled with a
StartupTask.Disable()call, a subsequent call toStartupTask.RequestEnableAsync()will enable app start at log-in without asking for user consent again.This does not feature the, what I consider, bad UX of UWP apps where a user is asked twice if they really want to enable automatic app start. (First ask is the user clicking the ToggleSwitch button, second ask is the user-consent dialog prompt.) The UX here should be fast and straight-forward and should not require by default to have the user confirm their choice whenever they want to enable start-at-log-in for the app in question.
Proposal: UWP apps should feature the same straight-forward register-app-for-start-at-log-in experience as DesktopBridge apps come with as shown in the GIF above.
It is important to note that this proposal will not result in the user losing control over their apps! As long as the user denies the app start at log-in permission in the Settings app, a call to
StartupTask.RequestEnableAsync()will not succeed:As this GIF shows, if the user denied the app permission in Windows Settings at the time of the request, the app cannot programmatically set itself as a startup app.
For each UWP app, the system default is that the user has not granted the app permission to start at log-in. As such, even without the user actively denying the app permission, the app's very first call to
StartupTask.RequestEnableAsync()since installation will also fail. It will, of course, require the user to first actively grant the app this permission in the Settings app.No malicious app can use the absence of the user-consent dialog as outlined in this proposal to just do as it pleases. The user still rules!
Scope
(*2) Or denied the request using the user-consent dialog prompt.
Additional Context
@BenJKuhn Feedback Hub entry here.
Attached Files
I created a sample project showcasing the current behavior for both UWP and DesktopBridge apps. Please check that out if you still have questions regarding the different behavior:
StartupSandboxDemo.zip
The text was updated successfully, but these errors were encountered: