Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web Manifest - install API
• Specification or proposal URL: Allowing only site-triggered install prompt w3c/manifest#627

Relevant folks at Mozilla: @andreasbovens, @snorp.

Other information

This is a request for position on a potential feature, not the web manifest spec itself.

tl;dr: should we add an .install() method and .checkIfInstalled() (not final names), to allow web applications to be installed? If yes, what security/privacy characteristics should such an API have? Or will we end up with "🚨INSTALL MY WEEEEB APPPS NOW!!!🚨" buttons all over the web?

The web manifest spec provides basic information about a web application, such as icons, name, preferred orientation, etc. As of 2018, the Web Manifest spec has facilitated the ability to "add [a web application] to homescreen" in Chrome, Firefox for Android, Microsoft Edge, and, very recently, Safari in iOS.

In architecting the web manifest spec, we (the spec Editors) deliberately resisted adding an API that would allow sites to explicitly request installation (i.e., an .install() method). Our hope was that browsers would provide innovative UX solutions to informing a user that a web application is "installable" (whatever that may mean on the OS or browser).

We now find ourselves basically ~5 years on and we've seen various approaches, but none of them are ideal.

Installability signals

Installability signals were a set of UA-specific heuristics championed original by Chrome, that, if met, the browser displayed:

This had a few issues:

• The banner popup was unpredictable. Chrome kept having to adjust their heuristics in a way that would make interoperability a challenge.
• could interrupt the user while they were performing a task (or just reading content).
• Was quite disruptive, covering significant part of the content.

BeforeInstallPromptEvent

In order to give control back to developers, Chrome folks proposed a BeforeInstallPromptEvent that notified developers before the install prompt above was shown.

The purpose was to, preventDefault(), and give the developer an opportunity show their own "install button". The BeforeInstallPromptEvent, then provided a .prompt() method, that showed the install banner.

window.addEventListener("beforeinstallprompt", event => {
  // Suppress automatic prompting.
  event.preventDefault();

  // Show the (disabled-by-default) install button. This button
  // resolves the installButtonClicked promise when clicked.
  installButton.disabled = false;

  // Wait for the user to click the button.
  installButton.addEventListener("click", async e => {
    // The prompt() method can only be used once.
    installButton.disabled = true;

    // Show the prompt.
    const { userChoice } = await event.prompt();
    console.info(`user choice was: ${userChoice}`);
  });
});

However, this API was somewhat clunky and racy, in that it could fine sporadically.

Ambient badging

Opera software pioneered ambient badging:

This also suffered from discoverability issues. It's not immediately obvious to users that they can install the application.

Complex menus to get to "add to homescreen"

Even before iOS added web manifest support, developers were UA sniffing to point to users as to where they need to click to install a web application:

The above situation did not change in the recent release of Safari on iOS: developers still need to do UA sniffing and explicitly point to parts of the browser's UI to encourage users to install a web application.

Do we need an install API?

Reflecting on the approaches we (implementers) tried, over the last few years, it feels like we succeeded in surfacing that web apps were "installable"... but failed to create UXs that meets the needs of developers in an interoperable manner.

It might be time to reconsider adding an Install API. Basically, the requirements we have:

• Must be "SecureContext".
• Must be triggered by user activation.
• By default, only exposed on top-level browsing context.
• Optional, time limited (like pop-up blocker rules or rate-limited payment request).
• Must provide a means to check if app is already installed - so not to show an install button unnecessarily.
• For backwards compat, browsers can continue to use ambient badging, installability signals, etc. That is, we don't need to tie it explicitly to the web manifest itself.

Thoughts?