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 80 is beta as of December 19, 2019.

Content Indexing

A progressive web app can store content such as images, videos, articles, and more for offline access using the Cache Storage API or IndexedDB. But how do users discover this content? How do they know that they can consume or use it, even when a network is unavailable?

The Content Indexing API provides metadata about content that your web app has already cached. More specifically, it stores URLs for HTML documents that display stored media. The new API lets you add, list, and remove resources. Browsers can use the information in the index to display a list of offline-capable content. Here's what it looks like in Chrome 80.

The Content Indexing API is in an origin trial from Chrome 80 to Chrome 82. For details about the API, see Experimenting with the Content Indexing API. See the Origin Trials section for information on signing up and for a list of other origin trials starting in this release.

ECMAScript Modules in Web Workers

Web Workers have been available in most browsers for more than ten years. Consequently, the method for importing modules into a worker, importScripts(), has not been state of the art for some time. It blocks execution of the worker while it fetches and evaluates the imported script. It also executes scripts in the global scope, which can lead to name collisions and its associated problems.

Enter Module Workers. The Worker constructor now supports a type option with the value "module", which changes script loading and execution to match <script type="module">.

const worker = new Worker('worker.js', {
  type: 'module'
});

Module Workers support standard JavaScript imports and dynamic import for lazy-loading without blocking worker execution. For background and details see ES Modules in Web Workers.

Origin Trials

This version of Chrome introduces the origin trials described 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 described below, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

New Properties for the Contact Picker

This version of Chrome is shipping the Contact Picker API, ending an origin trial that started in Chrome 77. (More on that below.) At the same time it's starting a new origin trial that adds features to that API. Before requesting that a user select contacts, an app must specify which data it wants back. Currently, only the contact's name, email address, and telephone number are available. The new origin trial adds to this the user's mailing address ('address') and image ('icon').

Other features in this release

Autoupgrade Mixed Content

Chrome is now auto-upgrading HTTP content in HTTPS sites by rewriting URLs to HTTPS without falling back to HTTP when secure content is not available. In this version of Chrome only audio and video content are so treated.

Compression Streams

JavaScript can now perform gzip and deflate compression using streams. This covers two interfaces: CompressionStream and DecompressionStream.

It is possible to compress stream data without this feature, but common libraries like zlib are complex to use. Compression streams make it easy for developers to compress data, and avoid the need to bundle a compressor with an application.

Contact Picker API

The Contact Picker API is a new, on-demand picker for Android Chrome 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. Additionally, a new origin trial adds members to the properties that may be returned by ContactsManager.getProperties(). See the Origin Trials section, above, for details.

Cookie updates

The SameSite attribute was introduced in Chrome 51 and Firefox 60 to allow sites to declare whether cookies should be restricted to a same-site (sometimes called first-party) context, mitigating the risk of cross-site request forgeries (CSRF).

In Chrome 80, the backward compatible behaviors described below are removed. For more on these features, read SameSite cookies explained.

Disallow defaulting of SameSite attribute to 'None'

The SameSite attribute now defaults to Lax meaning your cookies are only available to other sites from top-level navigations. As originally implemented in Chrome, the SameSite attribute defaults to None, which was essentially the Web's status quo. Cookies have valid cross-site use cases, but if a site owner did not previously want to allow cross-site cookie use there was no way to declare such an intent or enforce it.

Value 'None' no longer allowed on insecure contexts

Chrome now requires that when the SameSite attribute is set to None, that the Secure attribute must also be present. The Secure attribute requires that the attached cookie can only be transmitted over a secure protocol such as HTTPS.

CSS Improvements

line-break: anywhere

The line-break: anywhere declaration allows soft wrapping around every typographic character unit, including around any punctuation character or preserved spaces, or in the middles of words. It disregards any prohibition against line breaks, even those introduced by characters with the GL, WJ, or ZWJ character class (see UAX 14) or mandated by the word-break property.

overflow-wrap: anywhere

