Chrome version: 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 10 new features.
The existing Save-Data header will be made a formal client hint by adding a new CH-Save-Data permissions policy that controls its delegation. This hint will still be sent by default (when lite mode is on) and delegated to all first and third parties by default. #
This feature was specified in this Spec.
AudioContext.outputLatency property is the estimation in seconds of audio output latency. Technically, this is the interval between the time the UA requests the host system to play a buffer and the time at which the first sample in the buffer is actually processed by the audio output device. For devices such as speakers or headphones that produce an acoustic signal, this latter time refers to the time when a sample’s sound is produced. #
This feature was specified in this Spec.
We introduce a mechanism that allows an application to opt-in to exposing certain information to other applications which are video-capturing it. This allows collaboration between capturing and captured applications. For example, a VC application that's video-capturing a tab where a presentation application lives, could expose user-facing controls in the VC tab for navigating the presentation in the captured tab. #
This feature was specified in this Spec.
Samples: https://w3c.github.io/mediacapture-handle/identity/demos/remote_control/capturer.htmlhttps://w3c.github.io/mediacapture-handle//identity/demos/self_capture_detection/index.html
File Handling provides a way for web applications to declare the ability to handle files with given MIME types and extensions. The web application will receive an event when the user intends to open a file with that web application. #
This feature was specified in this Spec.
Docs: https://tinyurl.com/file-handling-design
Samples: https://principled-ring-yarrow.glitch.me
Query DNS for HTTPS records (alongside traditional A and AAAA queries). When a website has deployed an HTTPS DNS record and Chrome receives it, Chrome will always connect to the website via HTTPS. Design doc for all Chrome DNS HTTPS plans: https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ This feature covers just the basic query and HTTP->HTTPS upgrade part of those plans, and only for simpler cases that do not require followup DNS queries by the Chrome DNS stack. #
This feature was specified in this Spec.
The window.navigation API provides the ability to intercept and initiate navigations, as well as introspect an application's history entries. This provides a more useful alternative to window.history and window.location, specifically aimed at the needs of single-page web applications. (Note: this API was formerly known as the app history API.) #
This feature was specified in this Spec.
Docs: https://developer.chrome.com/docs/web-platform/navigation-api
Samples: https://gigantic-honored-octagon.glitch.me/https://selective-heliotrope-dumpling.glitch.me/
Three changes to the Secure Payment Confirmation API, implemented and flagged as “V3” of the API. - Add Relying Party ID as a required input (https://github.com/w3c/secure-payment-confirmation/issues/164). This is a breaking change, see compatibility section. - Add an optional boolean to allow failed instrument icon download (https://github.com/w3c/secure-payment-confirmation/issues/125) - Add payeeName as an optional input (https://github.com/w3c/secure-payment-confirmation/issues/163) #
This feature was specified in this Spec.
With WebAssembly Dynamic Tiering, an heuristic decides which functions of a WebAssembly module get optimized, and when the optimization is triggered. This is an improvement to the existing eager optimization approach, where all functions get optimized immediately after baseline compilation is finished. WebAssembly Dynamic Tiering reduces the resource consumption of the optimizing compiler, and prevents the compiler from competing with the web application for resources. #
This feature was specified in this Spec.
The "exclusionFilters" option in navigator.hid.requestDevice() allows web developers to exclude some devices from the browser picker. It can be used to exclude devices that are known to be malfunctioning. #
This feature was specified in this Spec.
The inert attribute allows web authors to mark parts of the DOM tree as inert. When a node is inert: - Hit-testing must act as if the 'pointer-events' CSS property were set to 'none'. - Text selection functionality must act as if the 'user-select' CSS property were set to 'none'. - If it is editable, the node behaves as if it were non-editable. - The user agent may ignore the node for the purposes of find-in-page. (also aboxhall@) #
This feature was specified in this Spec.
Docs: https://github.com/WICG/inert#tldrhttps://discourse.wicg.io/t/inert-attribute/1838/https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement
Samples: https://wicg.github.io/inert/demo/
This release of Chrome had 0 new origin trials.
This release of Chrome had 0 are available behind a flag.
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 SDP used to establish a connection in WebRTC has a non-standard dialect: Plan B. Removal timeline: M93: Exception thrown in Canary. M96: Exception thrown in Beta and Stable. M102: Prior to this version, Plan B was allowed behind Deprecation Trial. With M102, sdpSemantics is ignored (you get Unified Plan no matter what). CrOS-only: Plan B was temporarily allowed up until M104. #
This feature was specified in this Spec.
This release of Chrome had 1 features removed.
Allowing PaymentRequest.show() to be triggered without a user activation could be abused by malicious websites. To protect users, the spec was changed to require user activation, and we are now following through in the Chrome implementation. #
This feature was specified in this Spec.