Chrome version: 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 16 new features.
Support for "<string>" syntax component name for registered custom properties. #
This feature was specified in this Spec.
Currently the aggregation key identifier length limit (https://wicg.github.io/attribution-reporting-api/#max-length-per-aggregation-key-identifier) is checked in both source and trigger registrations. As this limit is not for privacy and it's not persisted in the storage, we are removing this limit in trigger registrations. This is consistent with other fields in the trigger registrations, e.g. filters and scopes, whose size is only checked in source registrations, but not trigger registrations. #
This feature was specified in this Spec.
The anchor-scope property allows limiting the visibility of anchor names to a given subtree. #
This feature was specified in this Spec.
With CSS Highlight Inheritance, the CSS Highlight pseudo classes, such as ::selection and ::highlight, inherit their properties through the pseudo highlight chain, rather than the element chain. The result is a more intuitive model for inheritance of properties in highlights. Specifically, "When any supported property is not given a value by the cascade ... its specified value is determined by inheritance from the corresponding highlight pseudo-element of its originating element’s parent element." There are some caveats due to properties not allowed on a highlight pseudo and historical usage: units depending on fonts, container queries, viewports etc. use metrics from the originating element, and all custom property values used in the highlight pseudo are taken from the originating element (inherited through the originating element cascade). (https://drafts.csswg.org/css-pseudo-4/#highlight-cascade) #
This feature was specified in this Spec.
Font-variant-emoji CSS property provides users an easy way to control between colored (emoji-style) and monochromatic (text-style) emoji glyphs presentations. This can be also done by adding an emoji Variation Selector, specifically U+FE0E for text and U+FE0F for emojis, after each emoji codepoint. Using font-variant-emoji CSS property allows web developers to select between emoji style (colored) emoji presentation, text style (monochromatic) emoji presentation and unicode default emoji presentation [0]. This property only affects emojis that are part of a Unicode emoji presentation sequence [1]. [0] https://www.unicode.org/reports/tr51/tr51-25.html#Emoji_Presentation [1] http://www.unicode.org/emoji/charts/emoji-variants.html #
This feature was specified in this Spec.
Samples: https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-emoji
Reconciles the FedCM and Storage Access APIs by making a prior FedCM grant a valid reason to automatically approve a storage access request. When a user grants permission for using their identity with a 3rd party Identity Provider (IdP) on a Relying Party (RP), many IdPs require third-party cookies to function correctly and securely. This proposal aims to satisfy that requirement in a private and secure manner by updating the Storage Access API (SAA) permission checks to not only accept the permission grant that is given by a storage access prompt, but also the permission grant that is given by a FedCM prompt. A key property of this mechanism is limiting the grant to cases explicitly allowed by the RP via the FedCM permissions policy, enforcing a per-frame control for the RP and preventing passive surveillance by the IdP beyond the capabilities that FedCM already grants, as outlined in the Privacy Considerations. #
This feature was specified in this Spec.
Support more CSS styling for the structure of <details> and <summary> elements to allow these elements to be used in more cases where disclosure widgets or accordion widgets are built on the web. In particular, this change removes restrictions that prevented setting the display property on these elements, and adds a ::details-content pseudo-element to style the container for the part that expands and collapses. #
This feature was specified in this Spec.
This change makes the HTML parser allow additional tags in <select> besides <option>, <optgroup>, and <hr>. This change is in support of the customizable <select> feature but is being shipped first because it can be done separately and has some compat risk which I'd like to get feedback on. This feature is gated by the temporary policy (SelectParserRelaxationEnabled). This is a temporary transition period, and the policy will stop working on milestone M136 Customizable select explainer: https://open-ui.org/components/customizableselect/ I did a compat analysis and determined that the vast majority of sites which would see the effects of the parser changes would not have their behavior changed. More details here: https://github.com/whatwg/html/issues/10310 If there are major issues with this change, I will reassess and make adjustments to the parser as needed. #
This feature was specified in this Spec.
Allow relative colors in CSS (using the 'from' keyword) to use 'currentcolor' as a base. This will make it easy for web developers to set complementary colors, based on an element's text color, for that element's borders, shadows, backgrounds, etc. This feature also includes use cases where color functions are nested with a dependency on currentcolor, for example `color-mix(in srgb, rgb(from currentcolor r g b), white))` or `rgb(from rgb(from currentcolor 1 g b) b g r)`. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1568wVjrIRbrU9_O37gPu10cj0CDWRiAc6ZMk9t0JpXs/edit
No linked samplesAllow external references for clip paths, markers, and paint servers (for the 'fill' and 'stroke' properties). For example, clip-path: url("resources.svg#myPath"). #
This feature was specified in this Spec.
Adds the optional GPU feature "clip-distances" that allows setting user-defined clip distances in vertex shader outputs. This technique is particularly useful for the applications that need to clip all vertices in a scene that are beyond a user-defined plane, such as many CAD applications. #
This feature was specified in this Spec.
Functionality added to the WebGPU spec after its first shipment in a browser. Once GPUCanvasContext configure() has been called with a configuration dictionary, the GPUCanvasContext getConfiguration() method lets developers check the canvas context configuration. It includes GPU device, format, usage, viewFormats, colorSpace, toneMapping, and alphaMode members. As discussed in https://github.com/gpuweb/gpuweb/issues/4828, web apps can use it to detect whether HDR canvas is supported in WebGPU. #
This feature was specified in this Spec.
WebHID is enabled inside dedicated worker contexts. This allows developers to perform heavy I/O and processing of data from a HID device on a separate thread to reduce the performance impact on the main thread. #
This feature was specified in this Spec.
Samples: https://webhid-worker.glitch.me
Exposes hand joint data on XrInputSources for use during a WebXr session. This allows developers to have more fine grained interactions during WebXr sessions. #
This feature was specified in this Spec.
Samples: https://immersive-web.github.io/webxr-samples/immersive-hands.html
An API that configures WebRTC encoders to scale input frames if they are greater than the specified maxWidth and maxHeight. This API is similar to scaleResolutionDownBy except that resolution constraints are expressed in absolute terms (e.g. 640x360) as opposed to relative terms (e.g. scale down by 2), avoiding race conditions related to changing input frame size on the fly. #
This feature was specified in this Spec.
Some origins can contain different applications with different levels of security requirements. In those cases, it can be beneficial to prevent scripts running in one application from being able to open and script pages of another same-origin application. In such cases, it can be beneficial for a document to ensure its opener cannot script it, even if the opener document is a same-origin one. The `noopener-allow-popups` Cross-Origin-Opener-Policy value will allow documents to define that. #
This feature was specified in this Spec.
This release of Chrome had 0 new origin trials.
This release of Chrome had 3 are available behind a flag.
Allows Isolated Web Apps to establish direct transmission control protocol (TCP) and user datagram protocol (UDP) communications with network devices and systems as well as listen to and accept incoming connections. #
This feature was specified in this Spec.
Samples: https://github.com/GoogleChromeLabs/telnet-client
Selection isCollapsed should return true if and only if the anchor and focus are the same. This should be true whether the selection starts/ends inside a light or a shadow tree. Currently, the Chrome implementation returns true if selection's anchor node is in a shadow tree, even if the selection itself is not collapsed. We fix this by removing the erroneous shadow tree check. #
This feature was specified in this Spec.
Samples: https://codepen.io/Di-Zhang/pen/jOjdeoX
May show a permission prompt to the user when Keyboard Lock and/or Pointer Lock is requested by a website, and saves the user preferences as content settings. The settings can be queried for via the Permissions API. This helps mitigate the abusive use of the APIs. #
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 2 features removed.
The CSSWG resolved to rename the `inset-area` property to `position-area`. See the CSSWG discussion here: https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001. The new property name, `position-area`, as a synonym for `inset-area` shipped via https://chromestatus.com/feature/6567965055778816. This entry is for deprecation and removal of the `inset-area` property. #
This feature was specified in this Spec.
The WebGPU WG decided it was impractical for requestAdapterInfo() to trigger a permission prompt so they’ve removed that option and replaced it with the GPUAdapter info attribute so that web developers can get the same GPUAdapterInfo value synchronously this time. See the previous Intent to Ship: WebGPU: GPUAdapter info attribute at https://groups.google.com/a/chromium.org/g/blink-dev/c/eZqMmX7q_bA/m/euMLVMpxAgAJ #
This feature was specified in this Spec.