Add navigator.install()

[christianliebel]

This is a first pass for introducing navigator.install(). The goal is to specify a method that allows same-origin installs (current and background documents).

This draft currently only covers same-document installs (zero parameters) and does not take manifest IDs into account yet.

Relevant documents:

• Web Install API Explainer
• TAG feedback
• Discussion about requiring manifest ID
• The cross-browser future of Installable Web Apps (TPAC 2023)

Acknowledgements:

• The algorithm steps are largely inspired by the Web Share API.

---

Closes #???

This change (choose at least one, delete ones that don't apply):

• Adds new normative requirements

Implementation commitment (delete if not making normative changes):

• WebKit (https://bugs.webkit.org)
• Chromium (https://bugs.chromium.org/)
• Gecko (http://bugzilla.mozilla.org)

Commit message:

Add API for installing web applications

Person merging, please make sure that commits are squashed with one of the following as a commit message prefix:

• chore:
• editorial:
• BREAKING CHANGE:
• And use none if it's a normative change

---

Preview | Diff

[benfrancis]

I'm fascinated to see how this pans out given we now seem to have gone full circle from navigator.mozApps.install() in ~2012, and in the intervening time browser vendors have gone to great lengths (installability criteria, install prompts etc.) to avoid doing this.

Some questions:

• Is the intention still to eventually require that a manifest contains an id member in order for installation to succeed?
• If navigator.install() only works if the document links to a valid web app manifest, does this not further reinforce the idea that a web app needs a web app manifest in order to be installable (contrary to the definition recently added to the specification)?
• Are we OK with the idea that this will cause the web to be littered with install buttons (which as I understand it is the reason browser vendors have avoided doing this so far)?

I think on balance my advice (in the capacity of an Invited Expert) would be to not add this feature to the web platform, but to instead focus on how to improve the user interface that user agents provide to install web apps.

It is already possible for browser vendors to implement an "install app" feature inside user agents, which could be a more prominent and trusted user interface than an install button in each web app (e.g. an ambient indicator in a URL bar to indicate the current document is part of an installable web app, and a prominent "install app" button). Instead this feature currently tends to get buried inside multiple levels of menus or use obscure language like "add to home" rather than "install". Unfortunately I think this poor user experience is a result of misaligned incentives of the current incumbent "user agents" rather than a lack of creativity in user interface design.

If browser vendors continue to bury and obfuscate the install app feature then I can see why this API would be necessary, but I think the resulting user experience (spammy install buttons and prompts everywhere) would be worse for everyone.

---

As an aside, this is another example of something that could be much simpler to implement if a web app was identified by its manifest URL (navigator.install({manifest URL})).

[christianliebel]

@benfrancis This is all in flux. Drafting this first specification text was just my initiative to have a basis for discussion. No vendor has committed to implementing this.

I'm fascinated to see how this pans out given we now seem to have gone full circle from navigator.mozApps.install() in ~2012, and in the intervening time browser vendors have gone to great lengths (installability criteria, install prompts etc.) to avoid doing this.

Wow, interesting historical insights. I only joined this effort in 2018…

Is the intention still to eventually require that a manifest contains an id member in order for installation to succeed?

This is up to the Working Group to decide. Safari has traditionally allowed the installation of all websites regardless of any preconditions. This would also suggest navigator.install(documentURL) so a linked manifest can be loaded, or the default manifest can be created for the document at the given URL. As a web developer, it would be great to have a single way to trigger the installation of an app, regardless of the platform.

If navigator.install() only works if the document links to a valid web app manifest, does this not further reinforce the idea that #1168 (contrary to the #1163)?

(see above)

Are we OK with the idea that this will cause the web to be littered with install buttons (which as I understand it is the reason browser vendors have avoided doing this so far)?

We already have beforeinstallprompt in Chromium-based browsers (see the related discussion in MicrosoftEdge/MSEdgeExplainers#1055) to do this, and haven't seen a larger littering of install buttons yet.

I think on balance my advice (in the capacity of an Invited Expert) would be to not add this feature to the web platform, but to instead focus on how to improve the user interface that user agents provide to install web apps.

The idea of the Web Install API would be to allow same-origin installations as well, e.g. example.com could suggest to install example.com/docs or example.com/sheets. Same-origin installs also have TAG approval. I think improving the install UX is an orthogonal effort.