Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 77 is beta as of August 8, 2019.

New Performance Metrics

Largest Contentful Paint

It has not always been easy for developers to measure how quickly the main content of a web page loads and is visible to users. The usefulness of existing metrics varies. Some metrics are only measurable in a lab, while others tell nothing about content that users care about. Consider the example below, taken from a DevTools performance audit. At the time of the first contentful paint, there's no content on screen that a user can interact with.



Largest Contentful Paint attempts to provide more meaningful data by using the largest content element as a proxy for when the main content of the page is likely visible to users.

You're probably asking questions like what does the new metric track? When is the metric reported? How do I improve it if it's slow? For answers to these and other questions, see "Largest Contentful Paint" on web.dev.

First Input Timing

The PerformanceEventTiming interface provides timing information about the latency of the first discrete user interaction, specifically one of key down, mouse down, click, or the combination of pointer down and pointer up. Pointer down may be the start of scrolling, which is not tracked. This is a subset of the EventTiming API, but will be exposed in advance because it provides key metrics to help measure and optimize responsiveness.

New Form Capabilities

Many websites use custom form controls to either add features that aren't available in standard controls or to tailor a form's design. A drawback of custom controls is that data must be stored in hidden <input> elements.

Two new features support custom form controls. The formdata event lets sites use JavaScript instead of hidden <input> elements to add data to a form. With this feature, site builders add a formdata event listener to a form element. The passed event includes a FormData object containing the data being submitted, which can now be modified.

The formdata event only lets sites interact with the submission process. Form-associated custom elements let site creators build custom elements that act like built-in form controls, providing capabilities such as enabling input validation or submitting data to the server.

To learn more and to see example code, read More capable form controls on web.dev.

Origin Trials

This version of Chrome introduces the origin trials listed below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones listed below, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

A Contact Picker for the Web

The Contact Picker API is a new, on-demand picker that allows users to select entries from their contact list and share limited details of the selected entries with a website. It allows users to share only what they want, when they want, and makes it easier for users to reach and connect with their friends and family. See A Contact Picker for the Web for details.

Other features in this release

Enter Key Hint

The enterkeyhint content attribute
is an enumerated attribute for <form> elements that specifies what action label (or icon) to present as the enter key on virtual keyboards. This allows authors to customize the presentation of the enter key to make it more helpful for users. The attribute takes one of enter, done, go, next, previous, search, or send.

Feature Policy Control over Document.domain

The document-domain policy governs access to document.domain. It is enabled by default, and, if disabled, attempting to set document.domain will throw an error.

Layout Instability Monitoring

Adds the LayoutShift interface
to the Performance API, allowing developers to monitor changes to a DOM element's on-screen position.

Limit the "referer" Header's Length to 4kB

Strips the referer header down to an origin when it's size exceeds 4kB.
Servers will often behave in unexpected ways when presented with an overly-long referer header. This is unfortunate, because referer is one header whose length attackers generally retain control over when generating no-cors requests.

Limit registerProtocolHandler() url Argument to http/https

The registerProtocolHandler() now only accepts URLs with http or https schemas. Because the intent of the API is to allow an endpoint to handle something like an SMS message, for example, it doesn't make much sense for handlers to be data URLs, blob URLs, and so on.

New Features for Intl.NumberFormat

This change improves Intl.NumberFormat by adding support for measurement units, currency and sign display policies, and scientific and compact notation.

Overscroll Behavior Logical Longhands

Adds CSS flow-relative properties for controlling overscroll behavior through logical dimensions. flow-relative properties are those that are interpreted relative to the flow of content. The new properties are overscroll-behavior-inline and overscroll-behavior-block.

PerformanceObserverInit Buffered Flag

Adds a buffered flag to observer.observe() so that PerformanceObserver can receive entries created before the call is executed.

WebRTC

RTCPeerConnection.onicecandidateerror
Adds the incecandidateerror event which provides detailed information about WebRTC ICE candidate gathering failures, including the ones defined by STUN (RFC5389) and TURN (RFC5766).

