Chrome 156 Release Notes

Currently web developers cannot retry failed module loads, as these failures are being cached (and retries just result in immediate failures). This change to the module loading behavior enables failed module loads to be manually retried (e.g. by calling import() again), solving real developer (and user) pain when it comes to using modules over unstable networks.

When fetching rel=compression-dictionary links:

• Use "compression-dictionary" as request destination.
• Properly set request's mode, credentials, referrer and referrerpolicy.
• Take into account crossorigin and referrer attributes form <link rel="compression-dictionary">.

Adds support for passing custom HTTP request headers via WebTransportOptions and inspecting server response headers through the WebTransport instance. This allows web applications to supply metadata, authentication tokens, and custom parameters during the initial CONNECT handshake and access server-provided headers once the connection is established.

Selects the element that initiated the navigation, whether it's a link/button/form. The element stays selected throughout the navigation.

The random() function brings generative randomness to CSS, allowing web authors to generate a random numeric value within a specified range.

For example, web authors can use random() to scatter elements randomly within their container: .dot { /* Position each dot randomly */ position: absolute; top: random(0%, 100%); left: random(0%, 100%); }

This feature also includes caching controls. By default, each random() function resolves to a new, distinct value. Web authors can override this default by passing a <random-key> value as the function's first argument to control how random values are shared across properties and elements.

CSS text-decoration-inset controls how far underlines, overlines, and line-through decorations are inset from or extended beyond text run edges. It supports auto, length, and percentage values, including one-value and two-value syntax for setting the start and end offsets. This lets developers adjust decoration spacing and create reveal effects with native text decorations instead of background gradients or additional elements.

sampler: https://static.januschka.com/i-468928416/?asddsaasd MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/text-decoration-inset

CL: https://chromium-review.googlesource.com/c/chromium/src/+/7748204

Allows authors to omit any descriptor in an @property rule and the corresponding optional members of CSS.registerProperty(). Omitted values default to universal syntax, inheritance, and the guaranteed-invalid initial value; invalid descriptors use normal CSS fallback behavior.

Extends the overflow property to support scrollable values together with clip (for example, overflow: scroll clip). This allows position: sticky to be constrained by different ancestor scroll containers per axis, and gives authors a way to ensure an axis using overflow: clip stays in place.

https://github.com/w3c/csswg-drafts/issues/9519

Add a "pair" keyword to scroll-snap-type. If used, when the container scroll snaps to an element on one axis, it should snap to the same element on the other axis. In the existing spec, the "both" keyword allows the scroll container to select snap targets in X and Y axes independently and snap to different targets.

Chromium's IndexedDB implementation is rewritten on top of SQLite, to replace the previous implementation that uses a hybrid of LevelDB and flat files. There is no change to the Web API.

This is expected to improve reliability and, to a lesser extent, performance.

For now this is applied to new data stores. This is step 2 of a multi-phase rollout. See https://chromestatus.com/feature/5126896685809664 which tracks step 1, the rollout for in-memory i.e. incognito contexts. Step 3 will consist of migrating existing data from LevelDB stores to SQLite stores.

In this step, the first time a user visits a site, or after clearing site data, new IDB data will be stored in a backend that makes use of SQLite, but existing data stored in LevelDB is unimpacted.

See Documentation link below for a list of differences to be aware of.

Chrome 142 restricted the ability to make requests to the user's local network, gated behind a permission prompt. A local network request is any request from a public website to a local IP address or loopback, or from a local website (for example, intranet) to loopback.

Gating the ability for websites to perform these requests behind a permission mitigates the risk of cross-site request forgery attacks against local network devices such as routers, and reduces the ability of sites to use these requests to fingerprint the user's local network.

This permission is restricted to secure contexts. If granted, the permissions additionally relax mixed content blocking for local network requests (since many local devices are not able to obtain publicly trusted TLS certificates for various reasons).

