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 25 new features.
Array.fromAsync is the async version of Array.from. It takes async iterables, iterates them, and collects the results into an array. #
This feature was specified in this Spec.
The CSS Scrollbars spec allows authors to style scrollbars by specifying their colors and thickness. This spec adds the following two properties. The scrollbar-color property provides the capability of changing the color scheme of scrollbars so they fit better into the particular style of a web page. The scrollbar-width property allows the use of narrower scrollbars that may be more suitable for some use cases, or even to hide the scrollbars completely without affecting scrollability. #
This feature was specified in this Spec.
Samples: https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-colorhttps://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-width
The CSS `font-palette` property allows selection of a specific palette used to render a color font. With the newly added support for animating this property, transitioning between palettes is no longer a discrete step, but becomes a smooth transition between two selected palettes. This works everywhere in CSS animations and transitions. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1XMTrKH003KBOes6hxzI-3E7LTwp5YwFC-rnzoFpFrfw/edit?usp=sharing
Samples: https://drafts.csswg.org/css-fonts-4/images/nabla-animated.webp
CSS highlight pseudo-elements for styling text that the UA has flagged as misspelled or grammatically incorrect, and line decorations exposing the UA’s default decorations for spelling and grammar errors. These features allow authors to choose more legible colors for the default spelling and grammar errors, highlight misspelled words with background colors or other decorations, and implement custom spell checking with native appearance. #
This feature was specified in this Spec.
Samples: https://bucket.daz.cat/work/igalia/0/1.html
This enables the resizeBy() and resizeTo() Windows methods on document picture-in-picture windows, but with the added restriction of a user gesture requirement to mitigate the abuse potential #
This feature was specified in this Spec.
Samples: https://steimelchrome.github.io/document-pip/click_to_resize.html
The EditContext API simplifies the process of integrating a web app with advanced text input methods such as VK shape-writing, Handwriting panels, speech recognition, IME Compositions etc., improves accessibility and performance, and unlocks new capabilities for web-based editors. #
This feature was specified in this Spec.
Docs: https://w3c.github.io/edit-contexthttps://github.com/w3c/edit-context/blob/gh-pages/explainer.mdhttps://github.com/w3c/edit-context/blob/gh-pages/dev-design.md
No linked samplesCurrently during async clipboard write operation, there is no way for the web authors to detect if a particular mime type is supported by the UAs or not before attempting to actually write the formats to the clipboard. This not only affects developer ergonomics as now web authors have to attempt to write to the clipboard first in order to find out whether write failed due to a particular mime type not supported by the UAs (or sometimes add version checks that are unreliable at best), but also leads to unnecessary cost in terms of CPU cycles, COGS etc in order to produce an expensive web custom format which may not be supported by a particular browser. #
This feature was specified in this Spec.
Samples: https://lake-cobalt-way.glitch.me
Developers have been asking for a way to programmatically open the option picker of a select element. See https://www.google.com/search?q=programmatically+open+select+site%3Astackoverflow.com This is currently impossible in almost every browser. Providing showPicker() gives developers a supported way to do this. Following the pattern of input.showPicker(). #
This feature was specified in this Spec.
Samples: https://select-show-picker.glitch.me
This is a follow-on to the improved CSS mask support in chromium 120 (https://chromestatus.com/feature/5839739127332864) and adds new mask support to SVG (multiple masks, as well as mask-mode, mask-composite, mask-position, and mask-repeat). In addition, remote SVG masks (e.g., mask: url(masks.svg#star)) are now supported. Explainer: https://docs.google.com/document/d/1IzQv56NzfV1hA6YPr2j1chtb5qijNxykkYY7JyccZgc/edit?usp=sharing #
This feature was specified in this Spec.
Extends the Media Capabilities API to allow detection of HDR rendering support via three new VideoConfiguration dictionary fields: hdrMetadataType, colorGamut, transferFunction. Chromium implements its own tone-mapping algorithms so will always return true for HDR10 (smpteSt2086) static metadata. smpteSt2094-40 (HDR10+) and smpteSt2094-10 dynamic metadata are not currently supported, so will return false. We anticipate adding support for dynamic metadata in the future, so this API will allow developers to select the appropriate content for users with support. #
This feature was specified in this Spec.
Currently, only one FileSystemSyncAccessHandle may be open at a time per file, preventing an origin from reading and writing to the same file from multiple tabs easily. Conversely, multiple FileSystemWritableFileStreams can be simultaneously open, letting multiple writers clobber each other. Introducing new locking modes for FileSystemSyncAccessHandle and FileSystemWritableFileStream allows opening either multiple readers/writers or an exclusive writer to a file entry, depending on the application's use case. #
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.
Enables prefetch to match even if URL query parameters change. The No-Vary-Search HTTP response header declares that some or all parts of a URL's query can be ignored for cache matching purposes. It can declare that the order of query parameter keys should not cause cache misses, that specific query parameters should not cause cache misses or that only certain known query parameters should cause cache misses. It could apply to multiple caches, but this entry refers to support for prefetch cache. #
This feature was specified in this Spec.
Modification to the Private Aggregation API to provide a mechanism for selecting which coordinator to use for payload encryption (from an vendor-specified allowlist). The choice of service is made with an additional option in Shared Storage’s run() and selectURL() calls, and in Protected Audience’s runAdAuction() and joinAdInterestGroup() calls. The broad approach largely aligns with Attribution Reporting’s approach (see https://chromestatus.com/feature/5197591256236032). #
This feature was specified in this Spec.
The Protected Audience API (formerly known as FLEDGE) is a Privacy Sandbox proposal to serve remarketing and custom audience use cases, designed so third parties cannot track user browsing behavior across sites. The k-anonymity enforcement feature enhances user privacy by limiting ads that can win protected audience auctions to those ads that are k-anonymous. Enforcing the k-anonymity requirement improves user privacy and limits the ability of advertisers to target specific users by requiring each ad be shown to a minimum number of users. Details for the timeline for k-anonymity enforcement is in https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity #
This feature was specified in this Spec.
This specification defines an API extending the HTMLMediaElement that enables controlling remote playback of media from a web page. In M56, this will work on Android only (desktop will report no devices available) with the desktop backend being added later. #
This feature was specified in this Spec.
Samples: https://beaufortfrancois.github.io/sandbox/media/remote-playback.htmlhttps://avayvod.github.io/remote-playback/test.html
New CSS display property values, "ruby" and "ruby-text", are added. The default display values of <ruby> and <rt> are changed to "ruby" and "ruby-text" respectively, and ruby layout respects these display values. Web authors can use any elements such as <div> to render ruby by setting the new display values. #
This feature was specified in this Spec.
Currently developers can only specify speculation rules using inline script tags. The proposed feature provides an alternative through the "Speculation-Rules" header. Its value must be a URL to a text resource with "application/speculationrules+json" MIME type. The resource's rules will be added to the document's rule set. #
This feature was specified in this Spec.
An extension to speculation rules syntax that lets the browser obtain URLs for speculation from link elements in a page. They may include criteria which restrict which of these links can be used. #
This feature was specified in this Spec.
To make the web user experience more instant, the user agent (UA) could pre-connect to the server, prefetch resources, or prerender them ahead of time. These actions are referred to as preloading actions. Since performing any preloading action may cause side effects (e.g. log the user out) and has an overhead (e.g. extra data/cpu usage), to perform the action the UA should know if the action is safe to perform and also if it is worth performing. Being able to consistently determine which actions are safe for a given target without feedback from the developer is not an easy task. Speculation rules expose the necessary API to let developers specify that. Adding the eagerness field to the speculation rules will let the developers control how eagerly the browser preloads links in order to balance the performance advantage against resource overhead. This field accepts one of "conservative", "moderate" or "eager" strings as the value, and it is applicable to both "prefetch" and "prerender" actions and both "list" or "document" sources. If not explicitly specified, list rules default to "eager" and document rules default to "conservative". #
This feature was specified in this Spec.
This is about the interface objects for SpeechSynthesis and SpeechSynthesisVoice, not about the functionality itself which was already supported. These interfaces should be exposed according to spec. Feature detection using window.speechSynthesis was already possible, but this makes feature detection using SpeechSynthesisVoice.prototype possible. Note that SpeechSynthesisEvent, SpeechSynthesisErrorEvent and SpeechSynthesisUtterance interface objects were already exposed. #
This feature was specified in this Spec.
Samples: https://developer.mozilla.org/en-US/docs/Web/API/SpeechSynthesishttps://developer.mozilla.org/en-US/docs/Web/API/SpeechSynthesisVoice
Behavior changes to patterns which are constructed using a base URL, the constructor string syntax, or both -- but not any pattern which explicitly specifies components separately without a base URL. * Components are not inherited from a base URL if an "earlier" component is explicitly specified. * In the string format, unspecified "later" components are implicitly wildcarded, rather than required to be empty (with the exception of the port, which is always taken to be specified when the hostname is). * Username and password are never implicitly specified or inherited. This makes patterns more expansive than before, in cases where wildcards are likely to be desirable. See https://github.com/whatwg/urlpattern/pull/198. #
This feature was specified in this Spec.
The URL Pattern API allows developers to specify pattern strings. Those are transformed to regular expressions internally. When the API was first implemented, these regular expressions were compiled with the u flag. We're going to update it to the v flag, enabling Unicode sets. #
This feature was specified in this Spec.
WebGPU now allows developers to omit entry points to shader modules when creating a pipeline, improving ergonomics. If no default entry point is found, a GPUValidationError will be triggered as usual. #
This feature was specified in this Spec.
WebGPU timestamp queries allow WebGPU applications to measure precisely (down to the nanosecond) how much time their GPU commands take to execute, especially at the beginning and end of passes. Timestamp queries are heavily used to gain insights into the performance and behavior of GPU workloads. While the WebGPU specification makes timestamp queries an optional feature due to timing attack concerns, we believe that timestamp queries quantization provides a good middle ground by reducing the precision of timers with a resolution of 100 microseconds. #
This feature was specified in this Spec.
This release of Chrome had 0 new origin trials.
This release of Chrome had 1 are available behind a flag.
This is about adding support in Chrome for the VoiceIsolation getUserMedia constraint (https://w3c.github.io/mediacapture-extensions/#voiceisolation-constraint). The constraint only takes effect on platforms where there is low-level support for voice-isolation style denoising. Currently this is limited to a selected number of ChromeOS devices, but further platforms will be added. #
This feature was specified in this Spec.
Samples: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-streams/MediaStreamTrack-getSettings.https.htmlhttps://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-streams/MediaStreamTrack-getCapabilities.https.htmlhttps://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-streams/MediaDevices-getSupportedConstraints.https.htmlhttps://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-streams/GUM-non-applicable-constraint.https.html
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.
