# Chrome 132

**Stable release date:** January 14th, 2025


Unless otherwise noted, the following changes apply to Chrome 132 stable
channel release for Android, ChromeOS, Linux, macOS, and Windows.
| Want just the highlights? Check out [New in Chrome 132](https://developer.chrome.com/blog/new-in-chrome-132).

<br />

## HTML and DOM

### Throw exception for popovers and dialogs in non-active documents

Previously calling `showPopover()` or `showModal()` on a popover or dialog
that resides within an inactive document would silently fail. No exception
would be thrown, but as the document is inactive, no popover or dialog would
be shown. As of Chrome 132, these situations now throw `InvalidStateError`.


[Tracking bug #373684393](https://issues.chromium.org/issues/373684393) \| [ChromeStatus.com entry](https://chromestatus.com/feature/6352111728852992) \| [Spec](https://github.com/whatwg/html/pull/10705)

<br />

### Dialog toggle events

It's useful to know when `<dialog>` elements open and close, and `popover`
already has `ToggleEvent` which is dispatched when a popover opens or closes.
Previously, to detect when a `<dialog>` opens you had to register a mutation
observer to check for open, however, this is quite a lot of work where an
event would be easier.

This change incorporates the same `ToggleEvent` that popovers dispatch, but
for `<dialog>` elements: when `showModal` or `show` is called, `<dialog>`
dispatches a `ToggleEvent` with `newState=open`. When a `<dialog>` is closed
(using the form, button, or closewatcher) it should dispatch a `ToggleEvent`
with `newState=closed`.


[Tracking bug #41494780](https://issues.chromium.org/issues/41494780) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5078613609938944) \| [Spec](https://github.com/whatwg/html/pull/10091)

<br />

### Fix selection `isCollapsed` in Shadow DOM

Selection isCollapsed should return true if and only if the anchor and focus
are the same. This should be true whether the selection starts or ends inside a
light or a shadow tree.


[Demo](https://codepen.io/Di-Zhang/pen/jOjdeoX) \| [Tracking bug #40400558](https://issues.chromium.org/issues/40400558) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5175599392620544) \| [Spec](https://w3c.github.io/selection-api/#dom-selection-iscollapsed)

<br />

## CSS

### CSS Anchor Positioning: allow `anchor-size()` in `inset` and `margin` properties

Originally, `anchor-size()` was only allowed in sizing properties. The
specification was changed to allow `anchor-size()` in insets and margins as
well.


[Tracking bug #346521300](https://issues.chromium.org/issues/346521300) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5203950077476864) \| [Spec](https://drafts.csswg.org/css-anchor-position-1/#anchor-size-fn)

<br />

### CSS sideways writing modes

Support of `sideways-rl` and `sideways-lr` keywords for the `writing-mode`
CSS property. `sideways-rl` and `sideways-lr` are helpful to write non-CJK
text vertically. They don't have behaviors favorable for CJK languages unlike
`vertical-rl` and `vertical-lr`.


[MDN writing-mode](https://developer.mozilla.org/docs/Web/CSS/writing-mode) \| [Tracking bug #40501131](https://issues.chromium.org/issues/40501131) \| [ChromeStatus.com entry](https://chromestatus.com/feature/6201053052928000) \| [Spec](https://drafts.csswg.org/css-writing-modes/#propdef-writing-mode)

<br />

## Loading

### Fetch: `Request.bytes()` and `Response.bytes()`

Add a `bytes()` method to the `Request` and `Response` interfaces, which
returns a promise that resolves with a Uint8Array. While `Request` and
`Response` have an `arrayBuffer()` method, you can't read directly from a
buffer. You have to create a view such as a `Uint8Array` to read it. The
`bytes()` method improves the ergonomics of getting the body of Request and
Response.

<br />

| **Baseline Newly Available:** This feature is now available in all three major browser engines.

<br />


[Tracking bug #340206277](https://issues.chromium.org/issues/340206277) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5239268180754432) \| [Spec](https://fetch.spec.whatwg.org/#dom-body-bytes)

<br />

### Ignore `Strict-Transport-Security` for localhost

`Strict-Transport-Security` (STS) response headers can cause problems for
localhost web servers because STS applies host-wide, across all ports. This
causes compatibility problems for web developers testing locally. It also
affects end-users who use software packages that commonly start localhost
web servers for ephemeral reasons. For example, communication of an auth
token from a web login to a local software package. If one local listener
sets `Strict-Transport-Security` on a localhost response, it's applied to
all subsequent localhost requests regardless of port.

Chrome 132 resolves this problem by ignoring `Strict-Transport-Security`
headers on responses from localhost URLs.


[Tracking bug #41251622](https://issues.chromium.org/issues/41251622) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5134293196865536)

<br />

## Media

### Capture all screens

Capture all the screens 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. The
`getAllScreensMedia()` method improves on all of these fronts.
| **Note:** As this feature has 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, won't have access to it.

This feature is shipping on Desktop only.


[Design Doc](https://docs.google.com/document/d/1XB8rQRnY5N8G2PeEcNJpVO0q22CutvwW8GGKCZ1z_vc/preview?tab=t.0) \| [Tracking bug #40216442](https://issues.chromium.org/issues/40216442) \| [ChromeStatus.com entry](https://chromestatus.com/feature/6284029979525120) \| [Spec](https://screen-share.github.io/capture-all-screens)

<br />

### Element Capture

Given a video `MediaStreamTrack` obtained through pre-existing means to
initiate tab-capture, [Element Capture](https://developer.chrome.com/docs/web-platform/element-capture)
allows mutating the track to only capture a subtree of the DOM starting at a
given Element.

The API bears some resemblance to the Region Capture API, but affords greater
flexibility for applications, because occluding and occluded content are both
excluded from the capture.


[Demo](https://element-capture-demo.glitch.me/) \| [Tracking bug #270230413](https://issues.chromium.org/issues/270230413) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5198989277790208) \| [Spec](https://screen-share.github.io/element-capture)

<br />

## Web APIs

### `PushMessageData::bytes()`

The `PushMessageData` interface mimics the `Body` interface, which was amended
earlier this year with a new `bytes()` method, following the principle that
APIs should generally vend byte buffers as `Uint8Arrays`. Chrome 132 realigns
with the `Body` interface by providing the `bytes()` accessor on the
`PushMessageData` interface as well.

<br />

| **Baseline Newly Available:** This feature is now available in all three major browser engines.

<br />


[MDN PushMessageData: bytes() method](https://developer.mozilla.org/en-US/docs/Web/API/PushMessageData/bytes) \| [Tracking bug #373336950](https://issues.chromium.org/issues/373336950) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5117729756151808) \| [Spec](https://www.w3.org/TR/push-api/#dom-pushmessagedata-bytes)

<br />

### Keyboard focusable scroll containers

The rollout of this feature (from Chrome 130) was stopped due to an
accessibility regression. This is fixed and the feature continues to roll out
with Chrome 132.


[Keyboard focusable scrollers](https://developer.chrome.com/blog/keyboard-focusable-scrollers) \| [Tracking bug #40113891](https://issues.chromium.org/issues/40113891) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5231964663578624) \| [Spec](https://drafts.csswg.org/css-overflow-3/#scroll-container)

<br />

### Device Posture API

This API helps developers to detect the current posture of a foldable device.
The *device posture* is the physical position in which a device holds which
may be derived from sensors in addition to the angle.

From enhancing the usability of a website by avoiding the area of a fold, to
enabling innovative use cases for the web, knowing the posture of a device can
help developers tailor their content to different devices.

Content can be consumed and browsed even when the device is not flat, in
which case the developer might want to provide a different layout for it
depending on the posture state in which the device is being used.


[Git Repo](https://github.com/foldable-devices) \| [Tracking bug #40124716](https://issues.chromium.org/issues/40124716) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5185813744975872) \| [Spec](https://www.w3.org/TR/device-posture)

<br />

### Saved queries in `sharedStorage.selectURL`

`sharedStorage.selectURL()` now allows queries to be saved and reused on a
per-page basis, where the two per-page-load budgets are charged the first
time a saved query is run but not for subsequent runs of the saved query
during the same page-load. This is accomplished with a `savedQuery` parameter
in the options for `selectURL()` that names the query.


[Tracking bug #367440966](https://issues.chromium.org/issues/367440966) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5098690386329600) \| [Spec](https://github.com/WICG/shared-storage/pull/188)

<br />

### Private State Token API Permissions Policy default allowlist wildcard

Access to the Private State Token API is gated by Permissions Policy features.
Chrome 132 updates the default allowlist for both `private-state-token-issuance`
and `private-state-token-redemption` features from `self` to `*` (wildcard).


[ChromeStatus.com entry](https://chromestatus.com/feature/5205548434456576) \| [Spec](https://github.com/WICG/trust-token-api/pull/306)

<br />

### FedCM Mode API and Use Other Account API

Two new extensions for FedCM:

- **Mode** : The `active` mode allows websites to call FedCM inside a button click (for example, clicking on a **Sign-in to IdP** button), which requires FedCM to guarantee it will always respond with a visible user interface. 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 (for example, 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 into other accounts.


[Demo](https://fedcm-button.glitch.me/) \| [Tracking bug #370694829](https://issues.chromium.org/issues/370694829) \| [ChromeStatus.com entry](https://chromestatus.com/feature/4689551782313984) \| [Spec](https://github.com/w3c-fedid/FedCM/pull/660)

<br />

### File System Access for Android and WebView

This API enables developers to build powerful apps that interact with other
(non-Web) apps on the user's device using the device's file system. After a
user grants a web app access, this API allows the app to read or save changes
directly to files and folders selected by the user. Beyond reading and writing
files, this API provides the ability to open a directory and enumerate its
contents, as well as store file and directory handles in IndexedDB to later
regain access to the same content.

[File System access](https://developer.chrome.com/docs/capabilities/web-apis/file-system-access) shipped
on Desktop in Chrome 86, with Chrome 132 it's available on Android and WebView.


[The File System Access API](https://developer.chrome.com/docs/capabilities/web-apis/file-system-access) \| [Tracking bug #40091667](https://issues.chromium.org/issues/40091667) \| [ChromeStatus.com entry](https://chromestatus.com/feature/6284708426022912) \| [Spec](https://wicg.github.io/file-system-access)

<br />

### WebAuthn Signal API

Allows WebAuthn relying parties to signal information about existing credentials
back to credential storage providers, so that incorrect or revoked credentials
can be updated or removed from provider and system UI.

Learn more about [the Signal API for passkeys on Chrome desktop](https://developer.chrome.com/blog/passkeys-signal-api).


[Demo](https://signal-api-demo.glitch.me/) \| [Tracking bug #361751877](https://issues.chromium.org/issues/361751877) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5101778518147072) \| [Spec](https://pr-preview.s3.amazonaws.com/nsatragno/webauthn/pull/2093.html#sctn-signal-methods)

<br />

## Rendering and graphics

### WebGPU: 32-bit float textures blending

The `float32-blendable` GPU feature makes GPU textures with formats `r32float`,
`rg32float`, and `rgba32float` blendable.


[Tracking bug #369649348](https://issues.chromium.org/issues/369649348) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5173655901044736) \| [Spec](https://www.w3.org/TR/webgpu/#float32-blendable)

<br />

### WebGPU: Expose `GPUAdapterInfo` from `GPUDevice`

The GPUDevice `adapterInfo` attribute exposes the same `GPUAdapterInfo` as the
`GPUAdapter` object.


[Tracking bug #376600838](https://issues.chromium.org/issues/376600838) \| [ChromeStatus.com entry](https://chromestatus.com/feature/6221851301511168) \| [Spec](https://www.w3.org/TR/webgpu/#dom-gpudevice-adapterinfo)

<br />

### WebGPU: Texture view usage

Adds an optional field to WebGPU texture view creation to request a subset of
the usage flags from the source texture.

By default, texture view usage inherits from the source texture but there are
view formats which can be incompatible with the full set of inherited usages.
Adding a usage field to texture view creation allows the user to request a
subset of the source texture's usages that are valid with the view format and
specific to their intended usage of the texture view.

WebGPU implementations can also optimize the creation of low level resources
and improve performance when using views with more specialized usage flags.


[Tracking bug #363903526](https://issues.chromium.org/issues/363903526) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5155252832305152) \| [Spec](https://github.com/gpuweb/gpuweb/commit/b39d86d356eb759d7564bc7c808ca62fce8bbf3e)

<br />

## Origin trials

### Explicit compile hints with magic comments

This feature lets you attach information about which functions should be
eagerly parsed and compiled in JavaScript files. The information will be
encoded as magic comments.


[Origin Trial](https://developer.chrome.com/origintrials#/view_trial/4317826142741463041) \| [Explainer](https://explainers-by-googlers.github.io/explicit-javascript-compile-hints-file-based) \| [Tracking bug #42203853](https://issues.chromium.org/issues/42203853) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5100466238652416)

<br />

### `Document-Isolation-Policy`

`Document-Isolation-Policy` allows a document to enable `crossOriginIsolation`
for itself, without having to deploy COOP or COEP, and regardless of the
`crossOriginIsolation` status of the page. The policy is backed by process
isolation. Additionally, the document non-CORS cross-origin subresources will
either be loaded without credentials or will need to have a CORP header.


[Origin Trial](https://developer.chrome.com/origintrials#/view_trial/3670996646260375553) \| [Tracking bug #333029146](https://issues.chromium.org/issues/333029146) \| [ChromeStatus.com entry](https://chromestatus.com/feature/5141940204208128) \| [Spec](https://wicg.github.io/document-isolation-policy)

<br />

## Deprecations and removals

### `navigator.storage` no longer an `EventTarget`

`navigator.storage` was made an `EventTarget` for the Storage Pressure Event,
which never made it past the prototype phase. This dead code is being removed
and as a result, `navigator.storage` will no longer extend `EventTarget`.


[ChromeStatus.com entry](https://chromestatus.com/feature/5132158480678912) \| [Spec](https://storage.spec.whatwg.org/)

<br />

### Remove prefixed `HTMLVideoElement` fullscreen APIs

The prefixed `HTMLVideoElement` fullscreen APIs have been deprecated from Chrome.

They were replaced by the `Element.requestFullscreen()` API, which first
shipped unprefixed in Chrome 71, in 2018. As of 2024, most browsers have had
support for the unprefixed APIs for a few years now.

Chrome 132 removes the following from `HTMLVideoElement`:

- The `webkitSupportsFullscreen` attribute.
- The `webkitDisplayingFullscreen` attribute.
- The `webkitEnterFullscreen()` method.
- The `webkitExitFullscreen()` method. Note the different capitalization of the "S" in FullScreen.
- The `webkitEnterFullScreen()` method.
- The `webkitExitFullScreen()` method.

These methods are now only aliases for the modern API. Their use has declined
steadily over the years.


[ChromeStatus.com entry](https://chromestatus.com/feature/5111638103687168)

<br />

<br />

## Further reading

Looking for more? Check out these additional resources.

- [What's new in Chrome 132](https://developer.chrome.com/blog/new-in-chrome-132)
- [What's new in Chrome DevTools 132](https://developer.chrome.com/blog/new-in-devtools-132)
- [ChromeStatus.com updates for Chrome 132](https://chromestatus.com/features#milestone%3D132)
- [Chrome release calendar](https://chromiumdash.appspot.com/schedule)
- [Upcoming deprecations](https://chromestatus.com/features#browsers.chrome.status%3A%22Deprecated%22)
- [Upcoming removals](https://chromestatus.com/features#browsers.chrome.status%3A%22Removed%22)

## Download Google Chrome


Download Chrome for
[Android](https://play.google.com/store/apps/details?id=com.android.chrome),
[Desktop](https://www.google.com/chrome/), or
[iOS](https://apps.apple.com/us/app/google-chrome/id535886823).

<br />