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 10 new features.
AbortSignal.any(signals) returns a signal that is aborted when any of the source signals are aborted. Developers can use this to combine independent abort sources, e.g. timeouts specified with AbortSignal.timeout() and signals associated with user input, and pass them to async APIs like fetch(). #
This feature was specified in this Spec.
Makes Response.body be a readable byte stream instead of a "default" readable stream. This enables it to be used with bring-your-own-buffer (BYOB) readers, reducing garbage collection overhead and copies. #
This feature was specified in this Spec.
This feature mitigates bounce tracking on the web. It works by deleting state from sites that access storage during a redirect that the user has never directly interacted with. See the specification for more details. #
This feature was specified in this Spec.
Docs: https://developer.chrome.com/docs/privacy-sandbox/bounce-tracking-mitigationshttps://developer.chrome.com/blog/bounce-tracking-mitigations-dev-trial
Samples: https://bounce-tracking-demo.glitch.me
Motion path allows authors to position any graphical object and animate it along an author specified path. This allows a number of powerful new transform possibilities, such as positioning using polar coordinates (with the ray() function) rather than the standard rectangular coordinates used by the translate() function, or animating an element along a defined path, making it easy to define complex and beautiful 2d spatial transitions. Path can be specified as circle(), ellipse(), rect(), inset(), xywh(), polygon(), ray() and url(). With path() being already implemented before. #
This feature was specified in this Spec.
Document Picture-in-Picture adds a new API to open an always-on-top window that can be populated with arbitrary HTMLElements. This is an expansion upon the existing HTMLVideoElement API that only allows for an HTMLVideoElement to be put into a PiP window. This allows web developers to provide a better PiP experience to users. #
This feature was specified in this Spec.
Subdomain wildcards in allowlists provided some valuable flexibility, but differed from existing wildcard parsers and required novel code and spec work. This intent will reduce that overhead by reusing parts of the existing Content Security Policy spec and permitting ‘scheme + wildcard domain’ and ‘wildcard port’ in the allowlist. Specifically, this intent would adopt the definition of host-source and scheme-source instead of origin in the Allowlist definition while requiring that the path-part is empty (as Permissions Policies apply to matching origins). #
This feature was specified in this Spec.
Allows customizations to federated login flows that use FedCM. With LoginHint, the RP can specify a hint about the user account they want displayed in the FedCM UI. Accounts which do not match the hint are not displayed. This is mainly used to provide a better UX for returning users. The UserInfo extension allows the IDP to personalize the login experience for returning users, for instance via personalized buttons. After the user has used FedCM with a given IDP on some RP site, this API provides some information about the user accounts to the IDP on subsequent visits to the RP. With the context parameter, the IDP can request for the FedCM dialog to show a different title than “Sign in”, to improve the message being displayed to the user in the FedCM UI. #
This feature was specified in this Spec.
Make the event.composed property in mouseenter, mouseleave, pointerenter and pointerleave events "false" to be spec compliant and to fix interop gaps. Both the UI Events spec for Mouse Events and the Pointer Events spec define these events as non-composed. Both specs switched away from their original definitions few years ago: https://github.com/w3c/uievents/pull/210 https://github.com/w3c/pointerevents/pull/461 In addition to addressing the interop gap, this change also fixes an erroneous double/triple dispatch of these events to a shadow DOM host in Chromium when the shadow DOM also listens to the event (https://crbug.com/1136584). #
This feature was specified in this Spec.
Docs: https://w3c.github.io/pointerevents/#attributes-and-default-actions
Samples: https://codepen.io/mustaqahmed/pen/XWYZdYp
Sandbox flags of the caller are currently applied to the callee when document.open targets a different window. Stop doing it. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1_89X4cNUab-PZE0iBDTKIftaQZsFbk7SbFmHbqY54os/edit
No linked samplesWebsites can indicate that a particular Client Hint is critical to the page by including it in a `Critical-CH` HTTP response header. Doing so will trigger a connection restart if the hint listed in the `Critical-CH` HTTP response header could be (but wasn’t) included in the HTTP request initially sent. This intent proposes adding `readonly attribute DOMHighResTimeStamp criticalCHRestart;` to the `PerformanceNavigationTiming` interface. #
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.
Support specifying display and content-visibility in animations. This support allows for developers to create exit animations after which the element automatically becomes display: none or content-visibility: hidden without needing to write any javascript to handle that switch after the animation is finished. This allows exit animations for elements to be added purely in CSS. #
This feature was specified in this Spec.
Samples: https://output.jsbin.com/buquher
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.