Unless otherwise noted, the following changes apply to the newest Chrome beta channel release for Android, ChromeOS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 125 is beta as of April 17, 2024. You can download the latest on [Google.com](https://www.google.com/chrome/beta/) for desktop or on Google Play Store on Android. Once released to stable, all included features can be found in the [release notes](https://developer.chrome.com/release-notes). ## CSS This release adds two new CSS features and makes two CSS-related changes. ### CSS Anchor Positioning CSS anchor positioning lets developers *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. A few of the key properties are as follows: - `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. ### CSS stepped value functions---`round()`, `mod()`, and `rem()` The stepped-value functions, [`round()`](https://developer.mozilla.org/docs/Web/CSS/round), [`mod()`](https://developer.mozilla.org/docs/Web/CSS/mod), and [`rem()`](https://developer.mozilla.org/docs/Web/CSS/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. ### Remove discontinuity for Oklab and Oklch colors with lightness of nearly 100% or 0 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 unexpected to web developers. With this rollback, these colors are no longer mapped artificially and the resulting displayed color will be continuous with nearby colors and depend on the gamut mapping of the display. ### Used color scheme root scrollbars 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 [`color-scheme`](https://www.w3.org/TR/css-color-adjust-1/#color-scheme-prop) 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 the developer has not explicitly specified support for color schemes. This change does not prevent developers from controlling the color scheme for scrollbars. The new behavior makes the browser use the user's preferred color-scheme to render viewport non-overlay scrollbars only if the developer hasn't specified the color scheme for the root element. ## HTML ### Keyboard-focusable scroll containers Improves accessibility by making scroll containers focusable using sequential focus navigation. Prior to this change, 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 is an ongoing rollout that started in Chrome 124, and should be available to all users from Chrome 125. Learn more about [keyboard focusable scrollers](https://developer.chrome.com/blog/keyboard-focusable-scrollers). ### Declarative shadow DOM serialization A feature to let developers serialize DOM trees containing shadow roots, recently standardized in the HTML standard. ## Web APIs ### Additions to the Attribution Reporting API Features have been added to the Attribution Reporting API to create additional debugging capabilities by supporting parsing failure debug reports, improve API ergonomics by supporting a field to specify preferred registration platform, and improve privacy. ### The Compute Pressure API The [Compute Pressure API](https://developer.chrome.com/docs/web-platform/compute-pressure.md.txt) offers high-level states that represent the CPU load 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. Intel led the design and implementation work for this API, which will let video conferencing apps dynamically balance features and performance. ### Accept HTTP(S) URLs when constructing WebSocket This update enables HTTP(s) schemes in the WebSocket constructor, therefore also letting developers use relative URLs. These are normalized to the `ws:` and `wss:` internal schemes. ### Extending Storage Access API (SAA) to non-cookie storage This launches the proposed extension of the Storage Access API (backwards compatible and has been in origin trial) 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. ### FedCM CORS requirement on ID assertion endpoint The fetches in the FedCM API are hard to reason about because of the properties required of them. While there is ongoing discussion regarding the accounts endpoint, there is also largely consensus that the ID assertion endpoint should use CORS. This update aligns security properties of this fetch more closely to other fetches in the web platform. Learn more about how CORS requirement works in [FedCM updates: Button Mode API origin trial, CORS and SameSite](https://developers.google.com/privacy-sandbox/blog/fedcm-chrome-125-updates#cors-and-samesite). ### Interoperable mousemove default action Chrome allowed canceling 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. Now text selection will no longer be the default action of mousemove. Text selection and drag-and-drop can still be prevented through canceling `selectstart` and `dragstart` events respectively. ### Updates to the Shared Storage API This update adds support for running cross origin worklets without having to create an iframe. ## Chrome Apps ### Direct Sockets API in Chrome Apps This update helps ease the transition of specialized apps from Chrome Apps to Isolated Web Apps by enabling Direct Sockets in Chrome Apps, letting web apps establish direct transmission control protocol (TCP) and user datagram protocol (UDP) communications with network devices and systems. ## New origin trials From Chrome 125 you can opt into the following new [origin trials](https://developer.chrome.com/docs/web-platform/origin-trials). ### FedCM Button Mode API and Use Other Account API This origin trial includes the following two FedCM APIs. The Button Mode API lets websites call FedCM inside a button click, such as clicking on a **Sign-in to IdP** button. This requires FedCM to guarantee it always responds with a visible user interface, as opposed to widget mode, which doesn't show a UI when users log out. Calling the FedCM API in *button mode* takes users to login to the IdP (in a dialog window), when users are logged-out. Also, because the button mode is called within an explicit user gesture, the UI may also be more prominent (for example, centered and modal) compared to the UI from the widget mode (which doesn't have such explicit intention). Learn more about how the Button Mode API works in [FedCM updates: Button Mode API origin trial, CORS and SameSite](https://developers.google.com/privacy-sandbox/blog/fedcm-chrome-125-updates#button-mode-api) The Use Other Account API lets an Identity Provider allow users to sign in to other accounts. [Register for the FedCM origin trial](https://developer.chrome.com/origintrials#/view_trial/3196429835526209537). ### Foldable APIs This origin trial includes the Device Posture API and Viewport Segments Enumeration API. These APIs are designed to help developers target foldable devices. Learn more in [Origin trial for Foldable APIs](https://developer.chrome.com/blog/foldable-apis-ot.md.txt). [Register for the Foldable APIs origin trial](https://developer.chrome.com/origintrials#/view_trial/4188910603407982593). ### Media Previews opt-out This reverse origin trial will exclude sites from the launch of Media Previews. Chrome intends to provide real-time previews of camera and microphone input at the time camera and microphone permissions are requested by websites. These will also be available from the site's pageinfo. In addition, users with multiple devices will be able to select a camera and microphone at the time permissions are requested, unless the site has requested a specific device through `getUserMedia()`. This feature is in concurrent development with another permissions-related project, Page-Embedded Permissions Controls (PEPC). Users will be exposed to PEPC under an independent launch process involving a separate origin trial or site-specific experiments. ### Deprecation trial for prefixed HTMLVideoElement Fullscreen properties and methods This deprecation trial lets you opt back into support for the prefixed HTMLVideoElement properties and methods if you need more time to adjust your code. See full details of the removed properties and methods under [Deprecations and removals](https://developer.chrome.com/blog/chrome-125-beta#deprecations-and-removals). [Register for the Prefixed Video fullscreen API deprecation trial](https://developer.chrome.com/origintrials#/register_trial/300896750103691264). ### Skip preload scanning Skips the [preload scanner](https://web.dev/articles/preload-scanner) to explore performance tradeoffs for pages with no sub-resource fetches. The preload scanner step benefits performance of pages with sub-resource fetches, through implementation of the speculative prefetch. However, for pages that don't benefit from this step, that is, for pages with no sub-resources, this is additional processing overhead with little benefit. For advanced web users who would like to benefit by reducing this overhead, this experiment provides a page-level control to disable the preload scanner. Data collected from this experiment could evaluate if a modified API or a different implementation of the HTML preload scanner would be helpful. [Register for the skip preload scanning origin trial](https://developer.chrome.com/origintrials#/register_trial/225742931321946113). ## Deprecations and removals Visit [ChromeStatus.com](https://ChromeStatus.com) for lists of planned deprecations, current deprecations and previous removals. This release of Chrome removes the following three features. ### Remove "window-placement" alias for permission and permission policy "window-management" Removes the "window-placement" alias for permission and permission policy "window-management". This is part of a larger effort to rename the strings by eventually [deprecating and removing "window-placement"](https://developer.chrome.com/docs/capabilities/web-apis/window-management#the_window-management_permission). The terminology change improves the longevity of the descriptor as the Window Management API evolves over time. ### Removal of Enterprise policy: NewBaseUrlInheritanceBehaviorAllowed The underlying code change (enable new base URL inheritance behavior) that this enterprise policy overrides has been enabled in stable releases since August 2023 (118.0.5966.0). Since known issues have been dealt with, this enterprise policy will be removed in Chrome 125. ### Removal of prefixed HTMLVideoElement Fullscreen properties and methods The prefixed `HTMLVideoElement` fullscreen APIs have been deprecated since Chrome 38. They were replaced by `Element.requestFullscreen()`, which first shipped un-prefixed in 2018 in Chrome 71. The following properties and methods will be removed from HTMLVideoElement: - `webkitSupportsFullscreen` - `webkitDisplayingFullscreen` - `webkitEnterFullscreen()` - `webkitExitFullscreen()` - `webkitEnterFullScreen()` (note the different capitalization of the "S" in FullScreen) - `webkitExitFullScreen()` Register for the deprecation trial listed in this post, if your site still relies on these and you need more time for updating code.