The overflow-wrap: anywhere declaration allows an otherwise unbreakable sequence of characters to be broken at an arbitrary point if there are no otherwise-acceptable break points in a line. Additionally, soft wrap opportunities introduced by anywhere are considered when calculating min-content intrinsic sizes.

Decoding Encrypted Media

The capabilities of MediaCapabilities.decodingInfo() are now available for encrypted media. The decodingInfo() method (available in multiple browsers) allows websites to get more information about the decoding abilities of the client. This enables more informed selection of media streams for the user, enabling scenarios such as smoothly and power-efficiently decoding a video for the available bandwidth and screen size.

Delegating Shipping Address and Contact Information in Web Payments

The Payment Handler API now lets the browser delegate handling of the shipping address and payer's contact information to Payment Handlers. Delegating collection of the shipping address and contact information to payment handlers can lead to better user experiences because the payment app may have more accurate information than the browser. It can also reduce the checkout steps by one since the browser can show the payment handler window directly rather than showing the payment sheet UI first to collect shipping address and/or payer's contact information. To keep updated on other technical updates around Payment Request API / Payment Handler API on Chrome, subscribe to paymentrequest@chromium.org.

Fetch Metadata Destination header

Chrome now supports the Sec-Fetch-Dest HTTP request header which exposes a request's destination to a server, providing it with information on which to base security decisions. The spec provides a list of its possible values.

HTMLVideoElement.getVideoPlaybackQuality()

This method retrieves information about video playback performance. Such information may be used to alter bitrate, framerate, or resolution, either upward or downward, to provide a better user experience.

JavaScript optional chaining

Provides safe access to descendent object members with parents that may or may not be null. This applies to objects as well as functions. For example, consider an object reference with three levels such as a.b.c. Testing for the existence of c would previously require nesting said test inside a test for b. This change allows you to test for c directly without an error being thrown when b is null.

Nullish coalescing

Adds support for the 'nullish' operator to JS.

Offscreen Canvases Now Support getTransform()

The OffscreenCanvasRenderingContext2D now supports getTransform(). Like its CanvasRenderingContext2D counterpart, this method lets you retrieve the transformation matrix that is currently applied to the context.

Support for SVG in favicons

Chrome now supports using SVG images as favicons. Scalable formats for favicons reduce the resources for a website or app. For example, a website could have one (or more) hand-tuned icons for small sizes and use a scalable icon as a catch-all.

Text URL Fragments

Users or authors can now link to a specific portion of a page using a text fragment provided in a URL. When the page is loaded, the browser highlights the text and scrolls the fragment into view. For example, the URL below loads a wiki page for 'Cat' and scrolls to the content listed in the text parameter.

https://en.example.org/wiki/Cat#:~:text=On islands, birds can contribute as much as 60% of a cat's diet

Deprecations, and Removals

This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals. The descriptions here are just a summary of what's being deprecated and removed. You can find longer descriptions of all these items and replacements and remediations in Deprecations and removals in Chrome 80.

Disallow Popups During Page Unload

Pages may no longer use the window.open() method to open a new page during unload. The popup blocker already prohibits this, but now it is prohibited whether or not the popup blocker is enabled. For now, enterprises can use the AllowPopupsDuringPageUnload policy flag to allow popups during unload. Chrome expects to remove this flag in version 82.

Disallow Synchronous XMLHttpRequest() in Page Dismissal

Chrome now disallows synchronous calls to XMLHttpRequest() during page dismissal when the page is being navigated away from or is closed by the user. This applies to beforeunload, unload, pagehide, and visibilitychange.

To ensure that data is sent to the server when a page unloads, Chrome recommends sendBeacon() or Fetch keep-alive. For now, enterprise users can use the AllowSyncXHRInPageDismissal policy flag and developers can use the origin trial flag allow-sync-xhr-in-page-dismissal to allow synchronous XMLHttpRequest() requests during page unload. This is a temporary opt-out measure. Chrome expects to remove this flag in version 82.

For details about this and the alternatives, see Improving page dismissal in synchronous XMLHttpRequest().

FTP Support Deprecated

