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 26 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 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. #
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
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 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.
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.
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.
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
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. #
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.
Browsers may block third-party resources from accessing cookies and other storage for privacy and security reasons. The most popular reason is cross-site tracking prevention. Such blocking breaks authenticated cross-site embeds such as commenting widgets, embedded payment providers, and subscribed video services. The Storage Access API provides a means for authenticated cross-site embeds to check their blocking status and request access to storage if they are blocked. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1q5Q-8MJcfZamGAXLpjiXiPYR1Tov5JOGw0Z8Fv0TWFk
Samples: https://webkit.org/blog/8124/introducing-storage-access-api
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 samplesAn extension to the Storage Access API that allows a top-level site to request access to unpartitioned ("first-party") cookies on behalf of embedded sites. Browsers will have discretion to grant or deny access, with mechanisms like Related Website Set membership as a potential signal. This allows for use of the Storage Access API by top-level sites.
This feature was specified in this Spec.
This release of Chrome had 7 new origin trials.
The Compute Pressure API offers high-level states that represent the pressure on the system. It allows the implementation to use the right underlying hardware metrics to ensure that users can take advantage of all the processing power available to them as long as the system is not under unmanageable stress. “Pressure” is a generic term by design – at the moment it is calculated based on CPU load, but future plans include using signals from temperature and battery status, for example. #
This feature was specified in this Spec.
Docs: https://developer.chrome.com/docs/web-platform/compute-pressure
Samples: https://w3c.github.io/compute-pressure/demo
Chrome is removing support for signature algorithms using SHA-1 for server signatures during the TLS handshake. This does not affect SHA-1 support in server certificates, which was already removed, or in client certificates, which continues to be supported. SHA-1 can be temporarily re-enabled via the temporary InsecureHashesInTLSHandshakesEnabled enterprise policy. This policy will be removed in Chrome 123. #
This feature was specified in this Spec.
Allow attaching information about which functions should be eager parsed & compiled in JavaScript files. The information will be encoded as magic comments. We'll first target launching the file-based explicit compile hints, and as a follow up, investigate selecting individual functions for eager compilation. #
This feature was specified in this Spec.
Adds a hint to speculation rules that informs the navigation prefetch cache that the URL to be prefetched expects to receive the same No-Vary-Search header in the response. The hint is useful because prefetches that depend on No-Vary-Search to match to navigations do not benefit the user if the navigation happens before prefetch headers return from the server. Using the hint, the web browser will expect, but verify, that the No-Vary-Search hint matches with the No-Vary-Search header. If the No-Vary-Search hint does not match the No-Vary-Search header received then the web browser will send a new request.
This feature was specified in this Spec.
Storage Buckets gives sites the ability to organize on-device data into separate "buckets", allowing user agents to evict the grouped data independently of that which is in other buckets, and enabling sites to ergonomically manage semantically related data. Each storage bucket can contain data associated with established storage APIs such as IndexedDB and CacheStorage. #
This feature was specified in this Spec.
The TLS Encrypted ClientHello (ECH) extension enables clients to encrypt ClientHello messages, which are normally sent in cleartext, under a server’s public key. This allows websites to opt-in to avoid leaking sensitive fields, like the server name, to the network by hosting a special HTTPS RR DNS record. (Earlier iterations of this extension were called Encrypted Server Name Indication, or ESNI.) If your organization’s infrastructure relies on the ability to inspect SNI, for example, filtering, logging, and so on, you should test it. You can enable the new behavior by navigating to chrome://flags and enabling the #encrypted-client-hello flag. If you notice any incompatibilities, you can use the EncryptedClientHelloEnabled enterprise policy to disable support for ECH. #
This feature was specified in this Spec.
Samples: https://tls-ech.dev
Provides a method for yielding control to the browser, which can be used to break up long tasks. Awaiting the promise returned by scheduler.yield() causes the current task to yield, continuing in a new browser task. This can be used to improve responsiveness issues caused by long tasks. Continuations are prioritized to mitigate performance problems of existing alternatives. #
This feature was specified in this Spec.
This release of Chrome had 14 are available behind a flag.
The AccentColor and AccentColorText system colors can be used in CSS to access the system accent color specified on the user's device. This allows developers to apply native app like styling to their web content in contexts where users expect OS theme integration, such as an installed web application. Users must be in an installed web application on the initial profile to see the system accent color rendered. #
This feature was specified in this Spec.
This feature adds the ability to construct exclusive accordions using a sequence of HTML <details> elements. It adds a name attribute to the <details> element. When this attribute is used, multiple <details> elements that have the same name form a group. At most one element in the group can be open at once. #
This feature was specified in this Spec.
This feature mitigates bounce tracking on the web. It works by deleting state from sites that access storage during a redirect that the user has never directly interacted with. See the specification for more details. #
This feature was specified in this Spec.
Docs: https://developer.chrome.com/docs/privacy-sandbox/bounce-tracking-mitigationshttps://developer.chrome.com/blog/bounce-tracking-mitigations-dev-trial
Samples: https://bounce-tracking-demo.glitch.me
Supports using the <image> syntax for custom properties registered with @property or registerProperty(). The <image> syntax can be used to restrict values of the custom property to url() values and generated images like gradients.
This feature was specified in this Spec.
Supports using the <transform-function> and <transform-list> syntaxes for custom properties registered with @property or registerProperty(). The syntax can be used to restrict values of the custom property to represent transforms. This also makes it possible to use transitions and animations directly on these registered custom properties. #
This feature was specified in this Spec.
Allow authors to start CSS transitions on first style update CSS transitions do not trigger transitions from initial styles on the first style update for an element, or when the display type changes from 'none' to some other type. That is done to avoid unexpected transitions from initial styles. If the author wants to start a transition from the first style update, that can now be done by applying styles from within a @starting-style rule. If there is no pre-existing style for an element, but there are selectors inside @starting-style rules that match the element, a style is computed with rules inside @starting-style matching, before the actual style is computed without @starting-style rules matching. Any differences in computed style for transitioned properties will trigger transitions between the styles with and without @starting-style rules applied. Example which starts a background-color transition from green to lime on the first style update for a div: div { transition: background-color 0.5s; background-color: lime; } @starting-style div { background-color: green; } } #
This feature was specified in this Spec.
Chrome is removing support for signature algorithms using SHA-1 for server signatures during the TLS handshake. This does not affect SHA-1 support in server certificates, which was already removed, or in client certificates, which continues to be supported. SHA-1 can be temporarily re-enabled via the temporary InsecureHashesInTLSHandshakesEnabled enterprise policy. This policy will be removed in Chrome 123. #
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
Adds a hint to speculation rules that informs the navigation prefetch cache that the URL to be prefetched expects to receive the same No-Vary-Search header in the response. The hint is useful because prefetches that depend on No-Vary-Search to match to navigations do not benefit the user if the navigation happens before prefetch headers return from the server. Using the hint, the web browser will expect, but verify, that the No-Vary-Search hint matches with the No-Vary-Search header. If the No-Vary-Search hint does not match the No-Vary-Search header received then the web browser will send a new request.
This feature was specified in this Spec.
Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read Blocking (CORB - https://chromestatus.com/feature/5629709824032768). CORB and ORB are both heuristics that attempt to prevent cross-origin disclosure of “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's second step toward full ORB implementation. ORB specifies error handling for blocked resources differently from CORB: ORB raises network errors, while CORB injects an empty response. ORB "v0.1" still used CORB-style response injection. This change brings our implementation more in line with the ORB proposal, by changing the error handling of all fetches (except when initiated by a script) to be compliant with ORB. We've made a carve-out for script-initiated fetches (where we retain CORB behaviour for now) to limit compatibility risk. #
This feature was specified in this Spec.
Docs: https://github.com/whatwg/fetch/pull/1442
No linked samplesRelated 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 samplesThe Login Status API [1] (formerly IdP Sign-in Status API) allows identity providers to signal to the browser when their users are logging-in/out. Our goal is to open this up to other websites in the future. This signal, in this intent, is used by FedCM to address a silent timing attack, and in doing so, allows FedCM to operate without third party cookies altogether. This update would address the last remaining backwards incompatible changes we had previously identified in the original I2S of FedCM [2] as part of our scope of work. In the future, we expect that the Login Status API may also be used outside of FedCM (e.g. the Storage Access API [3]) and may be useful for websites that are not identity providers (e.g. extending browser storage [4]). [1] https://github.com/fedidcg/login-status [2] https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/E9pgS7GEBAAJ [3] https://github.com/fedidcg/login-status#storage-access-api [4] https://github.com/fedidcg/login-status#extending-site-data-storage #
This feature was specified in this Spec.
Adds a "scope_extensions" web app manifest field that enables web apps to extend their scope to other origins. Example usage: { "name": "Example", "display": "standalone", "start_url": "/index.html", "scope_extensions": [ {"type" : "origin", "origin" : "https://example.com"} ] } This allows sites that control multiple subdomains and top level domains to be presented as a single web app. Requires listed origins to confirm association with the web app using a .well-known/web-app-origin-association configuration file. { "https://sample-app.com/": { "scope": "/" } } #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1-idhx8heajbPYl3cdXFVCjpIuf96cRa_DrRk6147ELI/edit?usp=sharing
Samples: https://main-pwa-origin-2.glitch.me
Chrome 124 enabled by default on all desktop platforms a new post-quantum secure TLS key encapsulation mechanism [X25519Kyber768](https://developer.chrome.com/blog/chrome-124-beta#x25519kyber768_key_encapsulation_for_tls), based on a NIST standard (ML-KEM). This protects network traffic from Chrome with servers that also support ML-KEM from decryption by a future quantum computer. This change should be transparent to server operators. This cipher will be used for both [TLS 1.3](https://datatracker.ietf.org/doc/html/rfc8446) and [QUIC](https://datatracker.ietf.org/doc/rfc9000/) connections. However, some TLS middleboxes might be unprepared for the size of a Kyber (ML-KEM) key encapsulation, or a new TLS ClientHello cipher code point, leading to dropped or hanging connections. This can be resolved by updating your middlebox, or disabling the key encapsulation mechanism via the temporary [PostQuantumKeyAgreementEnabled](https://chromeenterprise.google/policies/#PostQuantumKeyAgreementEnabled) enterprise policy, which will be available through Chrome 145. However, long term, post-quantum secure ciphers will be required in TLS and the enterprise policy will be removed in Chrome 147. Post-quantum cryptography is required for CSNA 2.0. To learn more, see [Protect Chrome Traffic with Hybrid Kyper KEM](https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html). #
This feature was specified in this Spec.
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 1 features deprecated.
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
This release of Chrome had 0 features removed.