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 96 is beta as of October 21, 2021.
Next year, Chrome will release version 100. This will add a digit to the version number reported in Chrome's user agent string. To help site owners test for the new string, Chrome 96 introduces a runtime flag that causes Chrome to return '100' in its user agent string. This new flag called chrome://flags/#force-major-version-to-100 is available from Chrome 96 onward.
chrome://flags/#force-major-version-to-100
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 Chrome Origin Trials dashboard. To learn more about origin trials in Chrome, visit the Origin Trials Guide for Web Developers. Microsoft Edge runs its own origin trials separate from Chrome. To learn more, see the Microsoft Edge Origin Trials Developer Console.
Applications that capture other windows or tabs currently have no way to control whether the calling item or the captured item gets focus. (Think of a presentation feature in a video conference app.) Chrome 96 makes this possible with a subclass of MediaStreamTrack called FocusableMediaStreamTrack, which supports a new focus() method. Consider the following code:
MediaStreamTrack
FocusableMediaStreamTrack
focus()
stream = await navigator.mediaDevices.getDisplayMedia(); let [track] = stream.getVideoTracks();
Where formerly, getVideoTracks() would return an array of MediaStreamTrack objects, it now returns FocusableMediaStreamTrack objects. (Note that this is expected to change to BrowserCaptureMediaStreamTrack in Chrome 97. At the time of this writing, Canary already does this.)
getVideoTracks()
BrowserCaptureMediaStreamTrack
To determine which display media gets focus, the next line of this code would call track.focus() with either "focus-captured-surface" to focus the newly captured window or tab, or with "no-focus-change" to keep the focus with the calling window. On Chrome 96 or later, you can step through our demo code to see this in action.
track.focus()
"focus-captured-surface"
"no-focus-change"
Priority Hints introduces a developer-set "importance" attribute to influence the computed priority of a resource. Supported importance values are "auto", "low", and "high". Priority Hints indicate a resource's relative importance to the browser, allowing more control over the order resources are loaded. Many factors influence a resource's priority in browsers including type, visibility, and preload status of a resource.
"importance"
"auto"
"low"
"high"
Requests with simple range headers can now be sent without a preflight request. CORS requests can use the Range header in limited ways (only one valid range) without triggering a preflight request.
The back-forward cache stores pages to allow for instant navigations to previously-visited pages after cross-site navigations.
Cross-Origin-Embedder-Policy has a new credentialless option that causes cross-origin no-cors requests to omit credentials (cookies, client certificates, etc.). Similarly to COEP:require-corp, it can enable cross-origin isolation.
Cross-Origin-Embedder-Policy
credentialless
no-cors
COEP:require-corp
Sites that want to continue using SharedArrayBuffer must opt-in to cross-origin isolation. Doing so using COEP: require-corp is difficult to deploy at scale and requires all subresources to explicitly opt-in. This is fine for some sites, but creates dependency problems for sites that gather content from users (Google Earth, social media generally, forums, etc).
COEP: require-corp
The new autofill pseudo class enables styling autofilled form elements. This is a standardization of the :-webkit-autofill pseudo class which is already supported in WebKit. Firefox supports the standard version.
autofill
:-webkit-autofill
Some properties like writing-mode, direction, and backgrounds are propagated from body to the viewport. To avoid infinite loops for CSS Container Queries, the spec and implementation were changed to not propagate those properties when containment is applied to HTML or BODY.
The font-synthesis CSS property controls whether user agents are allowed to synthesize oblique, bold, and small-caps font faces when a font family lacks faces.
font-synthesis
The MediaKeySession.closed property now uses an enum to indicate the reason the MediaKeySession object closed. The closed property returns a Promise that resolves when the session closes. Where previously, the Promise simply resolved, it now resolves with a string indicating the reason for closing. The returned string will be one of "internal-error", "closed-by-application", "release-acknowledged", "hardware-context-reset", or "resource-evicted".
MediaKeySession.closed
MediaKeySession
"internal-error"
"closed-by-application"
"release-acknowledged"
"hardware-context-reset"
"resource-evicted"
Chrome will always connect to a website via HTTPS when an HTTPS record is available from the domain name service (DNS).
The PerformanceEventTiming interface now includes an attribute called interactiveID. This is a browser-generated ID that enables linking multiple PerformanceEventTiming entries when they correspond to the same user interaction. Developers can currently use the Event Timing API to gather performance data about events they care about. Unfortunately, it is hard to link events that correspond to the same user interaction. For instance, when a user taps, many events are generated, such as pointerdown, mousedown, pointerup, mouseup, and click.
PerformanceEventTiming
interactiveID
pointerdown
mousedown
pointerup
mouseup
click
Chrome supports a new media query called 'prefers-contrast', which lets authors adapt web content to the user's contrast preference as set in the operating system (specifically, increased contrast mode on macOS and high contrast mode on Windows). Valid options are 'more', 'less', 'custom', or 'no-preference'.
'prefers-contrast'
'more'
'less'
'custom'
'no-preference'
Web app manifests now support an optional id field that globally identifies a web app. When the id field is not present, a PWA falls back to start_url. This field is currently only supported on desktop.
id
start_url
Enable web applications to register themselves as handlers of custom URL protocols/schemes using their installation manifest. Operating system applications often register themselves as protocol handlers to increase discoverability and usage. Web sites can already register to handle schemes via registerProtocolHandler(). The new feature takes this a step further by letting web apps be launched directly when a custom scheme link is invoked.
registerProtocolHandler()
Chrome has enhanced Content Security Policy to improve interoperability with WebAssembly. The wasm-unsafe-eval controls WebAssembly execution (with no effect on JavaScript execution). Additionally, the script-src policies now include WebAssembly.
wasm-unsafe-eval
script-src
WebAssembly modules can now hold references to JavaScript and DOM objects. Specifically, they can be passed as arguments, stored in local and global variables, and stored in WebAssembly.Table objects.
This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.
The PaymentRequest API has deprecated the basic card payment method. Its usage is low and declining. It underperforms when compared to other payment methods in time-to-checkout and completion rate. Developers can switch to other payment methods as an alternative. Examples include Google Pay, Apple Pay, and Samsung Pay. Removal timeline:
The Payment Request API is a soon-to-be-recommended web standard that aims to make building low-friction and secure payment flows easier for developers. The browser facilitates the flow between a merchant website and "payment handlers". A payment handler can be built-in to the browser, a native app installed on user’s mobile device, or a Progressive Web App. Today, developers can use the Payment Request API to access several payment methods, including “basic-card” and Google Pay in Chrome on most platforms, Apple Pay in Safari, Digital Goods API on Google Play, and Secure Payment Confirmation in Chrome.
Earlier last year, we announced that we will deprecate the "basic-card" payment handler on iOS Chrome, followed by other platforms in the future. The "basic-card" is a payment method that is typically built into the browser to help users easily enter credit card numbers without remembering and typing them. This was designed to make a good transition from a form based credit card payment to an app based tokenized card payment. In order to better pursue the goal of app based payment (and a few other reasons), the Web Payments WG decided to remove it from the specification.
Starting from version 96, Chrome will show a warning message in DevTools Console (together with creating a report to Reporting API) when the "basic-card" payment method is used. In version 100, the "basic-card" payment method will be no longer available and canMakePayment() will return false unless other capable payment methods are specified. This applies to all platforms including Android, macOS, Windows, Linux, and Chrome OS.
If you are using the Payment Request API with the "basic-card" payment handler, we suggest removing it as soon as possible and using an alternative payment method such as Google Pay or Samsung Pay.
Today we're announcing an important update to the previously communicated Chrome app support timeline. Based on feedback from our Enterprise and Education customers and partners, we have made the decision to extend Chrome app support for those users on Chrome OS until at least January 2025.
We continue to invest and have made significant progress in rich new capabilities on the Web platform with Progressive Web Apps (PWA), and we recommend that Chrome app developers migrate to PWAs as soon as possible. PWAs are built and enhanced with modern APIs to deliver enhanced capabilities, reliability, and installability while reaching anyone, anywhere, on any device with a single codebase. There is a growing ecosystem of powerful desktop web apps & PWAs, from advanced graphics products like Adobe Spark to engaging media apps like YouTube TV to productivity and collaboration apps like Zoom.
For additional support with Chrome app migration, please visit our Web apps on Chrome OS page. This page will be kept up to date as we progress together through this process.
We thank our community of developers who have provided feedback to help us shape this modified and simplified approach. We are inspired by a future beyond Chrome apps, where the ecosystem continues forward progress leveraging open Web standards across all modern browsers.
RenderingNG’s architecture implements performance isolation for all of these features.
To open the side panel and view the results, just click on the G icon next to the search bar. And if you’ve found what you’re looking for or don’t want to see the results any more, you can easily close the panel at any time. We’re experimenting with this feature first in the Chrome OS Dev channel with Google Search, and with any broader rollout in the future, we’d aim to bring it to more platforms with support for more default search engines.
Posted by Yana Yushkina, Product Manager, Chrome
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 95 is beta as of September 23, 2021.
It's our eventual goal to merge the origin private file system of the File System Access API with the Storage Foundation API to reduce the number of entry points for getting access to file-based storage in the browser. A first step toward this objective is the newly proposed access handle. The new feature differs from existing functionality by offering in-place and exclusive write access to a file's content. This change, along with the ability to consistently read unflushed modifications and the availability of a synchronous variant on dedicated workers, significantly improves performance and unblocks new use cases. To join the origin trial, see its entry on Chrome Origin Trials. For more on access handlers, see the information we've added to The File System Access API: simplifying access to local files.
Chrome is trying to reduce the amount of information the user agent string exposes in HTTP requests as well as in navigator.userAgent, navigator.appVersion, and navigator.platform. The user agent string can be used for passive user fingerprinting. To join the origin trial, see its entry on Chrome Origin Trials.
navigator.userAgent
navigator.appVersion
navigator.platform
The following features, previously in a Chrome origin trial, are now enabled by default.
Secure payment confirmation augments the payment authentication experience on the web with the help of the Web Authentication API. The feature adds a new 'payment' extension to that API, which allows a relying party such as a bank to opt-in to creating a PublicKeyCredential that can be queried by any merchant origin as part of an online checkout via the Payment Request API using the 'secure-payment-confirmation' payment method.
PublicKeyCredential
'secure-payment-confirmation'
This feature enables a consistent, low friction, strong authentication experience using platform authenticators. Strong authentication with the user's bank is becoming a requirement for online payments in many regions, including the European Union. The proposed feature provides a better user experience and stronger security than existing solutions.
WebAssembly now provides exception handling support. Exception handling allows code to break control flow when an exception is thrown. The exception can be any that is known by the WebAssembly module, or it may be an unknown exception that was thrown by a called imported function.
Currently, web developers can call PerformanceObserver.observe() with the buffered option to listen to past and future performance entries about their site. Unfortunately, past entries need to be stored, and there is a buffer size limit. The droppedEntriesCount parameter helps developers know if they may have lost an entry due to storage being full.
PerformanceObserver.observe()
droppedEntriesCount
The droppedEntriesCount property is one of the options specified as the third parameter of the callback passed in the PerformanceObserver constructor. It provides the number of entries dropped due to the buffer being full.
PerformanceObserver
The EyeDropper API provides a browser-supplied eyedropper for the construction of custom color pickers. Creative applications built for the web could benefit from an ability to sample a color from pixels on the screen. Many OS applications, PowerPoint for example, have this ability but are unable to carry it over to their web equivalents. Even though some browsers have eyedropper capability built into <input type=color> elements, web applications are limited in their ability to integrate this into their custom color pickers since the eyedropper is generally accessible only through the non-customizable popup triggered by the <input> element.
<input type=color>
<input>
Chrome has updated the value provided by the Sec-CH-UA-Platform-Version on Windows to provide a reasonable level of fidelity to allow sites to identify meaningful Windows platform changes. This enables sites to deliver appropriate binary executables and help content specific to a particular operating system version. The current user agent string and existing Sec-CH-UA-Platform-Version implementation provides the major and minor version Windows components. However, as of Windows 10, Windows generally doesn't increase either of these numbers across significant releases. Notably, Windows 11 does not increase either of these numbers. You can find a table of value mappings to Windows releases in the UA Client Hints' repo issue 220.
Sec-CH-UA-Platform-Version
This function, available in windows and workers, allows developers to report errors to the console and any global "error" event handlers in the same way as an uncaught JavaScript exception. It is mainly useful for custom event-dispatching or callback-manipulating libraries. This allows library developers to report exceptions in the same way the browser does, which is useful when they need custom control over running the callback.
URLPattern is a new web API that provides operating system support for matching URLs given a pattern string. It can be used in JavaScript directly or by passing patterns to other web platform APIs such as, for example, as a service worker scope. Both web platform features and JavaScript applications often need to match against URLs. Examples include, service worker scopes on the web platform and URL routing in JavaScript frameworks. Past web platform features have individually created their own URL matching mechanisms. JavaScript has relied on libraries such as path-to-regexp.
Chrome is removing support for FTP URLs. Use 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. Google Chrome 72 and later removed support for fetching document subresources over FTP and rendering of top level FTP resources. Currently navigating to FTP URLs results in showing a directory listing or a download depending on the type of resource. A bug in Google Chrome 74 and later resulted in dropping support for accessing FTP URLs over HTTP proxies. Proxy support for FTP was removed entirely in Google Chrome 76. In Chrome 86 FTP support was turned off for pre-release channels (Canary and Beta) and experimentally turned off for one percent of stable users, though it could be reenabled via the command line. In Chrome 87 it was turned off for fifty percent of users but could also be enabled through the command line. Since Chrome 88, it was only available through a deprecation trial and is now disabled.
Most hostnames that aren't valid IPv4 addresses, but end in numbers are treated as valid, and looked up via DNS (for example, http://foo.127.1/). Per the Public Suffix List spec, the eTLD+1 of the hostname in that URL should be 127.1. If that is ever fed back into a URL, http://127.1/ is mapped to http://127.0.0.1/ by the URL spec, which seems potentially dangerous. 127.0.0.0.1 could also potentially be used to confuse users. URLs with these hostnames are now rejected.
http://foo.127.1/
127.1
http://127.1/
http://127.0.0.1/
127.0.0.0.1
Chrome now deprecates sharing WebAssembly modules between cross-origin, but same-site environments to allow agent clusters to be scoped to origins long term.
Chrome's legacy U2F API for interacting with security keys is deprecated and beginning a deprecation trial in Chrome 95 wherein the API remains enabled by default, but the trial token will disable the key for participating sites. U2F security keys themselves are not deprecated and will continue to work.
Affected sites should migrate to the Web Authentication API. Credentials that were originally registered via the U2F API can be challenged via web authentication. USB security keys that are supported by the U2F API are also supported by the Web Authentication API.
U2F is Chrome's original security key API. It allows sites to register public key credentials on USB security keys and challenge them for building phishing-resistant two-factor authentication systems. U2F never became an open web standard and was subsumed by the Web Authentication API (launched in Chrome 67). Chrome never directly supported the FIDO U2F JavaScript API, but rather shipped a component extension called cryptotoken, which exposes an equivalent chrome.runtime.sendMessage() method. U2F and Cryptotoken are firmly in maintenance mode and have encouraged sites to migrate to the Web Authentication API for the last two years.
chrome.runtime.sendMessage()
The following timeline is currently planned for deprecation and removal:
Stable as of August 31, 2021. Support added for the googleLegacyAppIdSupport extension.
Beta as of September 23, 2021. The following changes were implemented:
Beta expected in early January 2022, stable in February. The deprecation trial will continue, but its behavior will reverse: the API will be disabled by default, but may be kept alive by trial participants.
Back in May, we published an update on our User-Agent string reduction plans with a promise to publish further details on timing. Now that we have an origin trial ready for testing the Reduced User-Agent header (and associated JS interfaces) we have estimated timelines to share. What follows is repeated from the original blog post, but contains estimated Chrome versions where these Phases will begin to help you prepare.
The Chromium schedule dashboard will be useful for understanding dates associated with each Chrome version and its progression from Canary into Beta and Stable Release.
Note: The usual disclaimers about estimating engineering deadlines apply—unforeseen circumstances may dictate delays. But in the case that we encounter delays, we do not intend to accelerate timelines between Phases.
We plan to roll out these changes slowly and incrementally in 7 Phases—pending origin trial feedback.
Phase 1: Since Chrome 92 (July 20, 2021)
Call to Action (CTA): Audit your site usage to understand where migration may be necessary.
Warn about accessing navigator.userAgent, navigator.appVersion, and navigator.platform in DevTools, beginning in M92.
Phase 2: Chrome 95 to Chrome 100
CTA: Enroll in the origin trial for your site, and provide feedback until Chrome 101 is released.
Launch an origin trial for sites to opt into the final reduced UA string for testing and feedback, for at least 6 months.
We will evaluate feedback from origin trial partners and the community, and based on this feedback proceed to Phases 3 through 7 of our plan, giving the ecosystem adequate time to adapt in between them. Otherwise, depending on feedback we will reconsider the best course of action.
Phase 3: Chrome 100
CTA: Enroll in the deprecation trial or Enterprise policy for your site, when needed.
Launch deprecation trial and Enterprise policy, for instances where a site may need more time for migration.
Phase 4: Chrome 101
CTA: Ensure your site is compatible with the reduced Chrome version number, and migrate to UA Client Hints if not.
Ship reduced Chrome MINOR.BUILD.PATCH version numbers (“0.0.0”). Once rolled-out, the reduced UA string would apply to all page loads on desktop and mobile operating systems for sites that do not opt into the deprecation trial.
Phase 5: Chrome 107
CTA: Ensure your site is compatible with the reduced Desktop UA string and related JS APIs, and migrate to UA Client Hints if not.
Begin roll-out of reduced Desktop UA string and related JS APIs (navigator.userAgent, navigator.appVersion, navigator.platform). Once rolled-out, the reduced UA string would apply to all page loads on desktop operating systems for sites that do not opt into the deprecation trial.
Phase 6: Chrome 110
CTA: Ensure your site is compatible with the reduced Mobile UA string and related JS APIs, and migrate to UA Client Hints if not.
Begin roll-out of reduced Android Mobile (and Tablet) UA string and related JS APIs. Once rolled-out, the reduced UA string would apply to all page loads on Android that do not opt into the deprecation trial.
Phase 7: Chrome 113
Deprecation trial ends and all page loads receive the reduced UA string and related JS APIs.
See the companion Reduced User Agent string updates page for more details and example User Agent strings at each of these phases. We will note any significant delays or changes on this page as well.