Chrome has been removing capabilities from its FTP support since version 72. The reason for this is that usage of FTP in the browser is sufficiently low that it is no longer viable to invest in improving the existing FTP client. In addition, more capable FTP clients are available on all affected platforms. In Chrome 80, the client's capabilities are restricted to either displaying a directory listing or downloading a resource over unencrypted connections. For more information, see Deprecations and removals in Chrome 80.

Non-origin-clean ImageBitmap serialization and transferring removed

Starting in Chrome 80, errors are raised when a script tries to serialize or transfer a non-origin-clean ImageBitmap object. A non-origin-clean ImageBitmap is one that contains data from cross-origin images that are not verified by CORS logic.

Protocol handling now requires a secure context

The methods registerProtocolHandler() and unregisterProtocolHandler() now require a secure context. These methods are capable of reconfiguring client states such that they would allow transmission of potentially sensitive data over a network.

Remove -webkit-appearance:button for arbitrary elements

Changes -webkit-appearance:button to work only with <button> and <input> buttons. If button is specified for an unsupported element, the element has the default appearance. All other -webkit-appearance keywords already have this restriction.

Web Components v0 removed

Web Components v0 are now removed from Chrome. The Web Components v1 APIs are a web platform standard that has shipped in Chrome, Safari, Firefox, and (soon) Edge. For guidance on upgrading, read Web Components update: more time to upgrade to v1 APIs. This deprecation covers the items listed below.

• Custom Elements v0
• HTML Imports v0
• Shadow DOM v0

If you’re a standards-curious web developer, you may have wondered how features get added to browsers, or even how the Chrome team decides what they will work on. You probably also have, at least at some point, thought to yourself “I have this urgent problem but I’ll have to work around it for the foreseeable future, because browsers are just too slow to bring in changes”. You may have even added some expletives when no one was around.

If that description sounds accurate, this is the post for you! This post will describe the Blink process, how browser engineers (both inside and outside of Google) use it in order to ship features in Chromium, what considerations are taken when deciding to ship a new feature, as well as some considerations that impact what features get worked on, and how you can play a role in all of this!

Project goals

The Chromium project is the open source project on which Chrome is built, and on which other browsers are also based: Samsung Internet, Opera, Brave, Vivaldi, and last (to join the project) but not least, Microsoft Edge. The project enables all those different browsers to share a single implementation of the web platform, and at the same time, keep their unique characteristics and focus.

Blink is the rendering engine used by Chromium. It is the part of the project that descends from WebKit (the rendering engine Safari uses), and which is mostly (but not exclusively) responsible for the Chromium’s Web Platform implementation. The goal of Chromium and Blink inside it is to continuously improve the web platform as a whole.

How does Blink improve the web platform?

• By improving its predictability through testing and infrastructure, making sure developers have to spend less of their time tackling browser-specific issues and more of their time… well, developing.
• By removing user hostile features, features that increase the platform’s complexity or make its implementations less secure.
• By adding platform capabilities that enable web developers to innovate and create web experiences that meet and exceed their users’ expectations and needs.

If we want the web to thrive in the long term, we need to make sure that our users consider it safe and pleasant to use, and that it supports all the capabilities developers need in order to easily make their users (and businesses) are happy.

Any improvement to the platform needs to take backwards compatibility and cross-browser interoperability into account. There’s a lot of web content out there that will never change. The risk of breaking some of it needs to be weighed against the user benefits of shipping that new feature or removing that risky old one. Similarly, in cases where Blink is the first engine to ship a feature or to remove it, we should make sure other browser vendors can follow. We do that by ensuring shipped features designs are widely reviewed, and have specifications and tests to guide future implementers.

The Chromium project is rather large, and is being worked on by many different entities. Therefore it needs to control which features get shipped, while being even-handed in that decision process. We achieve that through a simple process that guides contributors as they evolve the platform to ensure maximum long-term compatibility and interoperability.

What features get worked on?

Chromium is an open source project that’s being worked on by over 2000 engineers from ~55 different organizations. Of course, Google is responsible for the bulk of Chromium - 92% of commits to the project (data) come from Google,  although about 20% of contributors are not Google-affiliated.

