Sunsetting the "basic-card" payment method in the Payment Request API

Thursday, October 21, 2021

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.

Posted by Eiji Kitamura, Developer Advocate on the Chrome team

Extending Chrome App Support on Chrome OS

Thursday, October 14, 2021

Posted by Paul Rossman, Technical Program Manager, Chrome

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: an architecture that makes and keeps Chrome fast for the long term

Wednesday, October 6, 2021

Our continual investments in the performance of Chrome have led to significant improvements in battery life, memory, and the speed of the web. This post in The Fast & the Curious series highlights the rendering journey of Chrome over the past eight years, a journey that has led to a browser that is better across the board. For example, Chrome 94, as compared with Chrome 93:

is up to 8% more responsive on real pages,

saves more than 1400 years of CPU time per day, and

improves battery life by up to 0.5%

In addition, recent versions of Chrome are much better than those of years past with:

150% or more faster graphics rendering, and

greater reliability, due to a 6x reduction in GPU driver crashes on problematic hardware

IntroductionRenderingNG

RenderingNGcoming to a conclusion

The pyramid of success

Performance

GPU & multi-core

A great way Chrome can render content faster is to take advantage of the multi-core CPUs and advanced GPUs present in today’s devices. Multi-core means we can do multiple kinds of work in parallel. For example, Chrome parallelizes running JavaScript, scrolling a web page, decoding an image or video, and rastering new content that will be on-screen soon. GPUs enable even more parallelization by rastering every pixel on-screen, rather than one-at-a-time, yielding a large speedup.

Earlier generations of browsers were not built to natively support these technologies, because at the time GPUs and multi-core computers were not widespread. It turned out that bolting on highly parallel features was extremely challenging, requiring the team to re-architect the entire Chrome rendering pipeline over time. This re-architecture is RenderingNG.

Scaling up and scaling down

To avoid exhausting available resources and potentially diminishing the user experience of the web, browsers must be respectful of efficiency. They should not slow down your ability to interact with your computer or phone, or keep you from multitasking between the browser and other apps. Likewise, browsers also need to maximize battery life of your phone and laptop, and prevent the device itself from getting too hot (here’s looking at you, CPU cooling fans!). And finally, the browser must always be smooth and responsive to the user.

This means that the browser needs to be able to scale up and down its use of the GPU and multi-threading to balance multitasking, battery, and device temperature. As one example of scaling up, it’s important that scrolling happen in parallel with JavaScript on all devices; otherwise the browser will have poor user responsiveness. On the other hand, there are times when the browser must scale down because battery life may be considered more important than maximum use of GPU and CPU resources to make rendering faster.

It turns out to be challenging to be able to scale up and scale down seamlessly, and in a way that doesn’t break web content or make the browser unresponsive in key situations. RenderingNG applies novel technologies throughout the stack to make this work, including a complete rewrite of how compositing works, enabling the flexible use of GPU or CPU computations for arbitrary pieces of web pages, in order to pick the right fit for each web page and device.

Performance isolation

The third key technique is performance isolation. Performance isolation is what allows you to have a nice experience reading your email while music and video is playing in the background: your computer and operating system (OS) architecture makes sure that they all share the CPU fairly and smoothly. (This feature has been around for native apps for so long, we just take it for granted, but it wasn’t always that way!)

Browsers already have good isolation from other apps on your computer (thanks to the OS), but within a web page, it can be difficult to isolate all the pieces, such as iframes for ads and other embedded content, video and audio, animations, scrolling, JavaScript, and various other browser tasks. In earlier eras of the web, it was a huge achievement to simply make all these features work at all. Now the bar has been raised, and they need to fit together seamlessly in order to create a reliably fast user experience on the web.

RenderingNG’s architecture implements performance isolation for all of these features.

Reliability

Most of our work has been focused on reliability of the user experience. This is especially true when rewriting the entire rendering stack of a web browser--a huge and potentially risky undertaking.

