Chrome version: 151, 150, 149, 148, 147, 146, 145, 144, 143, 142, 141, 140, 139, 138, 137, 136, 135, 134, 133, 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 19 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 prior behavior caused issues if a top layer element (dialog, fullscreen, etc.) was DOM-nested within a popover. The inner element, when promoted to the top layer, would cause the outer popover to be hidden, which also (via CSS display:none) hid the inner element. That, in turn, caused issues at least for dialogs, which inert the entire page. This change makes top layer elements "nestable" within popovers. #
This feature was specified in this Spec.
We are landing the following changes to the Attribution Reporting API focused on: * additional debugging support by supporting new verbose debug reports * improving privacy & security by adding additional gating to source verbose debug reports * improving rate limit accounting by separating the attribution count for the two ARA report types
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
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 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.
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 samplesThe 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
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.
Allows 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. #
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.
Canceling mousemove will not prevent text selection or drag-and-drop. 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: 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 canceling 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.
Support running cross origin worklets without having to create an iframe
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.
Functionality added to the WebGPU/WGSL spec after its first shipment in a browser. Adds support using a render pass to render to slices of 3D textures in addition to rendering to 2D textures. This is used in graphical algorithm to do voxelization between others. #
This feature was specified in this Spec.
This release of Chrome had 5 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
A collection of APIs that helps developers target foldable and dual screen devices: Device Posture API and Viewport Segments Enumeration API. Each have their own chrome status entry : https://chromestatus.com/feature/5185813744975872 https://chromestatus.com/feature/5170498990243840
This feature was specified in this Spec.
The 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.
The Viewport Segments API allows developers to adapt their website/webapp layout to target foldable devices. The viewport segments defines the position and dimensions of a logically separate region of the viewport. Viewport segments are created when the viewport is split by one or more hardware features (such as a fold or a hinge between separate displays) that act as a divider; segments are the regions of the viewport that can be treated as logically distinct by the author. #
This feature was specified in this Spec.
Docs: https://github.com/WICG/visual-viewport/blob/gh-pages/segments-explainer/SEGMENTS-EXPLAINER.md
Samples: https://github.com/foldable-devices/demos
This release of Chrome had 5 are available behind a flag.
This feature captures the JS call stack when a web page becomes unresponsive due to JavaScript code running an infinite loop or other very long computation. This helps developers to identify the cause of the unresponsiveness and fix it more easily. The JS call stack is included in the crash reporting API when the reason is unresponsive. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing
No linked samplesThe includeShadowRoots argument was a never-standardized argument to the DOMParser.parseFromString() function, which was there to allow imperative parsing of HTML content that contains declarative shadow DOM. This was shipped in M90 [1] as part of the initial shipment of declarative shadow DOM. Since the standards discussion rematerialized in 2023, the shape of DSD APIs changed, including this feature for imperative parsing. (See [2] for more context on the standards situation and recent changes, and see [3] and [4] for other related deprecations.) Now that a standardized version of this API, in the form of setHTMLUnsafe() and parseHTMLUnsafe() will ship in Chrome 124 ([5]), the non-standard includeShadowRoots argument needs to be deprecated and removed. All usage should shift accordingly: Instead of: (new DOMParser()).parseFromString(html,'text/html',{includeShadowRoots: true}); this can be used instead: document.parseHTMLUnsafe(html); [1] https://chromestatus.com/feature/5191745052606464 [2] https://chromestatus.com/feature/5161240576393216 [3] https://chromestatus.com/feature/5081733588582400 [4] https://chromestatus.com/feature/6239658726391808 [5] https://chromestatus.com/feature/6560361081995264 #
This feature was specified in this Spec.
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.
The 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.
WebNN seeks to enable web applications and frameworks to take advantage of native operating system services for machine learning and the underlying hardware capabilities available on a user's computer to implement consistent, efficient, and reliable ML experiences on the web. #
This feature was specified in this Spec.
Samples: https://webmachinelearning.github.io/webnn-sampleshttps://microsoft.github.io/webnn-developer-preview
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 3 features deprecated.
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, we intend to remove this enterprise policy by early May 2024 (Chrome 125).
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 #
Chrome 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.
This release of Chrome had 0 features removed.