Chrome version: 151, 150, 149, 148, 147, 146, 145, 144, 143, 142, 141, 140, 139, 138, 137, 136, 135, 134, 133, 132, 131, 130, 129, 128, 127, 126, 125, 124, 123, 122, 121, 120, 119, 118, 117, 116, 115, 114, 113, 112, 111, 110, 109, 108, 107, 106, 105, 104, 103, 102, 101, 100, 99, 98, 97, 96, 95, 94, 93, 92, 91, 90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80, 79, 78, 77, 76, 75, 74, 73, 72, 71, 70, 69, 68, 67, 66, 65, 64, 63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 50, 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0
This release of Chrome had 18 new features.
Adds "window-management" as an alias for "window-placement" permission and permission-policy strings. This is part of a larger effort to rename the strings by eventually deprecating and removing "window-placement". The terminology change improves the longevity of the descriptor as the Window Management API evolves over time. #
This feature was specified in this Spec.
Docs: https://github.com/w3c/window-placement/blob/main/EXPLAINER_spec_and_permission_rename.md
No linked samplesAll features described in CSS Color 4 (https://www.w3.org/TR/css-color-4/) are now enabled! This includes four device-independent color types (lab, Oklab, lch and Oklch), the color() function and user-defined color spaces for gradients and animations. The incredibly useful color-mix() function from CSS Color 5 (https://www.w3.org/TR/css-color-5/#color-mix) has also been included as a bonus!
This feature was specified in this Spec.
Samples: https://codepen.io/argyleink/pen/RwyOyeqhttps://2021-hd-color-at-css-camp.netlify.app
Adds root font units. Previously, only 'rem' has been supported in Chrome. This feature adds root element variants of ex, ch, ic, and lh. #
This feature was specified in this Spec.
Extend :nth-child(an + b) to take a selector, and the same with :nth-last-child. So e.g. :nth-child(3 of .c) is the third .c under a given parent. (This is not the same as .c:nth-child(3), which is a .c that must also be the third element under a given parent.) #
This feature was specified in this Spec.
Add trigonometric functions sin(), cos(), tan(), asin(), acos(), atan(), atan2() to CSS math expressions. MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Functions#trigonometric_functions #
This feature was specified in this Spec.
Support efficient moves and renames of local files (i.e. user-visible files on the device). Efficient file moves is a core API primitive that dramatically improves the viability of a number of applications on the web. For example, renaming a large video file currently requires obtaining access to a new file, copying all the data, and removing the original. This is slow, error-prone (ex: out of quota), and a poor developer and user experience.
This feature was specified in this Spec.
Docs: https://github.com/a-sully/fs/pull/2
No linked samplesAdds "previousslide" and "nextslide" actions to the existing Media Session API. #
This feature was specified in this Spec.
Samples: https://googlechrome.github.io/samples/media-session/slides.html
Extend the ArrayBuffer constructors to take an additional maximum length that allows in-place growth and shrinking of buffers. Similarly, SharedArrayBuffer is extended to take an additional maximum length that allows in-place growth. #
This feature was specified in this Spec.
This extends the speculation rules [1] syntax to allow developers to specify the referrer policy to use with speculative requests triggered by speculation rules. This also reintroduces the "sufficiently-strict referrer policy" requirement [2]. [1] https://chromestatus.com/feature/5740655424831488 [2] https://github.com/WICG/nav-speculation/blob/main/fetch.md#stripping-referrer-information #
This feature was specified in this Spec.
Chromium has shipped [1] a version of declarative shadow DOM in M90 which currently has 0.014% usage [2]. Mostly, that is due to the spec PR being stalled with no input from other implementers. Recently, there has been renewed interest in the feature, and discussions have resumed. As part of those discussions, two changes have been generally agreed upon: 1. Rename the `<template>` attribute from `shadowroot` to `shadowrootmode`. 2. Support streaming, by attaching the shadow root on the opening, rather than the closing, template tag. While the PR hasn't landed, and there is still an open issue (related to the DOMParser), we would like to ship the agreed upon behavior listed above. [1] https://chromestatus.com/feature/5191745052606464 [2] https://chromestatus.com/metrics/feature/timeline/popularity/3196 #
This feature was specified in this Spec.
Add two String.prototype methods for working with well-formed UTF-16 strings. A JavaScript string value is well-formed UTF-16 if it has no unpaired surrogate code points. By default, JavaScript strings may be ill-formed. - String.prototype.isWellFormed returns whether the receiver string is well-formed UTF-16. - String.prototype.toWellFormed returns a string that is identical to the receiver string, except all unpaired surrogate code points are replaced with U+FFFD (REPLACEMENT CHARACTER). #
This feature was specified in this Spec.
Adds a style() function to @container rules to make it possible to apply styles based on the computed values of custom properties of an ancestor element. style() queries can be combined with size container queries which shipped in M105. #
This feature was specified in this Spec.
Samples: https://www.bram.us/2022/10/14/container-queries-style-querieshttps://una.im/style-queries
View Transitions is an API that enables the creation of polished transitions. Web developers only need minimal effort to make transitions look nice. They can choose to use some default animation properties, or they can customize their own transition effects to achieve a desired transition experience. This is accomplished by leveraging user-agents’ ability to persist visual representations of rendered output (i.e. snapshots) and blend them with the live DOM state’s rendered output. The API also allows these animations to be customized via standard CSS animation properties. #
This feature was specified in this Spec.
Docs: https://github.com/WICG/view-transitions/blob/main/explainer.md
Samples: https://developer.chrome.com/docs/web-platform/view-transitions
This extension defines a standard method for picking between possible Scalable Video Coding (SVC) configurations on an outgoing WebRTC video track. #
This feature was specified in this Spec.
Docs: https://w3c.github.io/webrtc-svc/
No linked samplesReturns the set of features that were enabled for this XRSession as specified by XRSessionInit and the Implied Features required by the spec for the given mode/features. For a granted Session, this will contain all "requiredFeatures", but may be a subset of optionalFeatures. Most features have alternate ways to detect if they were granted; however, for some features the signal of whether or not a feature was enabled may tie closely with data for a feature just not being available "right now", rather than data not being available "ever". By querying enabledFeatures, you can determine if any helpful hints (e.g. to improve/start tracking) should be shown, or if a feature will never be supported in the current session. Future WebXR features may not have other signals to detect whether or not they were enabled, and would require querying this attribute. #
This feature was specified in this Spec.
The "baseline-source" properties allows web developers to specify if an inline-level box should use the "first" or "last" baseline for alignment within an linebox. Today the default behaviour is confusing for web developers. Consider: test <div style="display: inline-block;">line1<br>line2</div> test <div style="display: inline-flex;">line1<br>line2</div> The "inline-block" will align to the last baseline, and the "inline-flex" will align to the first baseline. "baseline-source: auto" is the existing (confusing) behaviour. Web developers can specify "baseline-source: first" or "baseline-source: last" to directly determine how they want these boxes to align within a line-box. #
This feature was specified in this Spec.
When font shorthand is specified all of its subproperties including font-size-adjust, font-kerning, font-feature-settings, font-optical-sizing and font-variation-settings should be reset to their initial value. #
This feature was specified in this Spec.
font-variant-alternates enables simpler access to glyph alternates in fonts such as as a swashes, character-variants, ornaments and more. It provides an easier method over having to use 4-letter-codes as arguments to `font-feature-settings`. font-variant-alternates refers to the @font-feature-values at-rule to map speaking feature names to OpenType feature numbers. In the font-variant-style rule, the requested feature activation becomes easy to use and to read and allows flexible combination of font features. #
This feature was specified in this Spec.
Samples: https://roettsch.es/montecarlo.html
This release of Chrome had 3 new origin trials.
Deprecate the ability for Web Payment API to bypass the connect-src CSP policy when fetching the manifest. After this deprecation, a site's connect-src CSP policy will need to allow for the payment method URL specified in a PaymentRequest call, as well as any other URLs that the method chains to fetch its manifest. #
This feature was specified in this Spec.
Document Picture-in-Picture adds a new API to open an always-on-top window that can be populated with arbitrary HTMLElements. This is an expansion upon the existing HTMLVideoElement API that only allows for an HTMLVideoElement to be put into a PiP window. This allows web developers to provide a better PiP experience to users. #
This feature was specified in this Spec.
Note: this has launched in Chrome 115 We intend to partition a number of APIs in 3rd party contexts. This effort is focused on partitioning APIs above the network stack. This includes quota-managed storage, service workers, and communication APIs (like BroadcastChannel). See the explainer for more details: https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md There is also a deprecation trial available as well as an enterprise policy: https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/ https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting #
This release of Chrome had 6 are available behind a flag.
Adds "window-management" as an alias for "window-placement" permission and permission-policy strings. This is part of a larger effort to rename the strings by eventually deprecating and removing "window-placement". The terminology change improves the longevity of the descriptor as the Window Management API evolves over time. #
This feature was specified in this Spec.
Docs: https://github.com/w3c/window-placement/blob/main/EXPLAINER_spec_and_permission_rename.md
No linked samplesThe Event Timing API is part of the Performance Timeline and is used to measure the performance of user interactions. Certain Events will have an interactionId value assigned to them, and this is useful for grouping related interactions based on common physical user inputs or gestures. This feature adds a very trivial performance.interactionCount, which is just the total number of interactions that have occured on the page. In particular, this feature is useful for computing the Interaction to Next Paint (INP) metric value, which requires knowing the total number of interactions in order to compute a high percentile score (p98 for pages with greater than 50 total interactions). This feature has been specced for a long while, was prototypes in Chromium a long time ago but never shipped, is part of Interop 2025, and is already available in other browsers. (Note: there is already a more powerful performance.eventCounts map for specific events, but it is not possible to accurately map event counts to interaction counts.)
This feature was specified in this Spec.
Docs: https://www.w3.org/TR/event-timing/#dom-performance-interactioncounthttps://www.w3.org/TR/event-timing/#sec-increasing-interaction-count
Samples: https://chrome.dev/inp-demo
Previously, when a resource was prefetched using <link rel=prefetch>, we ignored its cache semantics (namely max-age and no-cache) for the first use within 5 minutes, to avoid refetching. Now, we remove this special case and use normal HTTP cache semantics. This means web developers need to include appropriate caching headers (i.e. Cache-Control or Expires) to see benefits from <link rel=prefetch>. This also affects the nonstandard <link rel=prerender>. This fixes a bug with speculation rules prefetch, where non-2xx responses were cached. However, it does not start requiring caching headers for speculation rules prefetch, since they are intended for navigational prefetching and thus have different caching needs than the normal HTTP cache. #
This feature was specified in this Spec.
The feature makes the navigation of pages with no-op service worker fetch handlers fast by skipping them. Some sites have a no-op (no operation) fetch listener (e.g. onfetch = () => {}). Since having the fetch listener was one of the requirements to be a progressive web app (PWA), we assume they did that to make their site recognized as PWA. However, it only brings overheads to start a service worker and execute a no-op listener without bringing any feature benefits like caching or offline capabilities because the code does nothing. To make the navigation to such pages faster, we would like to omit the service worker start and the listener dispatch from the navigation critical path if a user agent identifies that all the service worker's fetch listeners are no-ops. From version 112, Chromium starts to show console warnings if all the service worker’s fetch listeners are no-ops, and encourages developers to remove the useless fetch listeners. Hopefully sites stop using the useless fetch listeners and we can deprecate the feature in the future. #
This feature was specified in this Spec.
Add two String.prototype methods for working with well-formed UTF-16 strings. A JavaScript string value is well-formed UTF-16 if it has no unpaired surrogate code points. By default, JavaScript strings may be ill-formed. - String.prototype.isWellFormed returns whether the receiver string is well-formed UTF-16. - String.prototype.toWellFormed returns a string that is identical to the receiver string, except all unpaired surrogate code points are replaced with U+FFFD (REPLACEMENT CHARACTER). #
This feature was specified in this Spec.
WebGPU is the successor to the WebGL and WebGL 2 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. WebGPU is developed by the “GPU for the Web” W3C community group. WebGPU previously launched on Windows, MacOS, and ChromeOS in M113. See https://chromestatus.com/feature/6213121689518080 for details.
This feature was specified in this Spec.
Docs: https://gpuweb.github.io/gpuwebhttps://gpuweb.github.io/gpuweb/wgslhttps://gpuweb.github.io/gpuweb/explainer
Samples: https://github.com/austinEng/webgpu-samples
To keep the platform healthy, we sometimes remove APIs from the Web Platform which have run their course. There can be many reasons why we would remove an API, such as:
Some of these changes will have an effect on a very small number of sites. To mitigate issues ahead of time, we try to give developers advanced notice so they can make the required changes to keep their sites running.
Chrome currently has a process for deprecations and removals of API's, essentially:
You can find a list of all deprecated features on chromestatus.com using the deprecated filter and removed features by applying the removed filter. We will also try to summarize some of the changes, reasoning, and migration paths in these posts.
This release of Chrome had 0 features deprecated.
This release of Chrome had 3 features removed.
PaymentInstruments is the Web API that backs non-JIT install of payment apps (see https://w3c.github.io/payment-handler/). It was designed with the assumption that the browser would store the actual payment instrument details, which has not turned out to be true, and has some privacy leaks. It also has not shipped on any other browser, not have we seen any interest from other browser vendors. As such, this API has been deprecated and removed. #
Deprecate the ability for Web Payment API to bypass the connect-src CSP policy when fetching the manifest. After this deprecation, a site's connect-src CSP policy will need to allow for the payment method URL specified in a PaymentRequest call, as well as any other URLs that the method chains to fetch its manifest. #
This feature was specified in this Spec.
The “canmakepayment” service worker event lets the merchant know whether the user has a card on file in an installed payment app. It used to silently pass the merchant's origin and arbitrary data to a service worker from payment app origin. This cross-origin communication happened on PaymentRequest construction in JavaScript, did not require a user gesture, and did not show any user interface. This silent data passage has been removed from the "canmakepayment" event (and the Android IS_READY_TO_PAY Intent). #
This feature was specified in this Spec.
Samples: https://rsolomakhin.github.io/pr/apps/romantic-dirt-jaguar