Re: [w3c/manifest] Add installation prompt control flow (#417)

> .onappinstall isn't necessarily the same as ev.userChoice = "accepted". The user could accept the banner, but the app might fail to install for a bunch of reasons. WebAPKs are a good example of this, as is the bookmark app system which Chrome uses on desktop.

I completely agree, but the fundamental question is: does the app need to know about these (system) failures? If so, what is the use case for them knowing? There is not much the application can do to recover.

If notifying the application of installation does have a valid use case, then we need to also handle the case where BIP is not involved... so we would need a `.onappinstallerror` or some such event handler.  

> I hazily remember initially speccing prompt() as a synchronous method returning a bool, but it was suggested to make it a promise to allow UAs more flexibility in case they needed to do async work in the method.

The return value is orthogonal to any asynchronous work. In Gecko, the work (of requesting some king of install overlay) will definitely need to be done asynchronously. 

But the question about if the application has any business/use-case about knowing these details is what I'm questioning. 

> I don't mind overly here (changing Chrome's implementation to return a bool is probably fine since I don't think many people at all actually use the promise returned by prompt). But retaining the flexibility in the API does seem like a good thing (naively).

It depends on what the return value reveals - and the use case for that information. 
 

-- 
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-254094781