Diagnosing ICE connectivity issues without access to detailed gathering failures can be a challenge. Support for ICE candidate errors is targeted towards better connectivity troubleshooting and network diagnostics.

RTCPeerConnection.restartIce()
Adds a method for triggering an ICE restart which causes a WebRTC connection to try to reconnect. This feature is already available in Chrome by passing the iceRestart argument to createOffer(). restartIce() is a version of this method that works regardless of signalingState.

Service Workers

Preserve Request Priorities through Service Worker
Preserves a request's original priority when it passes through a service worker. Previously, all requests going through a service worker would get "High" priority. This means render-blocking style sheets would have their priority clamped, while less important resources would get boosted.

Service Workers Support Basic HTTP Authentication
Displays HTTP authentication dialog boxes even if the request was from a service worker. This shows the native login dialog shown when an HTTP 401 response is received.

Stop Action for Media Sessions

Adds stop as a MediaSessionAction for calls to MediaSession.setActionHandler(). An action is an event tied specifically to a common media function such as pause or play. The stop action handler is called when the site should stop the playback and clear the state if appropriate. Samples are available on GitHub.

Web Payments: Throw a TypeError on Invalid "basic-card" Data

The PaymentRequest constructor now throws a TypeError when invalid supportedNetworks or supportedTypes are specified for basic card payment.

See Deprecations and Removals for an additional Web Payments update item. For more about recent web payments updates, see W3C Payment API changes in Chrome 77.

Interoperability Improvements

Support Step Timing Functions jump-start|end|both|none

Adds support for a richer set of step animations. Firefox already supports jump-* step timing functions. The step timing functions jump-both, jump-none, jump-start and jump-end were introduced to the spec for easing functions in 2018. Two of these, jump-start and jump-end are aliases for start and end. The remaining two provide increased flexibility for step transitions by enabling step functions in which both or neither endpoint has a discontinuous step. Previously, one and only one of the two endpoints could have a step discontinuity. Adding support in Chromium improves cross-browser interoperability.

white-space: break-spaces