We did this with four key techniques:

Comprehensive testing, such as a huge battery of Web Platform Tests,
Measuring progress in reliability, through metrics that track performance & quality, and committed goals such as Compat2021,
Listening to and acting on bug reports and feedback,
Good software design patterns.

Compat2021 improvements over time

Extensibility

Finally, we always have one eye toward what web apps will need now and in the future to unlock better and better experiences for users. These apps are always pushing at the boundary of what is possible to do well on the web, and sometimes beyond. When they go beyond what current web APIs or architectures were designed for, the web app may still work, but it’ll sometimes be slower and more cumbersome to use---and more taxing on your computer than necessary. We are filling these gaps with new APIs that allow web apps to continue doing all these things, but in a way that is much easier to implement performantly.

Extensibility has been part of the design of RenderingNG from the beginning, and is a big reason why the system is clean and modular.

Results

The first RenderingNG performance optimization shipped in 2015. Below we’ve highlighted a few of the many subsequent performance improvements since then.

CompositeAfterPaint: faster and more responsive on all pages [1]

In the M94 release, we will ship CompositeAfterPaint, a new compositing subsystem that allows for arbitrary scaling up and down of GPU use for web app content. Even better, due to more efficient, purpose-built algorithms in this subsystem, CompositeAfterPaint will substantially improve:

Scroll latency by up to 8%
Responsiveness by up to 3%
Peak rendering speed by up to 3%
GPU memory use by more than 3%
CPU time spent rendering and interacting with tabs, resulting in a savings of more than 1400 years of CPU time per day
Battery life by up to 0.5%

GPU Raster: dramatically faster than before [2]

When it shipped on Mac in 2016, GPU raster resulted in a 37% improvement on the overall MotionMark benchmark, and 150% on HTML categories. We subsequently brought similar wins to all other platforms and content types, concluding in 2020. In 2021 we shipped improvements focused on further GPU acceleration for 2D Canvas rendering, with up to a 1000% improvement in the Path rendering test, and a 130% improvement overall on the MotionMark 1.2 benchmark, as measured on an Apple M1 Mac.

Out-of-process Raster: much-improved reliability [1]

Out-of-process raster shipped on Android in 2018. This reduced the crash rate for problematic GPU drivers by 6x, bringing reliability in line with other drivers.

Learn more

If you’d like to learn more about RenderingNG, head over to the Chrome Developers Blog, where we are publishing a whole series about the project, with more to come over time.

Thanks for reading!

Posted by Chris Harrelson, Lead Rendering Software Engineer

[1] Data source: Real-world data anonymously aggregated from Chrome clients.
[2] Data source: MotionMark.

Helping users explore the web and continue prior tasks

Friday, October 1, 2021

When you’re looking for a certain piece of information or working on a project, your path through the internet likely isn’t a linear one. You might search for the same thing multiple times, jump between pages, head back to Google Search again, or parse through your history for that one page you can’t seem to find again. It can be challenging, and more importantly, it can take up time that you could be using to get things done.

Now, we’re kicking off two new experiments with the goal of making it easier to navigate, explore and keep track of the things you find on the web.

Continue your explorations of the web
If you’ve already started exploring a topic and visited multiple sites along the way over a number of days or weeks, chances are you’ve found helpful information you might want to revisit. But you also undoubtedly took a few detours along this journey to read the news, email a friend and shop for a new pair of shoes in the meantime. To help you take stock of completed research, revisit that one helpful nugget and continue exploring a certain topic, we’re experimenting with a new feature called Journeys.

If you’ve been researching a trip to Yosemite for the past few weeks, Journeys will cluster all the pages you’ve visited related to Yosemite so you can easily view them without having to sift through your browsing history. You’ll also see related search suggestions so you can continue planning your trip right there.

