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 28 new features.
The `pageswap` event is fired on a Document's window object when a navigation will replace this Document with a new Document. The event provides activation info about the navigation (type, NavigationHistoryEntry for the new Document). If the navigation has a cross-document ViewTransition, the event is dispatched before capturing state for the old Document. This allows the page-author to configure the old state captured for the transition based on the navigation's activation info and the current visual state of the old Document. This feature is split out from the larger ViewTransition-on-Navigation project. #
This feature was specified in this Spec.
This feature adds the 'priority' request header for all HTTP requests with the priority information for the request at the time that it was sent. RFC 9218 (Extensible Prioritization Scheme for HTTP) defines a 'priority' HTTP request header to use for signaling request priority to origins (and intermediaries). It also defines negotiation processes and protocol-level frames for HTTP/2 and HTTP/3 to carry the same priority information. The header can only signal the initial priority for a resource when it was first requested while the frame-based mechanisms allow for modifying the priority after the fact. The header can operate end-to-end to the origin servers (and provide a mechanism for the origin to override the priority if recognized by intermediaries) while the frames are limited to operating on a link level. This feature is specifically for supporting the header-based prioritization scheme. #
This feature was specified in this Spec.
UAs are starting to provide writing suggestions to users as they type on various editable fields across the web. While this is generally useful for users, there are cases when developers may want to turn off UA-provided writing assistance, such as extensions or sites that wish to provide similar functionality on their own. To that end, developers need a solution that would turn on/off UA-provided writing assistance. The new attribute 'writingsuggestions' has values 'true'/'false' that would allow developers to turn on/off browser-provided writing suggestions. The attribute's state for an element can also be inherited from ancestor elements, thereby allowing developers to control this functionality at a per-element or per-document/sub-document scale. #
This feature was specified in this Spec.
Adds `image/svg+xml` standard type support to the Async Clipboard API. The current implementation of the Async Clipboard API only supports text/plain, image/png, and text/html standard types. SVG images are popular due to their ability to encode images in a space efficiently and their ability to maintain image quality even when zooming in. Note that `image/svg+xml` as a standard type is not supported in DataTransfer APIs. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1jq8QSCQRdNy99rnPusmW8is62c22PVuq-Sk-tMT2tRk/edit
Samples: https://gilded-petalite-frost.glitch.me
We are landing the following changes to the Attribution Reporting API focused on: * additional debugging capabilities by supporting parsing failure debug reports * improving API ergonomics by supporting a field to specify preferred registration platform * improving privacy
Exposes length attribute of CSSKeyframesRule. Interfaces that support indexed properties must define an integer-typed attribute named "length". #
This feature was specified in this Spec.
This feature enables authors to block rendering of a Document until the critical content has been parsed, ensuring a consistent first paint across all browsers. Without this feature, the first paint's state depends on the heuristics for parser yielding which can vary across browsers. This is particularly important for View Transitions where the parsed DOM state on the first frame can drastically change the transition created. Note that this feature specifically implements a `<link rel=expect href="#id">` syntax that allows a link element to reference another expected element on the page. The rendering is then blocked until the expected element is fully parsed. This supersedes previous implementation of html attribute that allows the whole document to be render blocked.
This feature was specified in this Spec.
This adds a new parameter ("disallowReturnToOpener") to the document picture-in-picture API that, when set to true, hints to the user agent that they should not show a button in the picture-in-picture window that allows the user to return to the opener. While having a button to return content to the opener always makes sense in the video picture-in-picture case (the video stream can be returned to the video element in the opener tab), this is not always the case for document picture-in-picture experiences. This gives developers more control over the user experience when they determine that such a button does not make sense for their use case.
This feature was specified in this Spec.
Samples: https://steimelchrome.github.io/document-pip/hide-back-to-tab-button.html
CSS property writing-mode allow elements to go vertical, but users cannot set the direction in which value changes. With this feature, we are allowing the form control elements meter, progress and range input type to have vertical writing mode and choose the form control's value direction. If direction is rtl, the value is rendered from bottom to top. If direction is ltr, the value is rendered from top to bottom. For Web compatibility, we plan to slowly rollout the change in 123 and enable in stable in 124.
This feature was specified in this Spec.
Changes the lazy load intersection observer's init dictionary to use a scrollMargin instead of a rootMargin. This allows lazy loading iframes contained inside CSS scrollers, like carousels, to load as expected when near the viewport instead of the current behavior where these iframes load when at least one pixel is intersecting the viewport. #
This feature was specified in this Spec.
Docs: https://gist.github.com/tcaptan-cr/bf0ac25f77cb6b6c58c916e6577d91c3
No linked samples# Rationale There have been several reported problems around the Web MIDI API's drive-by access to client MIDI devices.[1][2] To address this problem, the Audio WG decided to place an explicit permission on the general MIDI API access.[3][4] Originally, the explicit permission was only required for advanced MIDI usage (System Exclusive messages) in Chrome, but the completion of this work will expand the scope of the permission even to regular MIDI API usage. # Project Scope This feature gates the Web MIDI API access behind a permissions prompt. Today the use of SysEx messages with the Web MIDI API requires an explicit user permission. With this implementation, even access to the Web MIDI API without SysEx support will require a user permission. [1] https://crbug.com/1251044 [2] https://www.phpied.com/nightmare-scenarios-with-webmidi/ [3] https://www.w3.org/TR/webmidi/#requestmidiaccess [4] https://webaudio.github.io/web-midi-api/#permissions-integration #
This feature was specified in this Spec.
In order to establish connections to devices on a local network that do not have globally unique names, and therefore cannot obtain TLS certificates, this feature introduces a new option to `fetch()` to declare a developers' intent to talk to such a device, a new policy-controlled feature to gate each sites' access to this capability, and new headers for the server's preflight response to provide additional metadata. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1Q18g4fZoDIYQ9IuxlZTaItgkzfiz_tCqaEAI8J3Y1WY/edithttps://github.com/WICG/private-network-access/blob/main/permission_prompt/security_privacy_self_review.md
Samples: https://drive.google.com/file/d/1pnyQfIsXdtJnZoCBVSt4xim0yXjZ0Aqc/view?usp=sharing
Applications relying on ICE often need to know whether a connection is relayed via a TURN server and which TURN server and TURN server protocol an ICE candidate was gathered from. https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface gets implementations for two new properties for RTCIceCandidate objects emitted from the 'icecandidate' event. https://github.com/w3c/webrtc-pc/pull/2773 added the url of the STUN or TURN server a local ICE candidate of type 'srflx' or 'relay' was gathered from. https://github.com/w3c/webrtc-pc/pull/2763 added the relay protocol (i.e. whether the candidate was gathered via TURN/UDP, TURN/TCP or TURN/TLS) a local ice candidates of type 'relay' was gathered from. These properties are already available in the getStats API as RTCIceCandidateStats. #
This feature was specified in this Spec.
Implements an existing SVG feature that allows the keywords 'context-fill' and 'context-stroke' when specifying fill and stroke properties: https://svgwg.org/svg2-draft/painting.html#context-paint This only affects SVG sub-trees that are instantiated via a <use> element, and <marker> elements that are instantiated via the 'marker' property on a <path> element. In those circumstances, 'context-fill' and 'context-stroke' are resolved to the value of the 'fill' and 'stroke' properties on the <use> or <path>.
This feature was specified in this Spec.
This hint indicates one or more of the "form-factor" of the user-agent / device, so that the site can tailor its response. #
This feature was specified in this Spec.
Docs: https://github.com/djmitche/web-explainers/blob/main/sec-ch-ua-form-factor.md
No linked samplesThis enables individual control over whether a shadow root is clonable (via standard platform cloning commands such as `cloneNode()`). Imperative shadow roots can now be controlled via a parameter to `attachShadow({clonable:true})`. Declarative shadow roots can be controlled via a new attribute, `<template shadowrootmode=open shadowrootclonable>`. #
This feature was specified in this Spec.
We plan to ship the following changes to the Shared Storage API: 1) Allow writing and deleting from Shared Storage via HTTP response header --This is a performance improvement and is backwards compatible 2) Only allow Private Aggregation reports for up to 5 seconds after worklet starts --This is a privacy measure to prevent timing attacks. --Reports sent after this point are silently dropped 3) Per-site privacy budgeting - This change enforces budgets per-site rather than per-origin
This feature was specified in this Spec.
According to https://w3c.github.io/ServiceWorker/#control-and-use-worker-client, workers should inherit controllers for the blob URL. However, existing code allows only dedicated workers to inherit the controller, and shared workers do not inherit the controller. This is the fix to make Chromium behavior adjust to the specification. #
This feature was specified in this Spec.
The pseudo element argument in some APIs ( getComputedStyle(element, pseudo) and new KeyframeEffect(target, keyframes, {pseudoElement}) is currently parsed in a way that doesn't match the spec - e.g. it allows pseudo-elements without ":", it doesn't parse whitespace correctly if there is argument, and several other issues. There are many failing tests around this. Recently webkit fixed this to more closely match the spec. This matches the webkit implementation and the spec, unskipping most of the tests. Using a chromestatus entry for this as it's a web-facing behavior change. #
This feature was specified in this Spec.
The streams APIs provide ubiquitous, interoperable primitives for creating, composing, and consuming streams of data. This change adds support for the async iterable protocol to the ReadableStream API, enabling readable streams to be used as the source of for await...of loops. #
This feature was specified in this Spec.
Docs: https://github.com/whatwg/streams/blob/main/explainers/readable-stream-async-iteration.md
Samples: https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream#async_iteration
Using the LoAF implementation for reporting longtasks is an implementation detail, but it would have the following web-observable impact: - we would stop reporting longtasks for hidden tabs - a few longtask bugs would disappear, resulting in more reported longtasks Note that this would not affect the Lighthouse TBT score, that anyway relies on trace events. #
This feature was specified in this Spec.
Functionality added to the WebGPU spec after its first shipment in a browser. ServiceWorker and SharedWorker support is added to WebGPU, aligning with existing WebGL capabilities. #
This feature was specified in this Spec.
Functionality added to the WebGPU/WGSL spec after its first shipment in a browser. Adds support for (read-only and) read-write storage textures which allow more general access to texture memory for GPU computation and can unlock more advanced graphical algorithms. This feature has been request by developers very often. #
This feature was specified in this Spec.
The WebSocket API provides a JavaScript interface to the RFC6455 WebSocket protocol. While it has served well, it is awkward from an ergonomics perspective and is missing the important feature of backpressure. The intent of the WebSocketStream API is to resolve these deficiencies by integrating WHATWG Streams with the WebSocket API. #
This feature was specified in this Spec.
Docs: https://web.dev/websocketstream/
Samples: https://github.com/ricea/websocketstream-explainer/blob/master/README.md
This feature tracks the work to support picking the contrast and gamma values from the Windows ClearType Text Tuner setting and applying them to Skia text rendering. This ensures that users' text rendering preferences are respected on Windows devices. #
Chrome 124 enabled by default on all desktop platforms a new post-quantum secure TLS key encapsulation mechanism [X25519Kyber768](https://developer.chrome.com/blog/chrome-124-beta#x25519kyber768_key_encapsulation_for_tls), based on a NIST standard (ML-KEM). This protects network traffic from Chrome with servers that also support ML-KEM from decryption by a future quantum computer. This change should be transparent to server operators. This cipher will be used for both [TLS 1.3](https://datatracker.ietf.org/doc/html/rfc8446) and [QUIC](https://datatracker.ietf.org/doc/rfc9000/) connections. However, some TLS middleboxes might be unprepared for the size of a Kyber (ML-KEM) key encapsulation, or a new TLS ClientHello cipher code point, leading to dropped or hanging connections. This can be resolved by updating your middlebox, or disabling the key encapsulation mechanism via the temporary [PostQuantumKeyAgreementEnabled](https://chromeenterprise.google/policies/#PostQuantumKeyAgreementEnabled) enterprise policy, which will be available through Chrome 145. However, long term, post-quantum secure ciphers will be required in TLS and the enterprise policy will be removed in Chrome 147. Post-quantum cryptography is required for CSNA 2.0. To learn more, see [Protect Chrome Traffic with Hybrid Kyper KEM](https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html). #
This feature was specified in this Spec.
JitterBufferTarget attribute allows applications to specify a target duration of time in milliseconds of media for the RTCRtpReceiver's jitter buffer to hold. This influences the amount of buffering done by the user agent, which in turn affects retransmissions and packet loss recovery. Altering the target value allows applications to control the tradeoff between playout delay and the risk of running out of audio or video frames due to network jitter. #
This feature was specified in this Spec.
The setHTMLUnsafe and parseHTMLUnsafe methods allow Declarative ShadowDOM to be used from javascript. In the future, they may also get new parameters for sanitization.
This feature was specified in this Spec.
This release of Chrome had 2 new origin trials.
Mutation Events, including `DOMSubtreeModified`, `DOMNodeInserted`, `DOMNodeRemoved`, `DOMNodeRemovedFromDocument`, `DOMNodeInsertedIntoDocument`, and `DOMCharacterDataModified`, are quite bad for page performance, and also significantly increase the complexity of adding new features to the Web. These APIs were deprecated from the spec (https://w3c.github.io/uievents/#legacy-event-types) in 2011, and were replaced (in 2012) by the much better-behaved Mutation Observer API. Usage of the obsolete Mutation Events must now be migrated to Mutation Observer. Mutation event support will be disabled by default starting in Chrome 127, around July 30, 2024. Code should be migrated before that date to avoid site breakage. If more time is needed, there are a few options: - The Mutation Events Deprecation trial (https://developer.chrome.com/origintrials/#/view_trial/919297273937002497) can be used to re-enable the feature for a limited time on a given site. This can be used through Chrome 134, ending March 25, 2025. - A MutationEventsEnabled enterprise policy (https://chromeenterprise.google/policies/#MutationEventsEnabled) can also be used for the same purpose, also through Chrome 134. Please see this blog post for more detail: https://developer.chrome.com/blog/mutation-events-deprecation Report bugs here: https://issues.chromium.org/new?component=1456718&template=1948649 #
This feature was specified in this Spec.
Installed web apps can change the text on the title bar based on the page's content. The current behavior is that the installed web application will put the app's name from the manifest and append the page’s inner text from the `<title>` HTML tag in the head of the page. This often can create awkward titles for some web apps. This feature allows to specify complementary information about the current window of an installed running PWA. It adds a subtitle to the page to provide contextual information that is displayed in the window's title bar. This replaces the text contained in the HTML's title tag. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1RFooPMsNJWoMifLU71GQysTC86BYdyKTCMcDIos3IGs/edit?usp=sharing
Samples: https://diek.us/pwinterhttps://youtu.be/qdBhSmawNc8?t=1581
This release of Chrome had 7 are available behind a flag.
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
A new "Automatic Fullscreen" content setting permits Element.requestFullscreen() without a user gesture, and permits browser dialogs to appear without exiting fullscreen. The setting is blocked by default. Sites can query for permission (starting in M128), but cannot prompt. New UI controls are limited to Chrome's settings pages [1] and the site info bubble. Users can allow Isolated Web Apps [2], and enterprise admins can allow additional origins with the AutomaticFullscreenAllowedForUrls policy. Combined with Window Management permission [3] and unblocked popups [4], this unlocks valuable fullscreen capabilities: - Open a fullscreen popup on another display, from one gesture - Show fullscreen content on multiple displays from one gesture - Show fullscreen content on a new display, when it's connected - Swap fullscreen windows between displays with one gesture - Show fullscreen content after user gesture expiry or consumption [1] chrome://settings/content/automaticFullScreen and site details pages [2] User control is initially scoped to security-sensitive apps; see https://chromestatus.com/feature/5146307550248960 [3] For multi-screen window placement features; see https://chromestatus.com/feature/5252960583942144 [4] To similarly permit window.open() without a user gesture; see chrome://settings/content/popups #
This feature was specified in this Spec.
Docs: https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
Samples: https://github.com/michaelwasserman/iwa-windowing-example
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.
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.
Adds the Float16Array typed array. Number values are rounded to IEEE fp16 when writing into Float16Array instances. #
This feature was specified in this Spec.
Chromium currently checks all selection highlight colors against the text color and inverts the highlight color if it matches the text. Hence, author-defined ::selection CSS properties may be modified by the browser despite explicit author intent. For example, a CSS rule "::selection { color: cyan; background: cyan; }" the background is inverted and red color is used. In https://github.com/w3c/csswg-drafts/issues/6150 the CSS working Group resolved to disallow the chromium behavior. We propose to implement this spec change and bring chromium into compatibility with other browsers. #
This feature was specified in this Spec.
The new `hints` parameter[1] in WebAuthn requests allows sites to provide guidance to browsers to guide their UI. The canonical use case are enterprises which know that their internal sites use only security keys and want to be able to communicate that so that browsers focus the UI on that case. But hints also resolve a tension where the current `authenticatorAttachment` parameter is strict: setting it to `platform` excludes all cross-platform options and vice versa. This has proven less than ideal in some cases. [1] https://w3c.github.io/webauthn/#enum-hints
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.