With a project of this magnitude, each of the involved companies and contributors are naturally pushing their own slightly different agenda and priorities. Even within Google’s Chrome team there are multiple ways to prioritize which problems are most urgent to tackle and solve. One area that is consistent, is that we work with the ecosystem and developer partners to understand and address their needs. We do that by creating compatibility dashboards, collaborating with frameworks, and observing development patterns in the wild.

The MDN survey is a great example of how the ecosystem can help shape the priorities that a browser vendor has. We’re still in the process of analyzing the results, but it was clear that compatibility is a top priority for developers and we will commit to keep improving on it. We also plan to create more ways to gather structured data on developer needs and hardships.

As you can imagine, with all these priorities from different contributors, it's important for us to be clear about how a feature goes from inception to shipping.

So, what are the typical phases of creating a new web platform feature and shipping it in Chromium?

The very first step before getting started would be to figure out what we need to be working on and which user or developer problems are the most burning ones. That is typically done by talking to partners, looking at current development patterns and consulting with web developers and framework authors to get a better understanding of what the platform can do better to address their and their users’ needs.

Once we know which problem we want to tackle, we can start incubating it!

---

What does “incubating” mean?

Over the years, we found that the best way to design and prototype a new platform feature is through incubation - getting a strong grasp of the use cases a feature is trying to solve as a first step, and then rapidly iterating over the design in a public forum that includes browser engineers and domain experts. Only once we are certain that a feature solves important use-cases and have high confidence that it solves it the right way, we bring that feature to an official track at a Standard Development Organization, such as a W3C Working Group, the WHATWG, or TC39.

Not all incubations turn up to be standards though. Some incubations fail and some prototypes never make it out to the hands of users. That is perfectly fine and by design. The web platform cannot afford features that don’t solve real user or developer problems to creep in, and we want to make sure those features never make it to be a permanent part of the platform. 

---

Step 1 - Initial research

At this phase, we establish a better understanding of the problem space, by gathering up the specific use-cases we want our future solution to tackle and the constraints under which the solution must operate.

At the end of that phase, engineers are expected to publish an explainer that outlines the above, and maybe have a very rough sketch of what a solution may look like. The explainer is published in a relevant public forum (e.g. the WICG discourse) in order to solicit feedback from the web community at large. Such feedback can include missed-out use-cases, further constraints that can impact the design, or simply statements of support for solving the problem.

It’s important at this stage to focus on the problem, and not over-index on any one possible solution - and this is one of the places we haven’t always been perfect.

Step 2 - Design & Prototype

Now that we have better grip of the problems we’re trying to solve and the constraints in which we operate, we can start designing the feature and what it may look like. Ideally, the design team would include browser engineers from interested vendors as well as problem space experts from the web developer or framework developer community.

Once we have an initial rough design, it might be a good idea to start building and committing  code (behind a flag and turned off by default) in order to better understand the solution’s feasibility and complexity.

That’s when engineers should send out an “Intent to Prototype” email to blink-dev (previously, “Intent to Implement”), in order to notify the relevant code owners that work is underway in that area. Note that such an intent doesn’t mean that the feature is shipping soon, or that it will ship at all for that matter. It just means that this is a problem space that’s being explored, and code is landing to that end. 

That’s also a good point in time to make sure the feature will get a wider review, by filing for a TAG review.

Step 3 - Experiment & iterate

Once code starts to land behind a flag, it’s a good time for interested web developers to start playing around with the solution by turning on the feature flag and testing it out.

Feedback on the initial implementation is critical in order to make sure the eventual design would work well for developers and users alike.

For some features, such experimentation is enough for developers to get a good handle on what’s the solution looks like, and how well it addresses the problem.

In other cases, it’s critical to gather data from the field regarding the solution, to see how well it works in broader deployment to fulfill user’s needs, or get a better understanding of its performance characteristics at scale.

Step 3.5 - Origin Trial

