Chrome version: 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 20 new features.
CSS 'display' property supports two or three keywords. Web authors can specify - How the box and its neighbor boxes are located; inline or block - How children of the box are laid out; flow, flex, grid, etc. separately. For example, `display: inline flow` instead of `display: inline-block` `display: block flex` instead of `display: flex` #
This feature was specified in this Spec.
Docs: https://developer.mozilla.org/ja/docs/Web/CSS/display
No linked samplesChrome has extended the size limit on synchronous WebAssembly compilation on the main thread from 4KB to 8MB. This extension is possible thanks to improvements in the WebAssembly runtime V8. The 8MB limit has been determined through performance measurements on a Google Pixel 1 phone, which is currently considered a representative low-end phone. Future developments in V8 or in hardware may allow to extend the limit further. WebAssembly modules that are bigger than 8MB can be compiled asynchronously with WebAssembly.compile(), or sychronously on a Worker. #
This feature was specified in this Spec.
This API measures ad conversions (e.g. purchases) and attributes them to ad interactions without using cross-site persistent identifiers like third-party cookies. The API allows measurement through both event-level reports sent directly from the browser, and aggregatable reports which can be processed through a trusted service to create summary reports of attribution data. An earlier version of this API was in Origin Trial from Chrome 86 through Chrome 97 which only supported click-through #
This feature was specified in this Spec.
Support style() container queries without a declaration value, only a property name, as a way of matching non-initial values. Previously you would have to do: not style(--my-property: initial) Now you can do: style(--my-property) to match any non-initial value. #
This feature was specified in this Spec.
When performing browsing data removal (e.g. via chrome://settings/clearBrowserData, hard reload, or the `Clear-Site-Data ` header), the disk and in-memory cache for the HTTP response will be cleared. In addition to this, if the browsing data removal's data type is "cache", then all the BFCache entries matching the origin will be cleared as well. #
This feature was specified in this Spec.
Supports "mediation requirements" to provide streamlined re-authentication UX for users who have created federated accounts on websites with FedCM API. #
This feature was specified in this Spec.
Docs: https://github.com/fedidcg/FedCM/issues/429
Samples: https://webid-fcm.glitch.me
Fenced frames are frames isolated from their embedding page. More details in the explainer here: https://github.com/WICG/fenced-frame/tree/master/explainer The OT for fenced frames is part of the joint Privacy Sandbox OT, which follows the timeline here: https://privacysandbox.com/intl/en_us/open-web/ #
This feature was specified in this Spec.
Automatically and optimistically upgrade all main-frame navigations to HTTPS, with fast fallback to HTTP. #
This feature was specified in this Spec.
Samples: http://example.comhttp://www.alwayshttp.com
This feature allows pages to disable the running of unload event handlers. The goals are: - allow sites that have removed all unload handlers to not regress (i.e. accidentally adding new ones) - allow sites to “remove” (skip) unload handlers (e.g. if updating the code is infeasible, or if they have nondeterministic chains of third parties and would rather not risk the BFCache benefits over unload handlers in third party code). Unload event handlers are problematic for various reasons and prevent use of BFCache on Desktop (see https://web.dev/bfcache/#never-use-the-unload-event). This is the first step to deprecating and removing unload handlers. #
This feature was specified in this Spec.
Docs: https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md
No linked samplesA collection of APIs to facilitate advertising: FLEDGE, Topics, Fenced Frames and Attribution Reporting. #
This feature was specified in this Spec.
This is a new API for propagating user signals across sites, without using cross-site persistent identifiers like third party cookies for anti-fraud purposes. Anti-fraud methods that rely on third party cookies will not work once third party cookies are depreciated. The motivation of this API is to provide means to fight fraud in a world with no third party cookies. Private State Token API does not generate or define anti-fraud signals. This is up to the corresponding first party and the token issuers. The API enforces limits on the information transferred in these signals for privacy concerns. Private State Token API is based on the Privacy Pass protocol from the IETF working group. It can be considered as a web-exposed form of the Privacy Pass protocols. Private State Token API spec is to be updated for new versions and types of tokens. The API will be kept up to date with the Privacy Pass working group specs. Expected changes would be in the underlying cryptographic protocols and token issuance code. We do not expect changes in the developer facing fetch API. The Private State Token API was formerly known as the Trust Token API. It is renamed to more accurately capture the underlying semantics and to highlight the privacy benefits to users. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit
No linked samplesProvides a privacy advancing API to facilitate interest group based advertising. The Protected Audience API shifts the interest data and the final ad decision browser-side instead of server-side, offering many advantages: strong privacy guarantees, as well as time limits on group membership, transparency into how the advertiser interest groups are built and used, and granular or global controls over this type of ad targeting. #
This feature was specified in this Spec.
Related Website Sets (“RWS”) provides a framework for developers to declare relationships among sites, to enable limited cross-site cookie access for specific, user-facing purposes. This is facilitated through the use of the Storage Access API. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1Lbvn3Wt664AhWA-UytjGEi7UcRMhrR4trUWEi2ieUkE/edit#heading=h.t7ybo54eelkdhttps://docs.google.com/document/d/16m5IfppdmmL-Zwk9zW8tJD4iHTVGJOLRP7g-QwBwX5c/edit?usp=sharing
No linked samplesExpose PerformanceResourceTiming.firstInterimResponseStart In cases where a navigation or subresource fetch encounters an interim 1xx response, e.g. 100 continue or 103 early hints, firstInterimResponseStart would now correspond to the time of that first interim response, while responseStart would correspond to the final response, e.g. with 200 status. #
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.
The intent of the Topics API is to provide callers (including third-party ad-tech or advertising providers on the page that run script) with coarse-grained advertising topics that the page visitor might currently be interested in. These topics will supplement the contextual signals from the current page and can be combined to help find an appropriate advertisement for the visitor. Explainer: https://github.com/jkarlin/topics #
This feature was specified in this Spec.
Node.lookupNamespceURI() supports "xml" and "xmlns" prefixes by default. The function returns fixed namespace strings for them. Document.createNSResolver() and XPathEvaluator.createNSResolver() stops to wrap the specified node to add "xml" prefix handling. They return the specified node as is. Web developers can use an element as an XPathNSResolver without wrapping it with createNSResolver(). #
This feature was specified in this Spec.
Exposes visibility state (visible/hidden) in the performance timeline. The timeline would always have an entry with a startTime of 0 and the initial visibility state, plus entries corresponding to any visibility state change. #
This feature was specified in this Spec.
Adds the `wgslLanguageFeatures` getter on the GPU object for WebGPU, and its corresponding `WGSLLanguageFeatures` type. #
This feature was specified in this Spec.
This exposes several WebDriver commands to allow browser automation, such as automated testing, to interact with FedCM dialogs. #
This feature was specified in this Spec.
Docs: https://github.com/fedidcg/FedCM/blob/main/proposals/webdriver.md
No linked samplesThis release of Chrome had 2 new origin trials.
A generic mechanism for measuring aggregate, cross-site data in a privacy preserving manner. The potentially identifying cross-site data is encapsulated into "aggregatable reports". To prevent leakage, this data is encrypted, ensuring it can only be processed by the aggregation service. During processing, this service will add noise and impose limits on how many queries can be performed. #
This feature was specified in this Spec.
Allows for unpartitioned storage that may only be read in a secure environment with carefully constructed output gates. This API is intended to support many of the use cases of third-party cookies without permitting cross-site user tracking. #
This feature was specified in this Spec.
This release of Chrome had 3 are available behind a flag.
The `document.domain` setter allows developers to relax the same-origin policy, complicating the fundamental security boundary we aim to maintain, and putting roadblocks in the way of post-Spectre changes to Chromium's process model. We should deprecate it, by making it opt-in via `Origin-keyed agent clusters` (https://chromestatus.com/features/5683766104162304) The setter will remain, but the origin remains unchanged. In that case the compatibility risk is low. #
This feature was specified in this Spec.
Samples: https://origin-agent-cluster-demo.dev/no-header.htmlhttps://origin-agent-cluster-demo.dev/explicit-false.html
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 feature was specified in this Spec.
ScrollTimeline and ViewTimeline are an extension to the Web Animations spec which allow developers to use the position of a scroller or the position of an element within a scroller as an input 'time' rather than the default monotonic clock time. This enables fast scroll-based animations, such as a shrinking navigation bar, without requiring user script execution. They can be declared and instantiated both via CSS and Javascript used in CSS animations and Web Animations. #
This feature was specified in this Spec.
Samples: https://scroll-driven-animations.style
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 0 features removed.