Chrome version: 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 0 new features.
This release of Chrome had 2 new origin trials.
This feature captures the JS call stack when a web page becomes unresponsive due to JavaScript code running an infinite loop or other very long computation. This helps developers to identify the cause of the unresponsiveness and fix it more easily. The JS call stack is included in the crash reporting API when the reason is unresponsive. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing
No linked samplesJavaScript Promise Integration (JSPI) is an API that allows WebAssembly applications to integrate with JavaScript Promises. It allows a WebAssembly program to act as the generator of a Promise, and it allows the WebAssembly program to interact with Promise-bearing APIs. In particular, when an application uses JSPI to call a Promise-bearing (JavaScript) API, the WebAssembly code is suspended; and the original caller to the WebAssembly program is given a Promise that will be fulfilled when the WebAssembly program finally completes. JSPI is described in more detail in https://github.com/WebAssembly/js-promise-integration which is part of the W3C WebAssembly standards track. See also https://github.com/WebAssembly/stack-switching and https://github.com/WebAssembly/meetings/tree/main/stack. #
This feature was specified in this Spec.
This release of Chrome had 11 are available behind a flag.
Correct the error type thrown during WebAuthn credential creation for 'payment' credentials. Due to a historic specification mismatch, creating a 'payment' credential in a cross-origin iframe without a user activation would throw a SecurityError instead of a NotAllowedError, which is what is thrown for non-payment credentials. This is a breaking change, albeit a niche one. Code that previously detected the type of error thrown (e.g., `e instanceof SecurityError`) would be affected. Code that just generally handles errors during credential creation (e.g. `catch (e)`) will continue to function correctly. #
This feature was specified in this Spec.
As a continuation of Storage Partitioning, Chromium will implement partitioning of Blob URL access by Storage Key (top-level site, frame origin, and the has-cross-site-ancestor boolean), with the exception of top-level navigations which will remain partitioned only by frame origin. This behavior is similar to what’s currently implemented by both Firefox and Safari, and aligns Blob URL usage with the partitioning scheme used by other storage APIs as part of Storage Partitioning. In addition, Chromium will enforce noopener on renderer-initiated top-level navigations to Blob URLs where the corresponding site is cross-site to the top-level site performing the navigation. This aligns Chromium with similar behavior in Safari, and the relevant specs have been updated to reflect these changes. This change can be temporarily reverted by setting the PartitionedBlobURLUsage policy. The policy will be deprecated when the other storage partitioning related enterprise policies are deprecated. #
This feature was specified in this Spec.
A keyword for CSS sizing properties (e.g. 'width', 'height') that allows elements to grow to exactly fill their containing block's available space. It is similar to '100%', except the resulting size is applied to the element's margin box instead of the box indicated by 'box-sizing'. Using this keyword allows the element to keep its margins while still being as large as possible. An unprefixed version of '-webkit-fill-available'. #
This feature was specified in this Spec.
The reading-flow CSS property controls the order in which elements in a flex, grid or block layout are exposed to accessibility tools and focused via TAB keyboard focus navigation. This change implements the CSS reading-flow keyword values: * normal * flex-visual * flex-flow * grid-rows * grid-columns * grid-order * source-order See spec: https://drafts.csswg.org/css-display-4/#reading-flow The reading-order CSS property allows authors to manually-override the order within a reading flow container. It is an integer with default value 0. See spec: https://drafts.csswg.org/css-display-4/#reading-order Please find more thorough examples of how TAB keyboard navigation and accessibility is improved by this feature here: https://chrome.dev/reading-flow-examples/ #
This feature was specified in this Spec.
Samples: https://chrome.dev/reading-flow-examples
This feature adds support for Curve25519 algorithms in the Web Cryptography API, namely the signature algorithm Ed25519 #
This feature was specified in this Spec.
Docs: https://github.com/WICG/webcrypto-secure-curves/blob/main/explainer.mdhttps://docs.google.com/document/d/1fDTUY3HVAXehi-eSfbi7nxh8ZPw4MpSKM8U1fMdqJlU/edit?usp=sharing
No linked samplesThis feature adds logic to ignore the letter-spacing setting for cursive scripts as specified by the web author, in line with the spec, to ensure that letter spacing does not disrupt word structure and aims to produce better user experience for users relying on cursive scripts. The spec suggests that the UA may apply letter spacing to cursive scripts by translating the total extra space into cursive elongation or compression. Otherwise, if the UA cannot expand text from a cursive script without breaking its cursive connections, it must not apply spacing between any pair of that script’s typographic letter units at all. Ignoring letter spacing altogether for cursive scripts is simpler and helps avoid performance issues as handling spacing for such scripts requires complex calculations to maintain cursive connections and account for script-specific factors like elongation glyphs, typefaces, and calligraphy preferences. With this feature, Chromium ensures that cursive scripts will be readable and properly spaced, even if the fonts don’t have advanced typographic features. The scripts that we are proposing to apply this to in Chromium are Arabic, Hanifi Rohingya, Mandaic, Mongolian, N’Ko, Phags Pa, and Syriac as these scripts are considered cursive as per spec. #
This feature was specified in this Spec.
A JavaScript API for detecting the language of text, with confidence levels. #
This feature was specified in this Spec.
This feature adds on-device speech recognition support to the Web Speech API, allowing websites to ensure that neither audio nor transcribed speech are sent to a third-party service for processing. Websites can query the availability of on-device speech recognition for specific languages, prompt users to install the necessary resources for on-device speech recognition, and choose between on-device or cloud-based speech recognition as needed. #
This feature was specified in this Spec.
This feature ships two new API methods for the Selection API: * Selection.direction which returns the selection's direction as either "none", "forward" or "backward" * Selection.getComposedRanges() which returns a list of 0 or 1 “composed” StaticRange A “composed” StaticRange is allowed to cross shadow boundaries, which normal Ranges cannot. For example: const range = getSelection().getComposedRanges({ shadowRoots: [root] }); If the selection crosses a shadow root boundary that isn’t provided in the shadowRots list, then the StaticRange's endpoints will be “rescoped” to be outside that tree. This makes sure we do not expose unknown shadow trees. #
This feature was specified in this Spec.
This feature empowers web developers to enhance the visual appeal of their websites by leveraging the operating system's accent color for form elements. By utilizing the "accent-color" CSS property, developers can ensure that form elements such as checkboxes, radio buttons, and progress bars automatically adopt the accent color defined by the user's operating system. This feature is an enhancement to existing feature that is already shipped in Chromium: https://groups.google.com/a/chromium.org/g/blink-dev/c/WwYkLjbGhoA #
This feature was specified in this Spec.
Improves the performance of compiled WebAssembly code by informing the engine that a particular branch instruction is very likely to take a specific path. This allows the engine to make better decisions for code layout (improving instruction cache hits) and register allocation. https://github.com/WebAssembly/branch-hinting/blob/main/proposals/branch-hinting/Overview.md #
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 0 features deprecated.
This release of Chrome had 0 features removed.