Chrome version: 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 13 new features.
Allow anchor-size() values for inset and margin properties. Originally, anchor-size() was only allowed in sizing properties. The specification was changed to allow anchor-size() in insets and margins as well. #
This feature was specified in this Spec.
It is useful for web authors do determine when their <dialog> elements open and close. popover already has `ToggleEvent` which is dispatched when a popover opens or closes, but <dialog> does not. The current way to detect when a <dialog> opens is to register a mutation observer to check for open, however, this is quite a lot of work where an event would be easier. This change incorporates the same `ToggleEvent`s that popovers dispatch, but for `<dialog>` elements: when `showModal` or `show` is called, <dialog> dispatches a ToggleEvent with newState=open. When a dialog is closed (via form or button or closewatcher) it should dispatch a ToggleEvent with newState=closed. #
This feature was specified in this Spec.
Add a bytes() method to the Request and Response interfaces, which returns a promise that resolves with a Uint8Array. While Request and Response have an arrayBuffer() method, we can't read directly from a buffer. We have to create a view such as a Uint8Array to read it. The bytes() method improves the ergonomics of getting the body of Request and Response. #
This feature was specified in this Spec.
Strict-Transport-Security response headers can cause problems for localhost web servers because STS applies host-wide, across all ports. This causes compatibility problems for web developers testing locally as well as end-users who use software packages that commonly spin up localhost webservers for ephemeral reasons (e.g. communication of an auth token from a web login to a local software package). If one local listener sets Strict-Transport-Security on a localhost response, it will be applied to all subsequent localhost requests regardless of port. We resolve this problem by ignoring Strict-Transport-Security headers on responses from localhost URLs. The HTML Fetch algorithm has been updated to require this behavior. #
This feature was specified in this Spec.
Access to the Private State Token API is gated by Permissions Policy features. We proposed to update the default allowlist for both `private-state-token-issuance` and `private-state-token-redemption` features from self to * (wildcard). #
This feature was specified in this Spec.
Support of `sideways-rl` and `sideways-lr` keywords for `writing-mode` CSS property is added. They are vertical writing modes, and all letters are sideways. #
This feature was specified in this Spec.
This is a corner case change that hopefully does not impact developers. Previously calling `showPopover()` or `showModal()` on a popover or dialog that resides within an inactive document would silently fail. I.e. no exception would be thrown, but since the document is inactive, no popover or dialog would be shown. As of the https://github.com/whatwg/html/pull/10705 spec PR, these situations now throw InvalidStateError. #
This feature was specified in this Spec.
Allow WebAuthn relying parties to report information about existing credentials back to credential storage providers, so that incorrect or revoked credentials can be updated or removed from provider and system UI. https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Signal-API-explainer #
This feature was specified in this Spec.
Samples: https://signal-api-demo.glitch.me
Functionality added to the WebGPU spec after its first shipment in a browser. The “float32-blendable” GPU feature makes GPU textures with formats "r32float", "rg32float", and "rgba32float" blendable. #
This feature was specified in this Spec.
Functionality added to the WebGPU spec after its first shipment in a browser. The GPUDevice adapterInfo attribute exposes the same GPUAdapterInfo as the GPUAdapter object.. #
This feature was specified in this Spec.
Adds an optional field to WebGPU texture view creation to request a subset of the usage flags from the source texture. By default, texture view usage inherits from the source texture but there are view formats which can be incompatible with the full set of inherited usages. Adding a usage field to texture view creation allows the user request a subset of the source texture's usages that are valid with the view format and specific to their intended usage of the texture view. WebGPU implementations can also optimize the creation of low level resources and improve performance when using views with more specialized usage flags. #
This feature was specified in this Spec.
navigator.storage is no longer an EventTarget navigator.storage was made an EventTarget for the Storage Pressure Event, which never made it past the prototype phase: https://chromestatus.com/feature/5666274359115776 This dead code is being removed and as a result, navigator.storage will no longer extend EventTarget. #
This feature was specified in this Spec.
navigator.storage is no longer an EventTarget navigator.storage was made an EventTarget for the Storage Pressure Event, which never made it past the prototype phase: https://chromestatus.com/feature/5666274359115776 This dead code is being removed and as a result, navigator.storage will no longer extend EventTarget. #
This feature was specified in this Spec.
This release of Chrome had 4 new origin trials.
We intend to ship two new extensions for FedCM to address two issue that were collectively identified as CR blockers by the FedID WG: “A not-yet logged in IDP has no route to success” and “Allow signing in to additional account(s)”. To address these issues, we intend to introduce the following extensions to FedCM: - Mode: The “active” mode allows websites to call FedCM inside a button click (e.g. clicking on a “Sign-in to IdP” button), which requires FedCM to guarantee it will always respond with a visible user interface (as opposed to in “passive” mode, which doesn’t show any UI when users are logged out). So, calling the FedCM API in “active mode” takes users to login to the Identity Provider (IdP) when users are logged-out. Also, because the active mode is called within an explicit user gesture, the UI is also more prominent (e.g. centered and modal) compared to the UI from the passive mode (which doesn’t require a user gesture requirement and can be called on page load). - Use Other Account: With this extension, an IdP can allow users to sign in to other accounts. #
This feature was specified in this Spec.
Samples: https://fedcm-button.glitch.me
This API helps developers to detect the current posture of a foldable device. The device posture is the physical position in which a device holds which may be derived from sensors in addition to the angle. From enhancing the usability of a website by avoiding the area of a fold, to enabling innovative use cases for the web, knowing the posture of a device can help developers tailor their content to different devices. Content can be consumed and browsed even when the device is not flat, in which case the developer might want to provide a different layout for it depending on the posture state in which the device is being used. #
This feature was specified in this Spec.
Samples: https://github.com/foldable-devices
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>. Note: The previous rollout of this feature (started in Chrome 127) was stopped due to web compatibility issues, which should be fixed in the current implementation shipping in 130. Note: The previous rollout of this feature (started in 130) was stopped due to an accessibility regression, which should be fixed in the current implementation shipping in 132. #
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 samplesThe prefixed HTMLVideoElement-specific fullscreen APIs have been deprecated since approximately M38. They were replaced by the Element.requestFullscreen() API, which first shipped un-prefixed in M71, in 2018. As of 2024, most browsers have had support for the un-prefixed APIs for a few years now. This feature tracks removing the following APIs from HTMLVideoElement: - readonly attribute boolean webkitSupportsFullscreen; - readonly attribute boolean webkitDisplayingFullscreen; - void webkitEnterFullscreen(); - void webkitExitFullscreen(); // Note the different capitalization of the "S" in FullScreen. - void webkitEnterFullScreen(); - void webkitExitFullScreen(); These methods are now only aliases for the modern API. Their use has declined steadily over the years. #
This feature was specified in this Spec.
This release of Chrome had 1 are available behind a flag.
This bundles a few features that we would like to launch at the same time. We are bundling them together because they can be used by IdPs to implement authorization flows such as letting a user grant access to a user’s calendar to an RP. See also https://github.com/w3c-fedid/FedCM/issues/477. Continuation API: https://github.com/fedidcg/FedCM/issues/555 This lets the IDP open a popup window to finish the sign-in flow after potentially collecting additional information. Parameters API: https://github.com/fedidcg/FedCM/issues/556 This lets RPs pass additional data to the ID assertion endpoint Fields API: https://github.com/fedidcg/FedCM/issues/559 This lets RPs bypass the data sharing prompt in favor of the IDP prompting Multiple configURLs: https://github.com/fedidcg/FedCM/issues/552 This lets IDPs use different config files in different contexts without weakening FedCM privacy properties, by allowing one accounts endpoint for the eTLD+1 (instead of one config file, which is more limiting than necessary) Account labels: https://github.com/fedidcg/FedCM/issues/553 Combined with the previous proposal, this allows filtering the account list per config file without providing additional entropy to the IDP. #
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.