Contact emails [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> Explainer https://aka.ms/webinstall Specification https://github.com/w3c/manifest/pull/1175 Design docs
https://docs.google.com/document/d/12nSXJLm8mW0gWZ_yjlXfrV8r9gwJliVt4WVa-209-KA/edit?tab=t.0 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 Blink>AppManifest<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EAppManifest%22> Web Feature ID navigator-install<https://webstatus.dev/features/navigator-install> Search tags web install<https://chromestatus.com/features#tags:web%20install>, install<https://chromestatus.com/features#tags:install> TAG review https://github.com/w3ctag/design-reviews/issues/1051 (Although this is technically the early design review, we went through several rounds of feedback off of this that influenced the shape of the API significantly) TAG review status Issues open Origin Trial Name WebAppInstallation 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. Chromium Trial Name WebAppInstallation Origin Trial documentation link https://aka.ms/webinstall WebFeature UseCounter name WebDXFeature::kNavigatorInstall Risks Interoperability and Compatibility Interop - Low risk. This is a new API that installs web apps, which are supported by other browsers. The no argument version of the API (installs the current document) has enough support to be merged into the W3C web app manifest spec - https://github.com/w3c/manifest/pull/1175. It has also been reviewed favorably by TAG - https://github.com/w3ctag/design-reviews/issues/1051. 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. This is a new API that requires explicit developer action to use. Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1179) WebKit: No signal (https://github.com/WebKit/standards-positions/issues/463) Web developers: Positive (https://github.com/w3ctag/ethical-web-principles/issues/120#issuecomment-2285348765) https://github.com/w3ctag/ethical-web-principles/issues/120#issuecomment-2285431557 Other signals: pwastore.io - https://www.reddit.com/r/PWA/comments/1o1excp/comment/niit2jh/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button 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 See security considerations for both current document and background document functionality - current document - https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebInstall/explainer-current-doc.md#accessibility-privacy-and-security-considerations background document - https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebInstall/explainer-background-doc.md#accessibility-privacy-and-security-considerations 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? N/A Reason this experiment is being extended We are requesting an extension so that navigator.install can run in parallel with the HTML Install Element origin trial (approved to start in 153), which is the new, declarative entry point to the same installation capability. We have metrics in place to enable direct comparison of the entry points, and we now need the community to tell us which they prefer. 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. Is this feature fully tested by web-platform-tests<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? No. Web app installs are not supported in WPT, but we are adding tests to cover Blink-specific precondition failures (e.g. malformed input, illegal contexts, etc) DevTrial instructions https://microsoftedge.github.io/Demos/pwa-web-install-api Flag name on about://flags web-app-installation-api Finch feature name WebAppInstallation Requires code in //chrome? False Tracking bug https://issues.chromium.org/issues/333795265 Measurement We have a JavaScript UseCounter and WebDX feature - https://chromestatus.com/metrics/webfeature/timeline/popularity/375 We will also implement chromium UMAs and possibly UKMs for the API service results. Estimated milestones Origin trial desktop first 143 Origin trial desktop last 148 Origin trial extension 1 end milestone 153 Origin trial extension 2 end milestone 153 DevTrial on desktop 139 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5183481574850560?gate=5595120835624960 Links to previous Intent discussions Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DB9PR83MB05184F25E5FEE4595055FE34CC042%40DB9PR83MB0518.EURPRD83.prod.outlook.com Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/ame_t7wN2cU Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/KCpVX8F6yh8/m/Fbs3p4PdAwAJ This intent message was generated by Chrome Platform Status<https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH3PR00MB267356EB5428C4233B819ECFD35EA%40CH3PR00MB2673.namprd00.prod.outlook.com.
