Chrome version: 151, 150, 149, 148, 147, 146, 145, 144, 143, 142, 141, 140, 139, 138, 137, 136, 135, 134, 133, 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 9 new features.
Implements "overflow-inline" and "overflow-block" media features. Allows to distinguish styles for displays with different overflow characteristics. #
This feature was specified in this Spec.
Implements "update" media feature. Allows to distinguish styles for print, slow and fast output displays: print - for documents on the paper; slow - for e-ink and underpowered displays; fast - regular computer displays. #
This feature was specified in this Spec.
Adds a way to get the values of multiple Set-Cookie headers without combining them. In HTTP, Set-Cookie is a special header for historical reasons because it can appear multiple times in a response but cannot be combined, unlike other headers. Headers objects don't currently support having multiple values of the Set-Cookie header, and this feature adds that capability. #
This feature was specified in this Spec.
Docs: https://github.com/whatwg/fetch/issues/973#issuecomment-902578584https://github.com/whatwg/fetch/issues/973#issuecomment-954815921
No linked samplesIntroduces linear() easing function that allows linear interpolation between a number of points. It makes it possible to approximate complex functions by linear interpolation. #
This feature was specified in this Spec.
Add a size getter to URLSearchParams. It's useful to check whether there are any query parameters in a URLSearchParams object. #
This feature was specified in this Spec.
Adds support for the WebAuthn largeBlob [1] client authenticator extension. This extension allows relying parties to store opaque data associated to a credential. [1] https://w3c.github.io/webauthn/#sctn-large-blob-extension #
This feature was specified in this Spec.
Samples: https://webauthn-large-blob.glitch.me
WebGPU is the successor to the WebGL and WebGL 2 graphics APIs for the Web. It provides modern features such as “GPU compute” as well as lower overhead access to GPU hardware and better, more predictable performance. WebGPU is developed by the “GPU for the Web” W3C community group. #
This feature was specified in this Spec.
Docs: https://gpuweb.github.io/gpuwebhttps://gpuweb.github.io/gpuweb/wgslhttps://gpuweb.github.io/gpuweb/explainer
Samples: https://github.com/austinEng/webgpu-samples
WebGPU is the successor to the WebGL and WebGL 2 graphics APIs for the Web. It provides modern features such as “GPU compute” as well as lower overhead access to GPU hardware and better, more predictable performance. WebGPU is developed by the “GPU for the Web” W3C community group. WebGPU previously launched on Windows, MacOS, and ChromeOS in M113. See https://chromestatus.com/feature/6213121689518080 for details.
This feature was specified in this Spec.
Docs: https://gpuweb.github.io/gpuwebhttps://gpuweb.github.io/gpuweb/wgslhttps://gpuweb.github.io/gpuweb/explainer
Samples: https://github.com/austinEng/webgpu-samples
image-set() is a CSS type for specifying a range of image options, such as different images for different screen densities, and letting the browser select the best one. It can be used with CSS properties such as background-image. This feature adds the unprefixed "image-set" type so authors no longer need to use "-webkit-image-set". The implementation has also been brought up to the current spec with new resolution units (dppx, dpi, dpcm), image type support (e.g., type("image/avif")), raw urls without "url()", and gradient image options. #
This feature was specified in this Spec.
This release of Chrome had 4 new origin trials.
Note: this has launched in Chrome 115 We intend to partition a number of APIs in 3rd party contexts. This effort is focused on partitioning APIs above the network stack. This includes quota-managed storage, service workers, and communication APIs (like BroadcastChannel). See the explainer for more details: https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md There is also a deprecation trial available as well as an enterprise policy: https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/ https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting #
To make the web user experience more instant, the user agent (UA) could pre-connect to the server, prefetch resources, or prerender them ahead of time. These actions are referred to as preloading actions. Since performing any preloading action may cause side effects (e.g. log the user out) and has an overhead (e.g. extra data/cpu usage), to perform the action the UA should know if the action is safe to perform and also if it is worth performing. Being able to consistently determine which actions are safe for a given target without feedback from the developer is not an easy task. Speculation rules expose the necessary API to let developers specify that. Adding the eagerness field to the speculation rules will let the developers control how eagerly the browser preloads links in order to balance the performance advantage against resource overhead. This field accepts one of "conservative", "moderate" or "eager" strings as the value, and it is applicable to both "prefetch" and "prerender" actions and both "list" or "document" sources. If not explicitly specified, list rules default to "eager" and document rules default to "conservative". #
WebGPU exposes an API to create opaque "external texture" objects from HTMLVideoElement. These object can be used to sample the video frames efficiently, potentially in a zero-copy way directly from the source YUV data. However the WebGPU specification for the first version of WebGPU does not allow creating GPUExternalTextures from WebCodecs VideoFrame objects. This capability is important for advanced video processing applications that are already using WebCodecs and would like to integrate WebGPU in the video processing pipeline. This feature adds support for using a VideoFrame as the source for a GPUExternalTexture and a copyExternalImageToTexture call. #
This feature was specified in this Spec.
Docs: https://github.com/gpuweb/gpuweb/issues/1380
Samples: https://webgpu.github.io/webgpu-samples/samples/videoUploadingWebCodecs
RTCPeerConnection has two versions of getStats(), one that is spec-compliant returning the report via resolving a promise, and one that is non-standard returning a very different report via a callback as the first argument. The callback-based was removed in M117, with a Deprecation Trial available until M121. As of M122, the API does not anymore, even if you use the Deprecation Trial. #
This release of Chrome had 4 are available behind a flag.
To comply with HTML standard, there are two new changes on how the cancel dialog gets prompted for beforeunload event. 1. If event.preventDefault() is called, prompt cancel dialog. 2. If event.returnValue is the empty string, do not prompt cancel dialog.
This feature was specified in this Spec.
We implement the WebAssembly extended-const proposal according to https://github.com/WebAssembly/extended-const. Specifically, we add i32.add, i32.sub, i32.mul, i64.add, i64.sub and i64.mul to the list of constant instructions. #
This feature was specified in this Spec.
WebGPU exposes an API to create opaque "external texture" objects from HTMLVideoElement. These object can be used to sample the video frames efficiently, potentially in a zero-copy way directly from the source YUV data. However the WebGPU specification for the first version of WebGPU does not allow creating GPUExternalTextures from WebCodecs VideoFrame objects. This capability is important for advanced video processing applications that are already using WebCodecs and would like to integrate WebGPU in the video processing pipeline. This feature adds support for using a VideoFrame as the source for a GPUExternalTexture and a copyExternalImageToTexture call. #
This feature was specified in this Spec.
Docs: https://github.com/gpuweb/gpuweb/issues/1380
Samples: https://webgpu.github.io/webgpu-samples/samples/videoUploadingWebCodecs
Provides a method for yielding control to the browser, which can be used to break up long tasks. Awaiting the promise returned by scheduler.yield() causes the current task to yield, continuing in a new browser task. This can be used to improve responsiveness issues caused by long tasks. Continuations are prioritized to mitigate performance problems of existing alternatives. #
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 3 features deprecated.
Removes the maxFragmentCombinedOutputResources limit from WebGPU, which has been deemed to be unnecessary. This limit applies additional restrictions on use of the WebGPU API, but is being removed from the standard. This removal is a minor breaking change. #
This feature was specified in this Spec.
* Chrome shipped support for Web Push Notifications using FCM Sender IDs M42 (March 2015), after which we added support for a standardized authentication path in M52 (July 2016). * We have been deprecating support for FCM Sender IDs since, adding console warnings and blocking the list of senders in 2019, and blocking all new subscription requests using sender IDs in 2020. Today we see <1000 unique senders still relying on Chrome to receive such messages in a 7-day window -- this is a tiny portion of full Web Push usage. * Following this prolonged deprecation path, we're now proceeding to remove support for Chrome to receive messages for subscriptions that were once created using FCM Sender IDs. Users who receive such messages will stop receiving them until they re-visit the sender's website, at which time it has the chance to renew the subscription. We unfortunately cannot automatically update such subscriptions. The roll-out will be done server-side. #
Secure Payment Confirmation (SPC) is a Web API to support streamlined authentication during a payment transaction. It builds on top of WebAuthn to bring strong authentication to payment flows. In the initial spec and implementation of SPC, the output CollectedClientAdditionalPaymentData dictionary[0] of the cryptogram contained a parameter named 'rp'. This was renamed in the specification[1] to 'rpId' to align with WebAuthn, and Chrome is changing its implementation to match (that is, adding 'rpId' and removing 'rp'). [0]: https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary [1]: https://github.com/w3c/secure-payment-confirmation/pull/198 #
This feature was specified in this Spec.
This release of Chrome had 0 features removed.