Re: [w3c/manifest] Add beforeinstallprompt event (#417)

Thanks for the detailed write up and thoughts... some reactions below. I think we should have a call and walk through everything in detail. I'll try to gather more feedback from folks internally also. If need be, I'm happy to fly out to Sydney for a day so we can go through this in detail (I'm in Melbourne, so no big deal for me). 

> permissions.query({name: 'install'}), to query whether it has been installed, can't yet be installed, or can be installed at the user's discretion, and

The installation itself is orthogonal: The `permissions.query({name: 'install'})` is an inquiry about the ability for the app to show the installation prompt. A successful install is still signaled by "oninstall" in my proposal. This is to cover the use case where installation is self-initiated by the end user (by digging through the menus or through an "ambient installation"). 

> Notably, it doesn't (and can't) remove anything from the base proposal.

It's unclear why it can't remove anything from the base proposal? It makes the base proposal redundant, for reasons you also state (but with caveats I questioned below):

 1. BIP is equivalent to `permission.onchange`. 
 1. `nav.installApp()` is `permissions.request({name: install})` when prompt state is available.

In the case of BIP and having a cancellable onchange event, that strikes me as architectural purity: is there a technical reason to not allow the event to be cancellable? That it "sounds totally wrong" needs further consideration, IMHO: It might be that in whatever we come up with, the UA never shows the install prompt automatically (allows for "ambient install"), and only ever allows the the developer to  `permission.request({install})`.

The above solves the problem in that BIP is not needed. `onchange` does not need to be cancellable, and gives control of the install prompt back to the developer - with the UA providing "ambient install" as a fallback. 

> So what do those two new capabilities buy us? 

I think this makes an incorrect presupposition: it presumes that because Chrome already has BIP and prompt(), that other implementations have this also (which they don't). So, when you say "us", it means "Chrome" in this case. In the case of Gecko, for instance, we already have the Permissions API - so what it buys "us" (Gecko) is one less API to add. 

I guess my point is: we can't take the current BIP (Chrome) model as a given - as we've seen, there is plenty of scope for improvements from what we've learned over the last years. 

> "silent transition"

I'm advocating for "silent transition". I think it strikes the right balance between UA, developer, and end-user control. 

> The user agents can decide on the above policies and change policies without having to update the spec. So that's kind of cool.

Agree. We still have a time to refine, experiment, etc. if we end up with a mixed policy. 

> We may not need an install event at all (the permissions.change event to "granted" may be sufficient, but see below).... There are lots of conceptual problems with "granted" meaning what you said it means.

Agree. "granted" remains highly ambiguous because there is a difference between "the installation process finished successfully (and a icon was placed somewhere successfully)", or "you were granted permission to install (which may or may not have succeeded)", or "the application is, and remains, 'installed' (for which the icon still available somewhere, maybe)". 

To me, "granted" can only mean "you were granted permission to install"... but if that succeeded, or if the icon remains on the home screen, is not in scope and is a different concern. The UA allowing multiple icons on the homescreen from mismanagement would likely be a bug. 

> the permissions system is about granting perpetual access to a resource, not taking a single action once.

I concede you may be right here. But I need to give this further consideration. However, this predicated on how we frame "granted" - and if it's only conceptual, then it might be workable to just treat it as a no-op. 

> @dominickng says the permissions API itself is still in flux.

This is true in as far that all specs are in flux, only because we shape them with our requirements :) 

> We still have problems with request(). Since request is supposed to prompt the user and if they say "OK" go into the "granted" state, what do we do? I guess it would have to be a no-op. 

Request is not required to do such a thing (or at least it should not be). If the request has been granted, then yes: it's a no-op. Once you are granted, you are granted. Only "prompt" allows a developer to put the a prompt in front of the end-user. 


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/417#issuecomment-230189032