This work supersedes a prior effort called Private Network Access, which used preflight requests to have local devices opt in. For more information on this feature, see Adapting your website for new Local Network Access restrictions in Chrome.

Chrome 145 introduced more granular permissions for websites requesting access to a user's local network. The previous single local-network-access permission is being split into two distinct permissions:

• local-network: Grants access to IP addresses in the local network space (for example, intranets, internal devices).
• loopback-network: Grants access to loopback IP addresses (for example, localhost, 127.0.0.1).

The old local-network permission will remain as an alias, ensuring existing configurations and permissions policies continue to function as expected.

This change provides both users and Admins with more precise control over how websites interact with internal network resources. Current enterprise policies managing local network access will not be affected by this change.

Chrome 146 introduces two new enterprise policies for managing local network access restrictions: LocalNetworkAccessIpAddressSpaceOverrides and LocalNetworkAccessPermissionsPolicyDefaultEnabled. These policies can be set using custom configurations.

Chrome 147 expands Local Network Access restrictions to include WebSocket and WebTransport connections.

In Chrome 156, the LocalNetworkAccessRestrictionsTemporaryOptOut policy will be removed.

The :playing, :paused, :seeking, :buffering, :stalled, :muted, and :volume-locked CSS pseudo-classes match <audio> and <video> elements based on their state.

This is one of the focus areas in https://wpt.fyi/interop-2026.

Adds the ability to provide a less or greater modifier to the @builtin(frag_depth) in WGSL.

The current @builtin(frag_depth) can potentially introduce a performance penalty due to disabling the early-Z optimizations on a draw call. The new modifiers allow the explicit setting of the buffer mode and allow the early-Z optimizations to be applied.

The WebRTC Web Diagnostic Logging API allows authorized web applications to trigger the collection of WebRTC diagnostic data so that it can be used for local debugging. It also allows an application to share the WebRTC diagnostic data with the user agent vendor, subject to user authorization, with the purpose of providing information that can help fix bugs in or improve the user agent.

Diagnostic logs are enabled with the enterprise policy WebRtcDiagnosticLogCollectionAllowedForOrigins.

Fenced frames are nested frames that embed content onto a page without the ability to share data between the fenced frame and its embedder.

window.fence APIs include Fenced frames Ads reporting (FFAR) JS APIs that were created for privacy-safe ads reporting from FFs created using Protected Audience and SelectURL and getNestedConfigs() to support PA component ads.

This intent is for removing both of these. Fenced frames element removal will be two step as detailed below.

With the removal (or stub API replacement) of PA and selectURL, FFs can no longer be navigated and thus it is safe to remove them. Fenced frames are only able to be navigated using the urn:uuid in a FencedFrameConfig[1], which can only be created using the return values from runAdAuction and selectURL. These APIs are being deprecated and removed in M152 as per the following Intent threads: Protected Audience[2], Shared Storage[3].

Plan: Given that the fenced frames element can no longer be navigated, we propose removing the element from the code in the following phases:

1. M156: Keep the fenced frame element and its associated IDL dependencies as stubs. This is to ensure no JS call throws, e.g.calling fenced-frame-element.config.setSharedStorageContext().

2. M156: In the same milestone we will also stub the window.fence APIs completely. Since there is no FF document navigation, these APIs cannot be invoked anymore, so it will be a no-op.

3. M157 Canary/Beta: Begin a controlled rollout of the stub FF HTML element removal via a field trial. Note that removing the element will resolve it to HTMLUnknownElement.

At this point we are requesting approvals for all of the above steps.

4. M157 Stable: Assuming there are no regressions or breakage after reaching 1% stable, we will request additional approval for full removal of the FF element.

[1]https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/fenced_frame/fenced_frame_config.idl [2]https://groups.google.com/a/chromium.org/g/blink-dev/c/k_nubsMb97g/m/awPD4IGLBAAJ [3]https://groups.google.com/a/chromium.org/g/blink-dev/c/uh5Ke6qyegc/m/WFTFnhyJBAAJ