In those cases, a browser engineer can request an Origin Trial (by sending out an Intent to Experiment email), which enables interested developers to test the feature out in broader deployment to users who have not turned on the feature flag. Once an Origin Trial is in place, developers can register for the trial, and enable the feature (in production) for their domains. That enables them to gather data on the user impact of the feature, and report it back to the design team, confirming or refuting their assumptions regarding the solution’s viability.

Note that an Origin Trial is a temporary experiment, and there’s a good chance that the feature will significantly change before it will be enabled by default, or even that the effort will be dropped altogether. Developers interested in participating should take that into account, and not rely on the feature being available to their users beyond the scope of the trial.

Step 4 - ship it!

Once the previous steps were completed with success and the team believes the feature is ready to be turned on by default, that’s when they can submit an Intent to Ship.

That’s a part of the process that’s a bit more strict.

In order to ship a feature by default, engineers need approval for the feature to ship from 3 API owners.

---

What’s an “API owner”?

API owners are a set of trusted Chromium engineers, who are responsible for enforcing the Blink process guiding principles. Each feature we’re trying to ship has some user and developer benefits, otherwise we probably wouldn’t be working on it. Shipping new features can introduce interoperability risks, if other browsers don’t follow us. The API owners are tasked with applying our compatibility and interoperability principles and help evaluate each shipping feature with regards to its risk/benefit tradeoff. They then provide their approval on “Intent to Ship” threads for new shipping features, if they think the benefits outweigh the risks. Those approvals are provided in the form of “LGTM” (“Looks Good To Me”) replies on intent threads.

Note that LGTMs are not required for Intent to Prototype. For an Intent to Experiment, approval from a single API owner is sufficient, as the risk they pose is fairly contained.

---

As part of the “Intent to Ship” request, chromium engineers need to provide clear signals regarding the risk and benefit tradeoff of the feature.

• The feature needs to have a solid specification and a comprehensive cross-browser test suite in order to minimize interoperability risk.
• Signals from other browser vendors as well as from wide review forums (such as the TAG) are taken into account, alongside signals from the web developer community and partners who are planning to use the feature.
• If the feature went through an Origin Trial, a report outlining the results is also important to better understand the benefits.

Note that the fact that an “intent to ship” is sent indicates the team’s estimate of the feature being ready to ship, but it does not necessarily mean that the feature will ship shortly, or at all.

Some features take a long time to go through the intent process, in order to prove that the risk they pose is low enough to justify shipping. Others get held up addressing feedback from other vendors or from wide-review forums. 

In other (rare) cases, features can be rejected by the API owners, and their proponents then need to look for alternative ways to resolve the problem, which won’t hit the same concerns that got their initial intent rejected.

Removing features

Finally, while adding new feature certainly grabs most people’s attention, an equally important part of the intent process is to deprecate and remove legacy web platform features. In those cases, the main risk is breaking existing content, and the benefits are typically around improving user’s security, privacy and performance. The project’s willingness to take some compatibility risk and remove features is critical to our risk/benefit calculus also when launching features first - if we got it wrong and late feedback causes us to change course, we typically can figure out a path to deprecate those features to get us back on track to interoperability.

Summary

The Chromium’s project goal is to make sure the web platform remains a healthy and successful platform.

For that, we believe the platform needs to make significant progress in the face of shifting developer and user expectations, as well as adapt to the changing market forces and constraints. At the same time, we need that progress to be done in a responsible manner both inside the Chromium project and when it comes to our collaboration with the wider ecosystem.

The Blink process’ role is to keep the balance between those different requirements, and to help ensure the web is a thriving platform for generations to come.

Posted by Yoav Weiss, Wrangler of processes and Advocate of developers.

• SMS Receiver, allowing web apps to retrieve two-factor SMS messages.
• Contact Picker, which will allow people to share web content to their contact lists, bringing social media and communication capabilities to web apps.
• Native File System API, enables web apps to read or save changes directly to files and folders on the user's device. This allows developers to build powerful web apps that interact with files on the user's local device, like IDEs, photo and video editors, text editors, and more.