Explainer
Specification
Design docs
Summary
Allows a website to install a web app. The API provides 3 signatures, with 0, 1, and 2 parameters, respectively. When invoked, the website installs either itself, or another site from a different origin, as
a web app (depending on the provided parameters). All 3 signatures will be experimented with in parallel.
*Terminology - A site installing itself is a "current document install". A site installing another site is a "background
document install".
Blink component
Web Feature ID
Search tags
TAG review
TAG review status
Issues open
Origin Trial documentation link
Risks
Interoperability and Compatibility
Interop - Low risk.
While the argument versions of the API (installing a document in the background) are still under discussion in WICG, we have no reason to believe there will be interop risk with these additions.
Compatibility - Low risk.
Ergonomics
This could be used in conjunction with the navigator.getInstalledRelatedApps API, which tells a developer if any related web apps are installed for their site, before attempting to install with navigator.install. There
is overlap between navigator.install and the BeforeInstallPrompt event. navigator.install is more ergonomic, and we think developers will prefer its declarative install. See this thread -
https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1055
Activation
No activation risks. It should be relatively easy for developers to take advantage of this feature immediately, as-is. The API was designed with ergonomics in mind, and we have four places with instructions for developers (two test sites, the explainer itself,
and a Developer Trial README)
Security
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No information provided
Goals for experimentation
We are looking to answer the following questions about the current API surface with this experiment to aid in further developments of the feature. We’ve added 2 new UKMs and 2 UMAs, in addition to preexisting
web app/permissions metrics, to help in answering these questions during the experiment.
1 - Is there evidence of abuse or annoyance in the API's prompt surfaces (permission and installation)?
metric(s) - App installation rate per origin; Permissions metrics, such as rate of prompt denial, or permission disablement in site settings.
2 - Is there a spike in uninstallations, that would indicate user regret, or lack of UX clarity?
metric(s) - Amount of apps uninstalled within 1 hour of installation.
3 - Do developers understand the manifest id requirements of the API?
metric(s) - Rate of DataErrors returned to the renderer.
4 - The API has 3 signatures, and can do 2 types of installations, as well as app launches. Are developers understanding and effectively using all signatures?
metric(s) - JS use counter data; success rate of both current and background installs; CTR of app launch dialog.
Ongoing technical constraints
None
Debuggability
Existing DevTools support for promise-based JS APIs. No new DevTools support is needed.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No
Windows, Mac, Linux, and ChromeOS will be shipped first. Android will be supported later, due to significant technical
deviation in the web app ecosystem - https://issues.chromium.org/issues/424497410.
As of now, no plan to support Android WebView.
No
Web app installs are not supported in WPT, but we will add a WPT manual test.
DevTrial instructions
Flag name on about://flags
web-app-installation-api
Finch feature name
WebAppInstallation
Requires code in //chrome?
False
Tracking bug
Measurement
Estimated milestones
|
Origin trial desktop first
|
144
|
|
DevTrial on desktop
|
139
|
Link to entry on the Chrome Platform Status
Links to previous Intent discussions