[Web Install] duplicates BIP

[marcoscaceres]

Hi Diego,

just following up after meeting with @dmurph and we identified potential blocker for .install() API as currently proposed.

There are a number of issues:

1. A precondition of .install() is that the manifest has loaded, which causes race condition with user/transient activation: transient activation might expire before the manifest has loaded. Also, if .install() must meet any conditions to be called, and it throws, then it's the user that is left frustrated because there's an install button there, but it fails when pressed.

2. There is significant usage of BIP, which Chromium has changed to be deterministic.

The preconditions for installing are that there be a manifest, possibly that it has an ID, and maybe other browser specific things. Also, calling .install() should result in the install sheet/prompt being shown.

If BIP has a significant amount of usage, and it meets the requirements, and it’s causing site-compat issues with Safari, we should probably fix BIP and not introduce a new mechanism that does effectively the same thing.

Thoughts?

[christianliebel]

BIP would only solve the same-document install case, and the API is quite unusual (receiving the prompt from an event). As a web developer, it would be quite nice to just have navigator.install(). This matches the vendors' consensus that installations should always be possible, regardless of certain preconditions such as a manifest being present.

So, it should be fine to just call navigator.install() to bring up the install dialog. The install dialog could still fetch the manifest or apply the default manifest for the given site (I think this is what Safari does). However, this would also mean that no restrictions, like a manifest ID being present, can be imposed.

To prevent buttons that aren't actually able to install another manifest, and to check the presence of an ID, and maybe for future-proofing such as for cross-origin installs, we could also consider a navigator.canInstall() method, as suggested before.

Related: w3c/manifest#1175

[dmurph]

Answer to 1) is that the transient activation is consumed by the install API call, not by the manifest loading. In a way BIP makes transient activation harder here instead of easier.

[diekus]

The .install method could do a reasonable wait for the manifest link to be added or know that a manifest is being downloaded. In that case the promise would be pending. If the process throws for whatever reason and causes the promise to reject, the site can know and just update the UI accordingly and either offer to navigate or resolve it in a different way.

BIP depends on the UA, and there's no guarantee that the event will fire. Additionally, as Christian points out this only works for the current loaded document. Thinking about developer ergonomics, it seems better to have a way to do .install() in a way that proves effective and not by waiting and having to prevent/intercept an unreliable event.

I see the install method as the way forward to acquire apps on both mobile and desktop, with a simpler approach than that of BIP and easier to futureproof if we wanted to standardize installing content from another origin or web bundles or whatever comes our way.

[marcoscaceres]

@dmurph assured me that BIP is deterministic in Chromium. Can someone point to Chromium’s code? MDN is not an authoritative source.

[diekus]

@marcoscaceres are there any meeting notes from this meeting you had with @dmurph ? It is hard to followup on this conversation without context, special on a feature that my team is leading.