Chrome version: 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 13 new features.
These URLs are interpreted relative to the base URL and translated to corresponding WS(S) URLs, which enables use of relative URLs. #
This feature was specified in this Spec.
The stepped-value functions, round(), mod(), and rem(), all transform a given value according to another "step value". The round() CSS function returns a rounded number based on a selected rounding strategy. The mod() CSS function returns a modulus left over when the first parameter is divided by the second parameter, similar to the JavaScript remainder operator (%). The modulus is the value left over when one operand, the dividend, is divided by a second operand, the divisor. It always takes the sign of the divisor. The rem() CSS function returns a remainder left over when the first parameter is divided by the second parameter, similar to the JavaScript remainder operator (%). The remainder is the value left over when one operand, the dividend, is divided by a second operand, the divisor. It always takes the sign of the dividend. #
This feature was specified in this Spec.
This feature introduces a new CSS property view-transition-class which allows the developer to specify one or more view transition classes. The developer can then select the ViewTransition pseudo elements using these classes (e.g. ::view-transition-group(*.class)). This is an extension to the ViewTransition API that simplifies styling of view transition pseudo elements in a similar way that CSS classes simplify styling of regular DOM elements. #
This feature was specified in this Spec.
Docs: https://github.com/vmpstr/web-proposals/blob/main/explainers/view-transition-classes.md
No linked samplesAllows web apps to establish direct transmission control protocol (TCP) and user datagram protocol (UDP) communications with network devices and systems. This API is supposed to provide a modern alternative to the deprecated chrome.sockets APIs. #
This feature was specified in this Spec.
This launches the proposed extension of the Storage Access API (backwards compatible and currently in OT) to allow access to unpartitioned cookie and non-cookie storage in a third-party context. The current API only provides access to cookies, which have different use-cases than non-cookie storage (discussed more in the Motivation section). The API can be used as follows (JS running in an embedded iframe): // Request a new storage handle via rSA (this may prompt the user) let handle = await document.requestStorageAccess({all: true}); // Write some 1P context sessionstorage handle.sessionStorage.setItem("userid", "1234"); // Write some 1P context localstorage handle.localStorage.setItem("preference", "A"); // Open or create an indexedDB that is shared with the 1P context let messageDB = handle.indexedDB.open("messages"); // Use locks shared with the 1P context await handle.locks.request(“example”, …); The same flow would be used by iframes to get a storage handle when their top-level ancestor successfully called requestStorageAccessFor, just that in this case the storage-access permission was already granted and thus the requestStorageAccess call would not require a user gesture or show a prompt, allowing for “hidden” iframes accessing storage. #
This feature was specified in this Spec.
The fetches in the FedCM API are hard to reason about because of the properties required of them. After lengthy discussions, it was decided that the ID assertion endpoint should use CORS. This aligns security properties of this fetch more closely to other fetches in the web platform. #
This feature was specified in this Spec.
Canceling mousemove will not prevent text selection or drag-and-drop. Chrome allowed cancelling mousemove events to prevent other APIs like text selection (and even drag-and-drop in the past). This does not match other major browsers; nor does it conform to the UI Event spec: https://w3c.github.io/uievents/#event-type-mousemove Through this feature, text selection will no longer be the default-action of mousemove. Text selection and drag-and-drop can still be prevented through cancelling selectstart and dragstart events respectively, which are spec compliant and fully interoperable. #
This feature was specified in this Spec.
Samples: https://codepen.io/mustaqahmed/full/wvNYGEP
https://github.com/tc39/proposal-duplicate-named-capturing-groups #
This feature was specified in this Spec.
RegExp modifiers adds the ability to locally modify the 'i', 'm', and 's' flags inside a pattern. To enable a flag for a subexpression, use `(?X:subexpr)` where X is one of 'i', 'm', or 's'. To disable a flag for a subexpression, use `(-X:subexpr)`. For example, for the case-insensitivity 'i' flag: ``` const re1 = /^[a-z](?-i:[a-z])$/i; re1.test("ab"); // true re1.test("Ab"); // true re1.test("aB"); // false const re2 = /^(?i:[a-z])[a-z]$/; re2.test("ab"); // true re2.test("Ab"); // true re2.test("aB"); // false ``` #
This feature was specified in this Spec.
Before this change, all lab, lch, oklab and oklch colors with a lightness value of 100% were rendered as white, regardless of the other two parameters. All colors in these spaces with a lightness value of 0 were rendered as black. These two mappings caused discontinuities in gradients and were generally surprising to web developers. With this rollback chromium no longer maps these colors artificially and the resulting displayed color will be continuous with nearby colors and will depend on the gamut mapping of the display. See: https://crrev.com/c/5400609 #
This feature was specified in this Spec.
Allows SVG gradients to interpolate in a linear-light sRGB color space. Currently all SVG gradients interpolate in a gamma-encoded sRGB color space. #
This feature was specified in this Spec.
Makes the browser use the user's preferred color scheme to render the viewport scrollbars if the value of "page’s supported color schemes" is 'normal' or not specified, and the computed value of the color-scheme for the root element is 'normal'. Viewport scrollbars can be considered to be outside the web content. Therefore, the user agents should honor the user's preferred color scheme when rendering viewport scrollbars if page authors have not explicitly specified support for color schemes. #
This feature was specified in this Spec.
This feature allows View transition API use to be customized for different types of transitions. Specifically, this adds an ability to add "types" to `startViewTransition` call which will identify the types of the transition. As well, it will match a pseudo-class, called `:active-view-transitions(...)` with a parameter matching the type for the duration of the view transition. Combined these two features provide a way for the author to declare several view transitions once and only trigger one at a time. See example usage in the spec: https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo #
This feature was specified in this Spec.
This release of Chrome had 1 new origin trials.
The Compute Pressure API offers high-level states that represent the pressure on the system. It allows the implementation to use the right underlying hardware metrics to ensure that users can take advantage of all the processing power available to them as long as the system is not under unmanageable stress. “Pressure” is a generic term by design – at the moment it is calculated based on CPU load, but future plans include using signals from temperature and battery status, for example. #
This feature was specified in this Spec.
Docs: https://developer.chrome.com/docs/web-platform/compute-pressure
Samples: https://w3c.github.io/compute-pressure/demo
This release of Chrome had 6 are available behind a flag.
CSS anchor positioning allows authors to "tether" an absolutely positioned element to one or more other elements on the page (the "anchors"), in a declarative way, without the use of Javascript. Anchor positioning works performantly when the anchors are scrollable. A common use case is to position a popover such as a tooltip next to the element that invoked it, or a select menu and its popover options list. Before the anchor positioning feature, these use cases required Javascript to dynamically position the popover, and keep it anchored as the invoking element was scrolled, which is a performance footgun and difficult to get right. With anchor positioning, these use cases can be implemented performantly and declaratively. The anchor positioning feature consists of a large number of CSS properties, which are fully described in the spec (https://drafts.csswg.org/css-anchor-position-1). A few of the key features/properties include: - `anchor-name`: sets up an element to be an anchor for other elements. - `position-anchor`: describes the "default" anchor that an anchored element should use for anchor positioning. - The `anchor()` function: used to refer to the position of the anchor element, in positioning the anchored element. - `inset-area`: a shorthand for positioning, for common relative positions. ...and many more. #
This feature was specified in this Spec.
Samples: https://anchor-tool.com
This is the new syntax for the CSS custom state feature for custom elements. The old syntax, :--foo, is being deprecated and removed. This new syntax, :state(foo), is shipping in WebKit. Deprecation for old syntax: https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE Spec for new syntax: https://github.com/whatwg/html/pull/8467 #
This feature was specified in this Spec.
The prototype implementation (which was shipped in 2020 and then shape-changed in 2023) contained a method called `getInnerHTML()` that could be used to serialize DOM trees containing shadow roots. That part of the prototype was not standardized with the rest of declarative shadow dom, and only recently has it reached spec consensus (https://github.com/whatwg/html/issues/8867). As part of that consensus, the shape of the getInnerHTML API changed. This feature represents the desire to ship the new, agreed-upon shape, which is: - getHTML({serializableShadowRoots:bool, shadowRoots:[roots]}). #
This feature was specified in this Spec.
We recently changed FedCM to send ID assertion requests with CORS (see https://chromestatus.com/feature/5094763339710464). As a side-effect, that change also meant that we no longer send SameSite=Strict cookies to the ID assertion endpoint (we still send SameSite=None). Since it does not make sense to send a different set of cookies to the accounts endpoint and the ID assertion endpoint, this change makes them consistent. Not sending SameSite=Strict cookies is also consistent with requestStorageAccess behavior (https://developers.google.com/privacy-sandbox/3pcd/related-website-sets-integration#cookie_requirements) and cross-site requests in general. #
This feature was specified in this Spec.
Improves accessibility by making scroll containers focusable using sequential focus navigation. Today, the tab key doesn't focus scrollers unless tabIndex is explicitly set to 0 or more. By making scrollers focusable by default, users who can't (or don't want to) use a mouse will be able to focus clipped content using a keyboard's tab and arrow keys. This behavior is enabled only if the scroller does not contain any keyboard focusable children. This logic is necessary so we don't cause regressions for existing focusable elements that might exist within a scroller like a <textarea>. #
This feature was specified in this Spec.
Docs: https://drafts.csswg.org/css-overflow-3/#scroll-containerhttps://html.spec.whatwg.org/multipage/interaction.html#focusable-areahttps://html.spec.whatwg.org/multipage/interaction.html#dom-tabindex
No linked samplesChrome 125 removes the window-placement alias for permission and permission policy descriptors. All instances of window-placement are replaced with window-management, which better describes the related API functionality. This is a follow-up to Window Management API feature enhancements and renaming from "Multi-Screen Window Placement API"; for more details, see https://chromestatus.com/feature/5146352391028736 #
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.