[Proposal] Run on OS Login

Hello WICG,

We would like to propose to bring a native capability to the web that allows applications to launch when the user logs into the OS.

Problem Many operating systems offer the ability to configure an application to launch automatically when the user logs into their OS session. Users can engage with those applications as soon as they log into the OS. Certain class of native applications including email and chat apps have been using this capability. We aim to add this capability to the web platform to empower web developers to provide the same first-class experience with their PWAs.

Proposal This is a powerful feature that would entail a performance and user-experience cost with applications launching at login. So, we think it should extend the standard permission registry with the “run-on-os-login” enum value. We propose JS APIs to prompt user a permission dialog and enable/disable the capability based on the user’s choice. We also propose an alternative way to get the user’s choice and enable the capability in the installation flow of a PWA via its web app manifest.

Here’s the exaplainer. For the folks who have read and provided feedback on our initial proposal, we updated the explainer with the API approach on May 27th, 2020. Here’s the list of issues we’re tracking.

Looking forward to your feedback.

Thanks, Jungkee Song on behalf of the feature crew

Why is this not something that people can choose to enable in the “PWA Settings” (assuming of course that these exist)?

A dialog like this means that the application gets the opportunity to run, but no reciprocal opportunity to be removed (because people don’t know where to look for that). At least the manifest-only option offers that opportunity, rather than being a demand for attention.

I realize that this is likely a browser-specific UX question, but I don’t think an application-controlled prompt strikes a good balance.

We have had both use cases in mind indeed. We expect that PWAs/browsers would provide ways to enable/disable the capability in their settings, which should be browser-specific UX choices as you pointed.

For developers, we expect the API approach would enable PWAs to provide a consistent settings UX across platforms and/or browsers. We’ve heard some developers want to implement scenarios where they can get their users notice the option in their own app flow - e.g. in the app’s first run experience UI as well as the app’s settings.

Also, note that we proposed to decouple the user permission and changing (enable/disable) the state of the capability to allow developers to implement such UIs (e.g. a checkbox or toggle button) to switch the state.