Adds the break-spaces value for the white-space property which specifies that any sequence of preserved white space that would otherwise overflow a line and hang (as per the CSS Text Module spec's Trimming and Positioning rules) must be broken.

With white-space: pre-wrap it's possible to wrap and preserve white space sequences in the middle of a text line. However, if there is a sequence at the end of the line, it either collapses or hangs, maybe overflowing its box area. The new value overflow-wrap: break-spaces allows authors to wrap and preserve these white space sequences. This can be also useful for textarea or contenteditable elements, so that white space sequences added by spacebar press events are handled properly and generate line breaks if needed. Finally, there is an ongoing effort to enhance interoperability of the line breaking CSS properties (white-space, word-break and overflow-wrap) and this new value was defined precisely to achieve that.

Deprecations, and Removals

Card Issuer Networks as Payment Method Names

Remotes support for calling PaymentRequest with card issuer networks (e.g., "visa", "amex", "mastercard") in the supportedMethods field.

Deprecate Web MIDI Use on Insecure Origins

Web MIDI use is classified into two groups: non-privilege use, and privilege use with sysex permission. Until Chrome 77, only the latter use prompts users for permission. To reduce security concerns, permissions will always be requested regardless of sysex use. This means that using Web MIDI on insecure origins will no longer be allowed.

Deprecate WebVR 1.1 API

This API is now deprecated in Chrome, being replaced by the WebXR Device API, which is expected to ship in Chrome 78. The WebVR Origin Trial ended on July 24, 2018.

WebVR was never enabled by default in Chrome, and was never ratified as a web standard. The WebXR Device API is the replacement API for WebVR. Removing WebVR from Chrome allows us to focus on the future of WebXR and remove the maintenance burden of WebVR, as well as reaffirm that Chrome is committed to WebXR as the future for building immersive web-based experiences. Removal is expected in Chrome 79.

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Find more information about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 76 is beta as of June 13, 2019.

Dark mode

Many operating systems now support inverted color schemes with a system setting referred to as ‘dark theme' or ‘dark mode', depending on the system.


The prefers-color-scheme media query allows a website or web app to adopt the preferred display mode of the user. Use the query in your CSS code like so:

@media (prefers-color-scheme: dark) {
  body {
    color: white;
    background-color: black;
  }
}

What is left out of this is the explanation? For that, read the article titled Hello Darkness, My Old Friend.

Payments API

Over the last few versions of Chrome we've rolled out a number of improvements to the payments APIs. These APIs provide a way to interact with proprietary payment systems without needing to build your own user interactions. Changes in Chrome 75 included replacing hasEnrolledInstrument() with canMakePayment() and removal of languageCode from the billing address. With the detailsPromise option Chrome 75 gives PaymentRequest.show() a means of performing a quick server call before showing payment details to the buyer.

Chrome 76 brings three changes to the payment realm. Now implemented are features that allow a merchant website or web app to respond when a user changes payment instruments. Additionally, the PaymentRequestEvent has a new method called changePaymentMethod() and the PaymentRequest object now supports an event handler called paymentmethodchange. You can use both to notify a merchant when the user changes payment instruments. The former returns a promise that resolves with a new PaymentRequest instance.

Additionally, Chrome now makes it easier to use the payments APIs for self-signed certificates on the local development environment. To do this, launch Chrome from a command line with the —ignore-certificate-errors flag.

For detailed information about these features, read Web Payments Updates.

Improvements for Progressive Web Apps

Install Progressive Web Apps on the desktop with ease

On desktop, there is typically no indication to a user that a Progressive Web App is installable, and if it is, the install flow is hidden within the three dot menu.

In Chrome 76, we're making it easier for users to install Progressive Web Apps on the desktop by adding an install button to the omnibox.


If a site meets the Progressive Web App installability criteria, Chrome shows an install icon in the omnibox. There is no extra work required from developers. Clicking the button prompts the user to install the PWA.

Control the Add to Home Screen mini-infobar

In Chrome 76, we're giving you control over the add to home screen mini-infobar.




Chrome shows the mini-infobar the first time a user visits a site that meets the Progressive Web App installability criteria. Developers want to prevent the mini-infobar from appearing, and provide their own install promotion instead.

To do this, listen for the beforeinstallprompt event, and call preventDefault()
on it. Then, update your UI to notify the user by adding an install button or other element. Depending on your app, there are several different patterns you can use to promote installation of your PWA.

The add to home screen mini-infobar is still a temporary measure. We are experimenting with new UI patterns for giving Progressive Web App users the ability to install, and do this in a way that reduces clutter in the browsing experience.

Updating WebAPKs more frequently

When a PWA is installed on Android, Chrome automatically requests and installs a WebAPK. Chrome periodically checks to see if the manifest has changed, and if a new WebAPK is required. Starting in Chrome 76, Chrome will check the manifest more frequently: checking every day, instead of every three days. If any of the key properties have changed, Chrome will request and install a new WebAPK.

Other features in this release

Animation.updatePlaybackRate

Adds Animation.updatePlaybackRate(), which lets you seamlessly transition the playback rate of an animation such that there is no visible jump in the animation. Current time is preserved at the instance the new playback rate takes effect.

Async clipboard: read and write images

Implements programmatic copying and pasting of images for the Async Clipboard API. This change also updates navigator.clipboard.read() and navigator.clipboard.write() to comply with the specification. Programmatic copying and pasting of images is Chromium's top starred bug.

Escape key is not a user activation

The escape key is no longer treated as a user activation. Browsers prevent calls to abusable APIs (like popup, fullscreen, vibrate, etc.) unless the user activates the page through direct interactions. Not all interactions trigger user activation. For example, clicking on a link or typing in a textbox does, but swiping fingers on a screen or hovering with the mouse cursor does not. Since users never intend to interact with the page through the escape key, it should not trigger user activation.

Fetch Metadata

Introduces a new HTTP request header that sends additional metadata about a request's provenance (is it cross-site, is it triggered from <img>, etc.) to the server to allow it to make security decisions which might mitigate some kinds of attacks based on timing the server's response (XSS leaks and others).

For example, it is unlikely that a bank's "Transfer all money" endpoint would be referenced from an <img> tag, and likewise unlikely that evil.com is going to be making any legitimate requests whatsoever. Ideally, the server could reject these requests a priori rather than deliver them to the application backend.

form.requestSubmit()

Adds the form.requestSubmit() function, which requests form submission. It includes interactive constraint validation, dispatches a submit event, and takes a reference to the submitter button.

ImageCapture support for focusDistance constraint

The Image Capture API provides a means to set the focusMode to manual which is not useful if you cannot set the focus distance. This change provides an interface for getting focus range values and setting focus distance value.

Implement Animation.pending

Adds the pending attribute to the Web Animations API. A pending animation is one that is waiting on an asynchronous operation that affects the play state. Adding support for this attribute does not affect the rendering or timing of animations, but simply exposes the signal.

IndexedDB transaction explicit commit API call

Adds a commit() function to IDBTransaction objects, which explicitly marks a transaction as not accepting further requests. Currently, IndexedDB only commits a transaction after all associated requests have had their completion event handlers executed, and no new requests have been queued by the event handlers. Developers can use the explicit commit() function to shave a few event loop cycles off of the latency of their transactions.

The primary benefit of explicit commit is that it increases the throughput of read and write requests made on an object store. This is a clear performance benefit in terms of the rate at which operations can be processed. Additionally, the increase in speed is advantageous because it adds stability to IndexedDB by reducing the probability that a disruptive event occurs within the lifetime of a transaction.

JavaScript

DateTimeFormat dateStyle and timeStyle
Adds dateStyle and timeStyle options to functions on Intl.DateTimeFormat, specifically formatToParts() and resolveOptions(). These options provide a compact way to request the appropriate, locale-specific date and time of given length styles.

Locale sensitive BigInt.prototype.toLocaleString and allow Intl.NumberFormat format/formatToParts to take BigInt.
Changes BigInt.prototype.toLocaleString() to locale-sensitive number formatting and changes Intl.NumberFormat.prototype.format() and formatToParts() to accept BigInt as input.

Media capabilities in workers

Enables the Media Capabilities API in all types of workers to help website and web apps pick the best media to stream from a worker. The information can then be used to create the MediaStream from a worker.

Promise.allSettled

Adds Promise.allSettled(), which returns a promise that is fulfilled with an array of promise state snapshots, but only after all the original promises have settled, in other words after it has either resolved or rejected.

Simpler reading methods for Blob interface

Adds three new methods to the Blob interface to perform read operations: text(), arrayBuffer(), and stream().

WebRTC

RTCSctpTransport
Exposes information about the SCTP transport that is used to carry WebRTC data channels such as max-message-size and max channels.

RTCRtpSender.setStreams
Allows changing the association between the track associated with an RTCRtpSender and streams. Stream association causes tracks in the same stream to be synchronized. This is useful, for example, if during a call a user switches from a front-facing camera to a back-facing camera and the application uses RTCRtpSender.replaceTrack(). On the receiving end the new track must be associated with the existing stream and synchronized with its auto track.

RTCRtpTransceiver.setCodecPreferences()
Adds the setCodecPreferences() method, which overrides the default codec preferences used by the user agent. This allows applications to disable the negotiation of specific codecs. It also allows an application to cause a remote peer to prefer the codec that appears first in the list for sending.

white-space: break-spaces

The white-space:break-spaces value allows authors to specify that any sequence of preserved white space that would otherwise overflow a line and hang (as per the CSS Text Module specification's Trimming and Positioning rules) must be broken.

Removals

Remove feature policy: lazyload

The lazyload feature policy was intended to allow developers to selectively control the lazyload attribute on the <iframe> and <img> tags to provide more control over loading delay for embedded contents and images on a per origin basis.

The policy is removed in favor of a newer feature policy for loading, namely loading-frame-default-eager which is more aligned with how the loading attribute will be used. The removal applies to both the Feature-Policy header and the <iframe> allow attribute.

Remove outputs from MediaStreamAudioDestinationNode

According to the specification, the MediaStreamAudioDestinationNode in the Web Audio API should have no outputs. Chrome's implementation has a single output which has been removed.

Remove insecure usage of DeviceMotionEvent

Chromium has been showing deprecation warnings since 2015 whenever the API is used in a non-secure browsing context. Chrome now restricts the API to secure browsing contexts. This change brings Chromium's implementation in line with the privacy and security recommendations in the specification, and is aligned with the effort to deprecate powerful features on insecure origins.

Remove insecure usage of DeviceOrientationEvent

The web celebrated its 30th anniversary this year, and what an amazing three decades they have been. We’ve seen the platform go from powering simple hypertext documents, to one that enables rich, immersive, and dynamic experiences that are at the forefront of design.

Looking forward, the world’s needs continue to evolve, and that motivates us to continue our participation with the global web community to adapt and improve the platform to meet the needs of the future. Our efforts are focused on making the web faster and more powerful, while keeping our users’ trust and safety front and center.

Vision for an Instant Web

Speed matters on the web. We’ve found that users are highly sensitive to loading speed and this can have a direct impact on the business.

So we’ve been working hard to make the browser faster and lighter so developers can do more with their experience. By focusing on startup bottlenecks, we were able to improve the loading speed on Chrome’s startup by 50% on low-end devices; and 10% across devices. We also improved scrolling performance by 18% and through V8, JavaScript memory usage reduced by up to 20% for real world apps.

Apart from making the browser more efficient, we’ve also been adding more features to the platform to take the burden away from developers. And we’d like to share a few of these here:

• To deliver a great image loading experience without needing developers to build their own JavaScript solutions, we’re bringing lazy loading for images and iframes directly into the browser. All developers have to do is add a simple HTML attribute and Chrome will take care of the rest.
• For fast sites, Chrome’s eager clearing of the page, when a user wants to navigate to another page, can be detrimental to the experience. To avoid this flash of a white “loading page”, we’re rolling out a new experiment called Paint Holding to improve navigation on the web. You can see it in action for the Awwwards website here: 

Speaking of navigations, Portals, is a new technology that we believe will fundamentally change the way users traverse the web. Portals are similar to iframes and allow content to be embedded directly in a page, but unlike standard iframes, they can be ‘activated’ to become the top-level page, enabling instant transitions across the web. Advanced experiences can even hold pieces of the original page’s UI privately and securely, so that you can provide seamless overlays that still hold our ideals of the origin model.

At I/O, we shared our vision of how developers would be able to use Portals and associated APIs to support pre-fetching, enhanced transitions and the exchange of contextual information between sites. And now that Portals API is available behind a flag in Chrome Canary, we’re excited to see what developers will build with this new primitive.
Another technology that we’re particularly excited about is Web Packaging, a bold new contract between web developers and web servers. With Web Packaging, the model for loading pages changes from the browser requesting the page from the origin’s server to it being able to load from anywhere — even potentially other peer devices.


This gives the browser the flexibility to preload content and load pages instantly while doing so in a privacy preserving way. Signed Exchanges, the first phase of this vision is now available in Chrome for developers to use.

These are some of the things that we’re doing to make the web more instant, but its success is predicated on developers making their experiences fast and maintaining that performance. So we’ve added a bunch of tools to help.

In 2017, we launched the Chrome UX report to give developers a better sense of how their users truly experience their webpages by providing them real world metrics. The report is now includes a data set of nearly 6 million origins and is powering more of our tools, including the latest Speed Report in the Google Search Console. The report is currently in beta and you can register here to join the program and share your feedback.

To give developers an even wider array of real world metrics, the Firebase team have broadened their Performance Monitoring tool to also cover web apps.

And to stay on the rails for performance, we’ve seen many top sites implement ‘performance budgets’ within their build environments, and that is why we’ve built performance budgets directly into Lighthouse, so that you can get alerted to performance regressions before they hit your production site.

Creating a more powerful web

Our vision is to allow you to do absolutely anything that you want your users to do, on the web. So we’ve been working hard over the last year to close the capability gap by focusing on the features that get your experiences closer to your users.

Since the beginning of Chrome we have worked to provide a solid foundation for modern web applications. Those capabilities have enabled new experiences on the web that were never thought possible. WASM is enabling new classes of games and productivity apps like Sketchup and AutoCAD, WebRTC enables new ways to communicate, and service workers allow developers to create reliably fast web experiences regardless of network conditions.
However, there are some capabilities, like file system access, idle detection, and more that are available to native but aren’t available on the web. These missing capabilities mean some types of apps can't be delivered on the web, or are less useful. To cope, some developers build native apps, or use wrappers like Cordova or Electron to access the underlying capabilities of the device.
We strongly believe that every developer should have access to the capabilities they need to make a great web experience, and we want to support them as they do.

Closing the gap

We want to close the capability gap between the web and native and make it easy for developers to build great experiences on the open web. Meanwhile we need to preserve everything that is great about the web. We will rapidly bring new, powerful, portable, and standardized capabilities that unlock key verticals on both mobile and desktop. Giving developers these new tools will empower the open web as a place where any experience can be created, and make the web a first class platform for developing apps that run on any browser, with any operating system, and on any device.
We plan to design and develop these new capabilities in an open and transparent way, using the existing open web platform standards processes while getting early feedback from developers and other browser vendors as we iterate on the design, to ensure an interoperable design.
Per our practice of open design and public iteration, look for many proposals for new designs to surface at the W3C's Web Incubator Community Group.

What are the initial capabilities?

We’ve identified and prioritized an initial set of capabilities we feel are critical to closing the gap between web and native, and have already started work on a handful of them. You can see the list by searching the Chromium bug database for bugs that are tagged with proj-fugu.
Personally I’m really excited about the writable file API that make it possible to create web based editors, and event alarms that help perform arbitrary work at some point in the future. But there are plenty more: Web Share Target, Async cookies, Wake Lock, WebHID, user idle detection, just to name a few.

Early feedback is critical

We developed a process to make it possible to design and develop new web platform capabilities that meet the needs of developers quickly, in the open, and most importantly, work within the existing standards process. It’s no different than how we develop every other web platform feature, but it puts an emphasis on developer feedback.
Developer feedback is critical to help us ensure we’re shipping the right features, but it’s easier to change course early in the process. That’s why we’re starting to ask for feedback earlier. When actionable technical and use-case feedback comes in early, it’s easier to course correct or even stop development, without having shipped poorly thought out or badly implemented features. Features being developed at WICG are not set in stone, and your input can make a big difference in how they evolve.
It’s worth noting that many ideas never make it past the explainer or origin trial stage. The goal of the process is to ship the right feature. That means we need to learn and iterate quickly. Not shipping a feature because it doesn’t solve the developer need is OK.

Getting everyone involved

The first API we’re looking for feedback on is the writable files API. We want to hear about your use cases and how you expect the security model to work. And keep an eye on our new capabilities page on developers.google.com/web to see the list of capabilities that we’re working on, and how you can participate.
The apps you want to build on the open web should only ever be limited by your imagination, never by missing capabilities. As we look to the future, the gap between web and native will get smaller as browser vendors add new capabilities to the web.
Here’s to a more capable open web.

Posted by Pete LePage, dreamer.

2008 – 2014: Web applications, HTML5, and the start of the mobile era