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 11 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.
This feature extends the existing hidden attribute with a new value, "until-found", which makes the element searchable by find-in-page, scroll to text fragment, and fragment navigation. When these search/navigation features want to scroll to something inside a hidden=until-found element, the browser removes the hidden attribute from the element and fires the "beforematch" event on it so that the newly revealed content can be scrolled into view. #
This feature was specified in this Spec.
Docs: https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.md
No linked samplesThe 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. #
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 2 new origin trials.
Extend the getDisplayMedia() API by adding a CaptureController object which can be passed in as a parameter. This object exposes a setFocusBehavior() method. By calling this method, an app can control whether the captured tab/window is focused when capture starts, or whether the capturing page should retain focus. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1LHJRt-ry9hwzFTbPxKrmD0VvtEFEU6lvqsD7k6wwGKM
Samples: https://wicg.github.io/conditional-focus/demo
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.
This release of Chrome had 3 are available behind a flag.
Allows putting 'blocking=render' as an attribute and value to a <script>, <style> or stylesheet <link> to make it explicitly render-blocking. The main usage is to avoid a flash of unstyled content or user interactions with an unmature page caused by, e.g., script-inserted scripts/stylesheets, client-side A/B testing and etc. #
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.1 of ORB - Chrome's first step toward full ORB implementation. For interop web authors should check Content-Type headers of their resources and indicate multimedia content when needed (e.g. audio/*, application/dash+xml, etc). #
This feature was specified in this Spec.
Fullscreen Companion Window allows sites to place fullscreen content and a popup window on separate screens from a single user activation. This is a small requested enhancement of the Window Management feature: https://chromestatus.com/feature/5252960583942144 #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1RRlGQharWVnmxKTomfKhNiaeE31L7iXHeXVfifOvwJA
Samples: https://michaelwasserman.github.io/window-placement-demo
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.