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 16 new features.
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.
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
# 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
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.
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.
Samples: https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream#async_iteration
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. #
This feature was specified in this Spec.
Starting in Chrome 124, Chrome enables by default on all desktop platforms a new post-quantum secure TLS key encapsulation mechanism X25519Kyber768, 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 and QUIC 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 enterprise policy, which will be available through the end of 2024. However, long term, post-quantum secure ciphers will be required in TLS and the enterprise policy will be removed. Post-quantum cryptography is required for CSNA 2.0. Chrome 124 on Windows, Mac, Linux: new post-quantum secure TLS key encapsulation mechanism X25519Kyber768 is enabled Chrome 131 on Windows, Mac, Linux: Switch to standard version of ML-KEM Chrome 141 on Windows, Mac, Linux: Remove enterprise policy 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 0 new origin trials.
This release of Chrome had 6 are available behind a flag.
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.
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
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.
This 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.
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.
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.
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.