Chrome 68 Beta: add to home screen, payment handler, page lifecycle

June 7th, 2018

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, macOS, and Windows. View a complete list of the features in Chrome 68 on Chrome 68 is beta as of June 7, 2018.

New add to home screen behavior for progressive web apps

We’ve heard from developers that they want more control over how and when the add to home screen prompt appears. Starting in Chrome 68 on Android, the behavior is changing to provide more control over when the prompt appears. Developers can now provide additional context for their add to home screen experience, and improve the click-through rate.

If a site meets the add to home screen criteria, Chrome will fire a beforeinstallprompt event, and no longer automatically show the add to home screen banner. Instead, when the event has fired, developers can save the event and add a button or other UI element to the app to indicate it can be installed. When the user clicks the install button, developers can call prompt() on the saved beforeinstallprompt event to show the new add to home screen modal dialog. Although the beforeinstallprompt event may be fired without a user gesture, calling prompt() requires one.

let installPromptEvent;
window.addEventListener('beforeinstallprompt', (event) => {
// Prevent Chrome <= 67 from automatically showing the prompt
// Stash the event so it can be triggered later.
installPromptEvent = event;
// Update UI notify the user they can add to home screen
document.querySelector('#install-button').disabled = false;

As a temporary measure to provide developers with time to handle the beforeinstallpromptevent and add an install button to their app, Chrome will show a mini-infobar the first time the user visits a site that meets the add to home screen criteria. Once dismissed, the mini-infobar will not be shown again until a sufficient amount of time (currently 3 months) has passed.

See Changes to add home screen behavior for complete details, code samples and screenshots of the new UI elements.

Payment Handler API

The Payment Request API brought the web a simpler, faster way to check out online by combining a seamless native-browser UI with a user’s preferred form of payment and shipping addresses.

The just-launched Payment Handler API extends the reach of Payment Request by enabling web-based payment apps to facilitate payments directly within the Payment Request experience.

const request = new PaymentRequest([{
  // Your custom payment method identifier comes here
  supportedMethods: ''
}], {
  total: {
    label: 'total',
    amount: { value: '10', currency: 'USD' }

Protecting users from unwanted destinations

In this version of Chrome we are changing a few user interface behaviors to improve users’ experience.

Require user gesture for redirects in cross-origin iframes

Unless forbidden by the sandbox attribute, content embedded in an iframe can generally navigate the top-level browsing context to a different website. This functionality is used by many types of websites, including single-sign-on providers and payment processors. Unfortunately, this behavior is also a common abuse vector, redirecting users to unwanted destinations without their knowledge or consent.

Beginning in Chrome 68, content embedded in an iframe will require a user gesture to navigate the top-level browsing context to a different origin. Similar to pop-up blocking, when this protection triggers users will see Chrome UI giving them the option to allow the redirect the continue.

A demonstration illustrates the behavior. The demo behind this link will exhibit the old behavior in Chrome 67 and early. The improved behavior works in Chrome 68.

Block tab-under navigations

A tab-under is when a page both opens a popup to some destination and navigates the opener page to some third-party content. Typically this behavior is used to send the user to a desired destination while also creating another tab with an unwanted destination. Similar to pop-ups, Chrome will prevent these unwanted navigations and instead show native UI to the user so they can choose whether to follow this redirect to the new direction.

The Page Lifecycle API

Application lifecycle is a key way that modern operating systems manage resources. On Android, iOS and recently Windows, apps can be started and stopped at any time by the platform. This allows these platforms to streamline and reallocate resources where they best benefit the user.

On the web, there has historically been no such lifecycle, and apps can be alive indefinitely. With large numbers of web apps (and tabs) running, critical resources such as memory, CPU, battery, and network can be oversubscribed, leading to a bad end-user experience.

In Chrome 68, developers will be able to listen for and respond to system-initiated CPU suspension of backgrounded tabs using the new freeze and resume events. In cases where a frozen page needs to be discarded to conserve memory, the document.wasDiscarded property is now available so developers can restore view state (saved in the freeze event) when the user refocuses the tab and the page is reloaded. Developers wanting to test these events in their own applications can visit chrome://discards to simulate page freezing, resuming, and discarding.

For more information on the Page Lifecycle API, refer to the specification or the explainer on GitHub.

Other features in this release


Accept two values in the overflow shorthand

The overflow shorthand will accept two values, making it possible to set the horizontal and vertical overflow to different values. If two values are specified, the first is overflow-x and the second is overflow-y. Changing the shorthand allows developers to specify a single statement where previously two were required.

CSS position values with three parts

The object-position and perspective-origin properties will no longer accept three-part values like "top right 20%". This also applies for positions in basic shapes and gradients. Valid position values will now always have 1, 2 or 4 parts. Deprecation of 3-part values occurred in Chrome 66.

Support ‘x’ as a resolution unit

CSS Values and Units Module Level 4 defines a new resolution unit called “dot per pixel” for support of high-resolution displays. This change adds 'x' as a synonym for the existing abbreviation, 'dppx'.

Unprefix CSS “grab” and “grabbing” values for cursor property

The CSS values “grab” and “grabbing” change the mouse cursor to an open hand or closed hand, commonly used to indicate that something can be grabbed or is currently grabbed. Prefixed versions of these properties have been supported since Chrome 1. With this change Chrome will support the standard, unprefixed versions of these values.


High resolution timestamp for Gamepad

Gamepad.timestamp now uses a DOMHighResTimeStamp, a high resolution monotonic time with microsecond resolution. Timestamps are measured as offsets from the PerformanceTiming.navigationStart property.

Custom elements

New customElements.upgrade()

This function invokes custom element constructors for custom elements whose constructors are not called yet explicitly. If a custom element is created with the innerHTML setter and its parent node is not connected to a document, the custom element constructor is not called until it’s connected. This method explicitly allows developers to fully control the timing of custom element constructor calls regardless of connectedness.


Keyboard lock

While in fullscreen, this API allows apps to receive keys that are normally handled by the system or the browser like Cmd-Tab/Alt-Tab, or Esc. Users can escape keyboard lock (and fullscreen) by holding the Esc key for two seconds.

Make PointerEvent.fromElement and PointerEvent.toElement null

To improve consistency with other browsers, PointerEvents for fromElement and toElement fields not follow the Pointer Events Level 2 spec by always reporting null.
In a MouseEvent (from which a PointerEvent inherits these fields), fromElement and toElement are non-standard, and have been inconsistent among major browsers for many years. Moreover, there are standard and consistent alternatives already: target and relatedTarget.

Unified touch adjustment

Touch adjustment changes the TouchEvent and the corresponding PointerEvent target to a best target within the touch area. TouchEvent coordinates will not be changed.

Treat long-press as a user gesture

Long-press is now considered a user gesture because it indicates user interaction with the page. This allows a web app to call restricted APIs like navigator.vibrate() on long-press to match native behavior.


WebAudio: add user selectable automation rate for AudioParams

The AudioParam.automationRate
attribute allows the user to select whether the AudioParam is either “a-rate” or “k-rate”. Most but not all AudioParam attributes allow changing the rate, as given in the spec.

For example, BiquadFilterNode with default “a-rate” automation is expensive to compute due to the complex relationship between the parameters and the filter coefficients. If this fast automation is not needed (the most typical case), the parameters can be set to “k-rate”.


Improve cache management for service worker scripts

The HTTP cache will be ignored when requesting updates to the service worker. Requests for importScripts will still go through the HTTP cache. But this is just the default. A new registration option, ServiceWorkerRegistration.updateViaCache is available that offers control over this behavior.

Previously, HTTP requests that checked for updates to the service worker were fulfilled by the HTTP cache by default. If a Cache-Control header was inadvertently set on a service worker, then service worker updates could be delayed, and if your service worker contained versioning information for your sites other assets, those updates would also be delayed.


RTCRtpSender.getParameters()/setParameters() return and control track encoding

The getParameters() and setParameters() methods return or update the RTCRtpSender object’s current parameters for how the RTCRtpSender.track property is encoded and transmitted to a remote RTCRtpReceiver. These methods enable you to change encoding parameters for WebRTC streams such as the maximum transmission bitrate without doing any SDP munging or renegotiation.

Deprecations and interoperability improvements

Chrome sometimes deprecates, removes, or changes features to increase interoperability with other browsers. This version of Chrome includes the following such changes.

Deprecate and remove negative brightness values in filter

For compliance with specification, filter’s brightness() function no longer accepts negative values.

Remove document.createTouch

The document.createTouch() method is being removed because the Touch() constructor has been supported since Chrome 48.

Remove Document.selectedStylesheetSet and Document.preferredStylesheetSet

The Document.selectedStylesheetSet and Document.preferredStylesheetSet attributes are removed because they are non-standard and only implemented by Chrome and WebKit. The standard versions of these attributes were removed from the spec in 2016.


Previously, Chrome provided the AMD_compressed_ATC_texture formats. Hardware support has dwindled to near-zero, so the extension has been rejected by the WebGL Working Group. Support for it has been removed.