Importantly, you're in control of your Journeys experience. For example: you can turn off Journeys at any time, and as always, you can easily clear your browsing history right from your Chrome settings, or by typing "clear browsing data" into the address bar. If you'd like, you can also clear history that's related to a particular journey vs. your history overall. Finally, the current Journeys experiment only groups history on your device — nothing is saved to your Google account. Based on user feedback and interest, future versions may offer the ability to access Journeys in Chrome across multiple devices (just like bookmarks or passwords).

We’re rolling out Journeys as an experiment in Chrome Canary on desktop and are looking forward to feedback so we can continue to improve it before rolling it out widely.

Easily compare search results on Chrome OS

In addition to helping you revisit past journeys, we’re also experimenting with ways to help you more easily find what you’re looking for when you’re actively searching for something. Whether you're shopping for a gift, planning a trip, comparing restaurants for a dinner with friends or seeking a recipe for dinner, you’ll likely visit more than one site to find what you need.

To make it easier to compare search results and find what you’re looking for more quickly in Chrome, we’re experimenting with a new side panel in the Chrome OS Dev channel, so you can view a page and the search results at the same time. This lets you view a page right in your main browser window without needing to navigate back and forth or losing your search results. The goal of this experiment is to explore how Chrome can better help users easily compare results, akin to the feature we announced last month.

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.
These experiments are just two of the ways we’re iterating on how Chrome can be more helpful as you explore the web. You might start seeing Journeys in Chrome Canary on desktop and the new side panel on the Chrome OS Dev channel, so we wanted to explain a little bit more about how they’ll work and, as always, we’re looking forward to your feedback.
Posted by Yana Yushkina, Product Manager, Chrome

Chrome 95 Beta: Secure Payment Confirmation, WebAssembly Exception Handling and More

Thursday, September 23, 2021

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.Origin TrialsThis 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. New Origin TrialsAccess Handles for the File System Access APIIt'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.Reduce User Agent String InformationChrome 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.Completed Origin TrialsThe following features, previously in a Chrome origin trial, are now enabled by default.Secure Payment ConfirmationSecure 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.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 Exception HandlingWebAssembly 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. Other Features in this ReleaseAdding droppedEntriesCount to PerformanceObserver CallbackCurrently, 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. 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. EyeDropper APIThe 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.New UA platform Version Source on Windows for User Agent Client HintsChrome 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.self.reportError()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. URLPatternURLPattern 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.Deprecations, and RemovalsThis version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.FTP Support RemovedChrome 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.Support for URLs with non-IPv4 Hostnames Ending in NumbersMost 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.WebAssembly Cross-Origin Module SharingChrome now deprecates sharing WebAssembly modules between cross-origin, but same-site environments to allow agent clusters to be scoped to origins long term. Deprecate U2F API (Cryptotoken)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.The following timeline is currently planned for deprecation and removal:Chrome 93Stable as of August 31, 2021. Support added for the googleLegacyAppIdSupport extension.Chrome 95Beta as of September 23, 2021. The following changes were implemented:

Gated U2F API requests behind a user permission prompt.

Logged a deprecation notice in the DevTools console for every request.

Chrome 98Beta 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.Chrome 103Beta expected in late May 2022, stable in late June. The deprecation trial will end.Chrome 104Beta expected in late June 2022, stable in early August. The U2F API will be fully removed.

User-Agent Reduction Origin Trial and Dates

Tuesday, September 14, 2021

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.Proposed Rollout PlanWe plan to roll out these changes slowly and incrementally in 7 Phases—pending origin trial feedback.Reduction PreparationPhase 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 100CTA: 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.Reduction RolloutPhase 3: Chrome 100CTA: 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 101CTA: 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 107CTA: 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 110CTA: 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.Reduction CompletionPhase 7: Chrome 113Deprecation 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.

Posted by Mike Taylor and Jade Kessler, Chrome Team

Chrome 94 Beta: WebCodecs, WebGPU, Scheduling, and More

Thursday, August 26, 2021

Video and audio decoders

