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 12 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.
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
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
Recency: The “recency” signal for Protected Audience interest groups indicates how long ago the user was joined to an interest group, which can be a useful signal when calculating an ad auction bid. Previously we provided this signal in a strictly bucketed and noised form to buyers’ win reporting function, reportWin(). This change exposes this signal to the buyers’ bidding function, generateBid(), which is a less privacy-sensitive function. It can be provided without bucketing or noising to generateBid() like other signals available in that function. We already allow developers to calculate this signal (e.g. by storing join time in the interest group), but we’ve been asked to have the browser supply it to generateBid() to ensure it’s calculated identically to the value supplied to the reporting function. Rounding bids and scores: In Protected Audience, the bid price and desirability score pass from functions that have access to cross-site data (generateBid() and scoreAd()) to the reporting worklets that have access to first party data (reportWin() and reportResult()), so to prevent event-level win reports from facilitating cross-site identity joins, we need to limit this data as much as possible. We’re planning to limit information in the bid price and desirability score by rounding them from 64-bit floating-point numbers to 16-bit floating point numbers.
This feature was specified in this Spec.
Websites 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 will make mouse events other than click, mouseup, and mousedown become dispatched on disabled form controls instead of blocking them. It will also stop propagating click, mouseup, and mousedown events to the parents of disabled form controls when the event is targeted at a child of a disabled form control. A previous attempt at this was not shipped here: https://chromestatus.com/feature/5685077795143680 #
This feature was specified in this Spec.
This release of Chrome had 4 new origin trials.
The EditContext API simplifies the process of integrating a web app with advanced text input methods such as VK shape-writing, Handwriting panels, speech recognition, IME Compositions etc., improves accessibility and performance, and unlocks new capabilities for web-based editors. #
This feature was specified in this Spec.
Docs: https://w3c.github.io/edit-contexthttps://github.com/w3c/edit-context/blob/gh-pages/explainer.mdhttps://github.com/w3c/edit-context/blob/gh-pages/dev-design.md
No linked samplesThis is a extension of long tasks. It measures the task together with its subsequent rendering update, adding information such as long running scripts, rendering time, and time spent in forced layout and style ("layout thrashing"). Developers can use this as a diagnostic for "sluggishness", which is measured by INP, by finding the causes for main-thread congestion which is often the cause for bad INP. #
This feature was specified in this Spec.
This API allows developers to configure the routing, and allows them to offload simple things ServiceWorkers do. If the condition matches, the navigation happens without starting ServiceWorkers or executing JavaScript, which allows web pages to avoid performance penalties due to ServiceWorker interceptions. #
This feature was specified in this Spec.
The Login Status API [1] (formerly IdP Sign-in Status API) allows identity providers to signal to the browser when their users are logging-in/out. Our goal is to open this up to other websites in the future. This signal, in this intent, is used by FedCM to address a silent timing attack, and in doing so, allows FedCM to operate without third party cookies altogether. This update would address the last remaining backwards incompatible changes we had previously identified in the original I2S of FedCM [2] as part of our scope of work. In the future, we expect that the Login Status API may also be used outside of FedCM (e.g. the Storage Access API [3]) and may be useful for websites that are not identity providers (e.g. extending browser storage [4]). [1] https://github.com/fedidcg/login-status [2] https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/E9pgS7GEBAAJ [3] https://github.com/fedidcg/login-status#storage-access-api [4] https://github.com/fedidcg/login-status#extending-site-data-storage #
This feature was specified in this Spec.
This release of Chrome had 5 are available behind a flag.
Use container queries to style descendants of containers based on their scroll state. The query container is either a scroll container, or an element affected by the scroll position of a scroll container. The following states can be queried: - Whether a sticky positioned container is stuck to one of the edges of the scroll box (stuck) - Whether a scroll snap aligned container is currently snapped horizontally or vertically (snapped) - Whether a scroll container can be scrolled in a queried direction (scrollable) A new container-type:scroll-state is introduced to allow such containers to be queried. For instance: #sticky { position: sticky; container-type: scroll-state; } @container scroll-state(stuck: top) { #sticky-child { font-size: 75% } } #
This feature was specified in this Spec.
Samples: https://codepen.io/argyleink/pen/JjqVzxqhttps://codepen.io/argyleink/pen/rNgbbOPhttps://codepen.io/argyleink/pen/wvbZZWPhttps://codepen.io/argyleink/pen/zYbEdGmhttps://codepen.io/argyleink/pen/vYPzdGphttps://codepen.io/argyleink/pen/PoMJvXN
'cap' is equal to the used cap-height of the first available font. 'rcap' is equal to the value of the cap unit on the root element.
This feature was specified in this Spec.
Capture all the screens currently connected to the device using getAllScreensMedia(). Calling getDisplayMedia() multiple times requires multiple user gestures, burdens the user with choosing the next screen each time, and does not guarantee to the app that all the screens were selected. getAllScreensMedia() improves on all of these fronts. (As this feature has extreme privacy ramifications, it is only exposed behind the MultiScreenCaptureAllowedForUrls enterprise policy, and users are warned before recording even starts, that recording *could* start at some point. The API will only work for origins that are specified in the MultiScreenCaptureAllowedForUrls allowlist. Any origin not specified there, will not have access to it.) #
This feature was specified in this Spec.
Docs: https://screen-share.github.io/capture-all-screenshttps://github.com/screen-share/capture-all-screens/blob/main/README.mdhttps://docs.google.com/document/d/1XB8rQRnY5N8G2PeEcNJpVO0q22CutvwW8GGKCZ1z_vc/edit?usp=sharing
Samples: https://honey-quartz-fukuiraptor.glitch.mehttps://github.com/screen-share/capture-all-screens/blob/main/HOWTO.mdhttps://github.com/screen-share/capture-all-screens/blob/main/README.md
Assigning a data: URL in SVGUseElement can cause XSS. And this also led to a Trusted Types bypass. Therefore, we plan to deprecate and remove support for it. #
This feature was specified in this Spec.
Docs: https://developer.chrome.com/blog/migrate-way-from-data-urls-in-svg-use
Samples: https://shhnjk.github.io/svg-use-iconshttps://github.com/shhnjk/shhnjk.github.io/tree/main/svg-use-icons
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
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 1 features deprecated.
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 samplesThis release of Chrome had 0 features removed.