Chrome version: 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 10 new features.
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-gesturehttps://docs.google.com/document/d/1yO5Ixgp6VNfYpGrqxezUmLaM-g_ZPGb16bxQ6_q9ln4
Samples: https://github.com/michaelwasserman/iwa-windowing-example
The font-size-adjust CSS property specifies that font size should be chosen based on the height of lowercase letters rather than the height of capital letters. It was once dropped since css 2.1, but newly defined in CSS3 font. #
This feature was specified in this Spec.
Docs: https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust
No linked samplesThe font-size-adjust CSS property adjusts the font size based on the height of lowercase letters rather than that of uppercase letters for consistency in readability. However, there have been voices that the adjusting metric is obscure and impractical. This new two-value syntax reflects such voices by allowing developers to specify a font metric for adjusting the size. This feature is standardized in CSS Font Module Level 5. #
This feature was specified in this Spec.
Samples: https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust
This makes user activations in a document picture-in-picture window usable inside its opener window and vice versa. This makes it more ergonomic to use user-activation-gated APIs, since often event handlers in the document picture-in-picture window are actually run in the opener's context, so the opener's context needs access to the user gesture. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1vtjK3iMEAjcfDCu-qZOYg2zAtTbhohmCX77T1Eu3usQ/edit?usp=sharing
Samples: https://steimelchrome.github.io/document-pip/user-gesture.html
The CSS content property allows developers to specify alternative text for accessibility with the following syntax: .has-before-content::before { content: url("cat.jpg") / "A cute cat"; } This functionality, where the alt text is given by a single string, is already supported in Chromium (https://chromestatus.com/feature/4550056227110912). However, the spec allows the alt text to be given by an arbitrary number of elements, which in addition to strings can be attr() functions or counters. For example: .has-before-content::before { content: url("cat.jpg") / "A cute " attr(data-animal); } This feature tracks the expansion of the Chromium implementation to support an arbitrary number of arguments as well as attr() functions in addition to strings. Note that this feature entry does *not* include the addition of counter support. #
This feature was specified in this Spec.
The corresponding implementation on the blink layer based on the w3c api change, which is to add the `ChapterInformation` attribute in the existing `MediaMetadata`. ThisChapterInformation applies to audio as well as video, since MediaSession is for both audio and video. See the propose: https://github.com/w3c/mediasession/issues/273 And the specs change pr: https://github.com/w3c/mediasession/pull/308 #
This feature was specified in this Spec.
Samples: https://googlechrome.github.io/samples/media-session/video.html
The ServiceWorker static routing API is an API used for routing the request to the network, the ServiceWorker fetch handler, or directly looking up from cache, and so on. Each route consists of a condition and a source, and the condition is used for matching the request. For Chromium implementations, the "or" condition is only the supported condition. However, to write the condition more flexibly, supporting the "not" condition is expected, which matches the inverted condition inside. #
This feature was specified in this Spec.
Makes the browser use the user's preferred color scheme to render the viewport scrollbars if the value of "page’s supported color schemes" is 'normal' or not specified, and the computed value of the color-scheme for the root element is 'normal'. Viewport scrollbars can be considered to be outside the web content. Therefore, the user agents should honor the user's preferred color scheme when rendering viewport scrollbars if page authors have not explicitly specified support for color schemes. #
This feature was specified in this Spec.
Functionality added to the WebGPU spec after its first shipment in a browser. Adds a synchronous GPUAdapter info attribute to retrieve same information about the physical adapter as with the asynchronous GPUAdapter requestAdapterInfo() method. A separate Intent will be sent to deprecate and remove the asynchronous GPUAdapter requestAdapterInfo() method. #
This feature was specified in this Spec.
Allow WebRTC Encoded Transform API to manipulate audio and video frame metadata. Some WebRTC Encoded Transform use cases involve manipulation of not only the payload of encoded video / audio frames but also its metadata. Some examples: * Altering the timestamp of a frame to introduce a delay, * Changing the mime type of the frame if the transform changes the type of the payload. * Forwarding of media to a new peer connection set up to use different metadata values Use cases: https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media https://w3c.github.io/webrtc-nv-use-cases/#auction Issue link: https://github.com/w3c/webrtc-nv-use-cases/issues/77 #
This feature was specified in this Spec.
This release of Chrome had 1 new origin trials.
Requires that private network requests for subresources from public websites may only be initiated from a secure context. Examples include internet to intranet requests and internet to loopback requests. This is a first step towards fully implementing Private Network Access: https://wicg.github.io/private-network-access/ #
This feature was specified in this Spec.
This release of Chrome had 5 are available behind a flag.
VideoFrame.copyTo() can convert pixel data to RGB pixel format Converting YUV video frames to RGB is often required for processing them in libraries like TensorFlow.js and OpenCV.js. Previously the only possible way to achieve this was rendering the frame on a canvas. Specifying VideoFrameCopyToOptions.format and VideoFrameCopyToOptions.colorSpace make it possible to convert frames to RGB pixel format by calling VideoFrame.copyTo() without having to use an extra canvas. #
This feature was specified in this Spec.
Docs: https://github.com/w3ctag/design-reviews/issues/951
No linked samplesThe CSS custom state pseudo-class is being renamed from :--foo to :state(foo). The new syntax, :state(foo), has been enabled by default, and now we have to deprecate and remove the :--foo syntax. Gecko and webkit never implemented the old syntax and they have both shipped the new syntax. We are currently shipping both the new syntax and the old syntax at the same time. There have been console errors and DevTools deprecations for the old syntax for many milestones already. Previous thread on this topic: https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/uRtWiqoHAQAJ The UseCounter is currently at 0.04% https://chromestatus.com/metrics/feature/timeline/popularity/3796 For Enterprise customers who need more time, please use the CSSCustomStateDeprecatedSyntaxEnabled policy. This policy will be removed in Chrome 131. #
This feature was specified in this Spec.
Dispatches selectionchange event per element when this element(input/textarea) provides a text selection or its selection changes. This is to match the latest specification of selectionchange event. This also matches Safari behavior. #
This feature was specified in this Spec.
Adds a hint to speculation rules that informs the navigation prerender cache that the URL to be prerendered expects to receive the same No-Vary-Search header in the response. The hint is useful because prerenders that depend on No-Vary-Search to match to navigations do not benefit the user if the navigation happens before prerender headers return from the server. Using the hint, the web browser will expect, but verify, that the No-Vary-Search hint matches with the No-Vary-Search header. If the No-Vary-Search hint does not match the No-Vary-Search header received then the web browser will send a new request. #
This feature was specified in this Spec.
Enables a prerender entry to match even if URL query parameters change. The No-Vary-Search HTTP response header declares that some or all parts of a URL's query can be ignored for cache matching purposes. It can declare that the order of query parameter keys should not cause cache misses, that specific query parameters should not cause cache misses or that only certain known query parameters should cause cache misses. It could apply to multiple caches, but this entry refers to support for prerender. #
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 1 features deprecated.
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.
This release of Chrome had 0 features removed.