- From: Matt Giuca <notifications@github.com>
- Date: Mon, 17 Oct 2016 23:24:31 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Message-ID: <w3c/manifest/issues/417/254417873@github.com>
For the public record: between your second-most and most recent messages, we had an offline discussion where we concluded that we'd try to change prompt() to a fire-and-forget (non-promise-based) interface, but that we wouldn't move it out of the BeforeInstallPromptEvent. Responding to your most recent message: I spoke to Dom about this. He says that, in Chrome at least, the user-triggered add to homescreen and the automated (or site-controlled) install banner are independent. Even when there is no race condition, they are still independent and using one does not preclude the other. Take the following non-racey case: 1. BIP is fired. 2. App calls `.preventDefault()`. 3. App sets up a then on the `.userChoice` promise. 4. User chooses "add to homescreen" from browser's menu, and completes the install process. 5. App calls `.prompt`. This is like your use case but the installation fully completes before Step 5. In this case, the prompt is shown (despite the app already being installed) and the user can choose OK, which installs the app a second time. `userChoice` resolves once the user chooses on the prompt. So the answer is just that the two are independent. The app should be installed twice (the second install may be a no-op depending on the system; on Android it would actually create a second shortcut). As for the race case you outlined, well the system just has to deal with this; for example queueing up the prompt behind the existing install process. I don't think this is an invalid state. -- 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-254417873
Received on Tuesday, 18 October 2016 06:25:00 UTC