Comments on Run on OS Login

[dominickng]

Overall, I'm still a bit on the fence about whether this particular API is necessary on the web platform, but I don't want to block experimentation. Here are some comments on the explainer:

Scope

I think it should be noted in the explainer that this is a purely desktop functionality. Mobile OSs do not permit applications to be run on login / startup.

Availability

What restrictions are placed on calling the API to ensure it is not abused / spammy like permission prompts can be?

Additionally, trusting a web app to provide the ability to disable running on login seems somewhat optimistic. Is it worth strengthening the suggests that user agents provide a way for users to identify web apps that are running on OS login, and disabling them?

Mode

I'd suggest making this correspond to the web app manifest display-mode values and choose standalone to indicate opening in windowed mode.

Privacy

as it is already possible for native applications to be auto started

This is something of a disingenuous comparison since there is currently no way for a web site to request that it be started on login. Privacy considerations generally aren't about comparing to existing native functionality, but rather existing functionality on the web platform. Right now, users have to explicitly launch an installed web app; this functionality lets that web app start automatically, and that is new to the web platform.

I also think there is room for guidance to implementations here regarding the scope of what is automatically started. Most browsers have a "continue where you left off" type feature. Launching a web app at login should not also restart the browser and its previous tab state, as that greatly increases the scope of the sites able to observe the user for longer than they might expect.

Use of permissions API

As noted in #342, this is a rather unusual application of the permissions API for several reasons (ergonomics, non-availability in non-installed contexts). I'd strongly suggest not using the permissions API here since it's not a good fit.

[Garbee]

Right now, users have to explicitly launch an installed web app; this functionality lets that web app start automatically, and that is new to the web platform.

This is not strictly true. As it is right now, there is an inter-browser incompatibility here that needs to be flushed out. For example, I can properly launch a PWA on Edge Canary during (MacOS) startup but not from Chrome Canary.

Steps to test (on MacOS):

1. Install a PWA ( https://airhorner.com will do for the test ) from Edge and Chrome.
2. Go to System Preferences > Users > Select your user > Login Items
3. Using the plus sign icon at the bottom of the application list, select $HOME/Applications/Chrome Canary Apps/The Air Horner to be added to startup
4. Logout
5. Login
6. Observe Chrome Canary starts along with the PWA instance, but neither show a window visible to the user. Canary will once clicked on, but the PWA is dead until quit and manually started.
7. Go back to the login items list in system preferences
8. Remove the Chrome Canary application and add the Edge Canary install in its place.
9. Logout
10. Login
11. See the PWA properly boot and show the window along with Edge Canary starting in the background.

So users can currently have a PWA start on login. It just depends on the exact browser being used whether it fully works or not. So we need to decide:

1. Is this is desired behavior?
2. Do we want to expose this to web developers so they can let users know it is possible and seamlessly allow it?

Personally I can see a discussion leading to us wanting to allow the behavior to happen, but for now possibly not expose a direct API for web apps. Instead leave it in settings and have the browser facilitate the OS level integrations needed. Then users as they wish can use the native facilities or browser settings to achieve the tasks. For example, the dock on MacOS allows users to right click, go to Options, then select "Open at login" to add/remove a login item. Later we could assess a developer-facing API if that becomes a big contention point.

[dominickng]

Thanks for the comment. I think the "existing incompatibility" you have described is not exposed to the web platform, but rather a user explicitly modifying their system to change its behaviour in a way that the web cannot directly control.

An analogy might be saying that installed web apps already have the ability to resize their own window bounds because on Windows, the user can edit the command line invocation in the desktop shortcut to include ones which specifically set the window size. Technically, yes, users can edit what starts up on certain OSs manually. But the whole discussion here is about whether or not we should expose a new ability to the web platform: to explicitly set and control startup behaviour, and we should say as such in the privacy considerations rather than comparing to situations where users are changing the system beyond the reach of the web platform.

If we end up not exposing an API to the web, then there is less need for this discussion - it's focused on the impact of exposing new APIs to the web on the user. Instead, competitive forces drive whether other browsers adopt these features. :)

[Garbee]

Ah, thanks for the follow-up context. I think I initially had one interpretation in my mind of the concern as I read it since it was under the Privacy header. You're coming from it a few degrees over from where my head space was at.

With this new understanding, I went to write a follow-up here. But it's gotten quite large and I don't want to deter from the other points you've brought up for discussion. So I'm going to flush that thought out more and make a new issue on the privacy considerations section to help improve it.

I would like to be clear on my remark of "now possibly not exposing an API." I think as a last resort if we can't find consensus on that aspect there is potential to move forward and decide on that later. That way we could at least have standardized behavior guidelines and expectations for browsers with this capability that is emerging as modern web applications become more integrated with the desktop.