Chrome Release Summary

Chrome version: 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

Chrome 124

Enabled (11) | Origin Trial (1) | Behind a flag (7) | Deprecated (0) | Removed (0)

Enabled by default in 124

This release of Chrome had 11 new features.

'priority' HTTP request header

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.

Document Render-Blocking

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.

Document picture-in-picture: add option to hide back-to-tab button

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.

Resources

No linked docs

Samples: https://steimelchrome.github.io/document-pip/hide-back-to-tab-button.html

Private Network Access permission to relax mixed content

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.

Resources

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

SVG context-fill and context-stroke

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.

Streams API: ReadableStream async iteration

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.

Resources

No linked docs

Samples: https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream#async_iteration

WebGPU: ServiceWorker and SharedWorker support

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.

WebSocketStream

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.

Resources

Docs: https://web.dev/websocketstream/

Samples: https://github.com/ricea/websocketstream-explainer/blob/master/README.md

Windows ClearType Text Tuner Integration

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.

jitterBufferTarget

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.

setHTMLUnsafe and parseHTMLUnsafe

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.

Origin Trials in-progress in 124

This release of Chrome had 1 new origin trials.

X25519Kyber768 key encapsulation for TLS

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 is exposed as a new TLS cipher suite. TLS automatically negotiates supported ciphers, so 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. https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html #

This feature was specified in this Spec.

Flagged features in 124

This release of Chrome had 7 are available behind a flag.

'pageswap' event

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.

Form Controls Support Vertical Writing Mode Direction Support

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.

Permissions Prompt for Web MIDI API

# 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.

Shadow root clonable attribute

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.

SharedWorker script inherit controller for blob script URL

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.

Update LongTask code to use Long animation frames as a backend

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.

WebGPU: read-write storage textures

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.

Deprecations and Removals

Deprecation policy

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.

Deprecated features in 124

This release of Chrome had 0 features deprecated.

Removed features in 124

This release of Chrome had 0 features removed.