Video and audio encoders

Raw video frames

Image decoders

This feature has also completed its origin trial in Chrome 93 and is now available by default. For more information, see Video processing with WebCodecs. WebGPUThe WebGPU API is the successor to the WebGL and WebGL2 graphics APIs for the Web. It provides modern features such as "GPU compute" as well as lower overhead access to GPU hardware and better, more predictable performance. This is an improvement over the existing WebGL interfaces, which were designed for drawing images but could only be repurposed for other kinds of computations with great effort.WebGPU exposes modern computer graphics capabilities, specifically Direct3D 12, Metal, and Vulkan, for performing rendering and computation operations on a graphics processing unit (GPU). Advantages of WebGPU over earlier technologies include:

Separating resource management, work preparation, and submission to the GPU.

Pipeline states that function similarly to OS APIs.

Binding groups that allow graphics drivers to perform needed preparations in advance of rendering.

This feature is starting an origin trial in Chrome 94 with the hope of shipping in Chrome 99. For more information, see Access modern GPU features with WebGPU.Scheduling APIs: Prioritized scheduler.postTask()It's difficult to build web apps that are responsive to user interaction and that remain responsive over time. Scripts are one of the primary culprits hurting responsiveness. Consider a "search-as-you-type" feature: an app with this capability needs to keep up with the user's typing at the same time that it is fetching and displaying results. This doesn't take into account anything happening on the page such as animation, which must be rendered smoothly.The problem is usually tackled by chunking and scheduling main thread work, specifically executing work asynchronously at appropriate times. This approach has its own problems, including the fact that whatever priority the developer sets, it's still competing for time on the main thread, which doesn't recognize the developer's prioritization, and is also responsible for browser tasks such as fetch() operations and garbage collection. The scheduler.postTask() method fixes these scheduling dilemmas by letting developers schedule tasks (JavaScript callbacks) with an OS browser scheduler at three levels of priority: user-blocking, user-visible, and background. It also exposes a TaskController interface, which can dynamically cancel tasks and change their priority. This feature completed its origin trial in Chrome 93 and is now available by default in Chrome. For a list of other new and completed origin trials, see the Origin Trials section below.Origin TrialsIn addition to the items above, 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. New Origin TrialsEarly Hints for NavigationChrome is testing a new HTTP status code: 103 Early Hints for preloading subresources earlier.
When a 103 response includes <link rel=preload> or other link headers Chromium tries to preload (and/or preconnect, prefetch) specified resources before the final response is received. This gives web developers a way to optimize apps, sites, and pages.Completed Origin TrialsThe following features, previously in a Chrome origin trial, are now enabled by default.Canvas Color ManagementThis update formalizes that the default color space for CanvasRenderingContext2D objects and ImageData objects is sRGB. This clarifies that the CanvasRenderingContext2D interface is fully color managed (that all inputs are converted to the canvas color space). These were previously conventions and not clearly specified. This updates makes the following changes:

Adds parameters to specify a non-sRGB color space when creating a CanvasRenderingContext2D object or an ImageData object.

Adds support for the Display P3 color space for these parameters.

Content displayed by CanvasRenderingContext2D is currently limited to the sRGB color space, which is less than the capabilities of modern displays and cameras. This feature allows creating a CanvasRenderingContext2D object that is in the Display P3 color space. This also clears up several points of ambiguity about the color behavior of CanvasRenderingContext2D.VirtualKeyboard APIThe VirtualKeyboard interface has methods and properties to control when a virtual keyboard is shown or hidden. It also fires events with the size of the virtual keyboard when it occludes content in the page. The virtual keyboard is the on-screen keyboard used for input in scenarios where a hardware keyboard may not be available. Unlike a hardware keyboard, a virtual keyboard can adapt its shape to optimize for the expected input. Developers have control over the displayed shape of the virtual keyboard through the inputmode attribute, but have limited control over when the virtual keyboard is shown or hidden.Other features in this releaseCSSAlign transform-style: preserve-3d and perspective Property with the SpecThe transform-style: preserve-3d and perspective properties now align with the spec. The preserve-3d property allows child elements to participate in the parent's 3D scene, and the perspective property applies a perspective transform to child elements. Before this change, Chromium applied both of these effects based on the containing block hierarchy rather than the DOM tree, and allowed them to extend through elements without transform-related properties on them.flex-basis Honors Keywords 'content' and 'min/max/fit-content'Chrome now supports the keywords content, min-content, max-content, and fit-content as values for the flex-basis property and its flex shorthand. The content keyword makes flex base size use the default sizing rules as if flex-basis and preferred size property (width or height) are both auto, ignoring any specified width or height in the main axis dimension when flex-basis is auto. The other keywords are the same as usual and give more options for specifying the flex base size.In responsive layouts, when adding or removing display:flex to a container, you previously had to sometimes add/remove values for each individual item. content eliminates the need in some situations.scrollbar-gutterThe scrollbar-gutter property provides control over the presence of scrollbar gutters (the space reserved to display a scrollbar), allowing developers to prevent layout changes as content expands while avoiding unwanted visuals when scrolling isn't needed.

Note that the presence of the scrollbars themselves is determined by the overflow property. The choice of classical or overlay scrollbars is up to the user agent. This property provides developers with more control over how their layouts interact with the scrollbars provided by the browser.MediaStreamTrack Insertable Streams (a.k.a. Breakout Box)This API lets developers manipulate raw media carried by MediaStreamTracks such as the output of cameras, microphones, screen captures or the decoder part of a codec and the input to the decoder part of a codec. It uses WebCodecs interfaces to represent raw media frames and exposes them using streams, similar to the way the WebRTC Insertable Streams exposes encoded data from RTCPeerConnections. Example use cases include funny hats and real-time object identification and annotation.Return Fixed Lists for navigator.plugins and navigator.mimeTypesWith the removal of Flash, there is no longer a need to return anything for navigator.plugins and navigator.mimeTypes. These APIs were used primarily for:

Probing for Flash player support

Fingerprinting.

Some sites use these APIs to probe for PDF viewer support. With this change, these arrays will return fixed lists containing a standard list of PDF viewer plugins.Note that this is not the removal or change of any API, it is merely the return of fixed arrays for these two existing APIs.JavaScriptThis version of Chrome incorporates version 9.4 of the V8 JavaScript engine. It specifically includes the change listed below. You can find a complete list of recent features in the V8 release notes.Self Profiling APIChrome now supports a web-exposed sampling profiler for measuring client JavaScript execution time. Gathering JavaScript profiles from real users can help developers debug slow observed performance without invasive manual instrumentation.Deprecations, and RemovalsThis version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.Deprecate and Remove WebSQL in Third-Party ContextsWebSQL in third-party contexts is now deprecated. Removal is expected in Chrome 97. The Web SQL Database standard was first proposed in April 2009 and abandoned in November 2010. Gecko never implemented this feature and WebKit deprecated in in 2019. The W3C encourages Web Storage and Indexed Database for those needing alternatives.Developers should expect that WebSQL itself will be deprecated and removed when usage is low enough.Restrict Private Network Requests for Subresources to Secure ContextsPrivate network requests for subresources may now only be initiated from a secure context. Private network requests are those initiated from a public network, targeting a private network. Examples include internet to intranet requests and intranet loopbacks. This is a first step towards fully implementing Private Network Access. Servers running inside local networks, or on a user's device, expose powerful capabilities to the web in ways that can be quite dangerous. Private Network Access proposes a set of changes to limit the impact of requests to these servers by ensuring that the servers are opting-into any communication with external entities.For this opt-in to have any meaning, the servers need to be able to ensure that the client origin is authenticated. To that end, only secure contexts are empowered to make external requests.

Chromium Blog