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 8 new features.
Fetch Priority provides developers a way to indicate a resource's relative priority to the browser, allowing more control over the order resources are loaded. Many factors influence a resource's priority in browsers. These include type, visibility, and preload status of a resource. This introduces a developer-set "fetchpriority" attribute to HTML elements and a "priority" property to the fetch API allowing developers to influence the computed priority of a resource. Supported fetchpriority values are auto, low, and high. #
This feature was specified in this Spec.
This is a recent change [1] to the spec for parsing the windowFeatures argument to window.open(). Previous to this change, window.open(url,'','popup=true') interpreted the 'popup=true' to mean popup is false. With this change, 'true' counts as a truthy value. [1] https://github.com/whatwg/html/pull/7425 #
This feature was specified in this Spec.
Extends the MediaCapabilities API to support WebRTC streams. The MediaCapabilities API helps web sites to make informed decisions on what codec, resolution, etc. to use for video playback by providing information about whether a configuration is supported and also whether the playback is expected to be smooth. This feature extends the MediaCapabilities API to also include WebRTC streams. #
This feature was specified in this Spec.
Dedicated workers loaded from a secure (HTTPS) origin yet instantiated by insecure (non-HTTPS) contexts are no longer considered secure. This results in the following web developer facing changes inside such worker contexts: - `self.isSecureContext` is now `false` - `self.caches` and `self.storageFoundation` are no longer available This aligns Blink behavior with the specification and Gecko. #
This feature was specified in this Spec.
Following the recent HIDDevice forget() addition[1] to the web platform, the USBDevice forget() method allows web developers to voluntarily revoke a permission to a USBDevice that was granted by a user. [1] https://groups.google.com/a/chromium.org/g/blink-dev/c/Fk-IJF63UWc #
This feature was specified in this Spec.
Docs: https://web.dev/usb/#revoke-access
No linked samplesMake USBConfiguration, USBInterface, USBAlternateInterface, and USBEndpoint instances returned by the accessors on USBDevice === comparable. #
The font-palette CSS property allows selecting a palette from a color font. In combination with the @font-palette-values at-rule, custom palettes can be defined. Use cases: designs where an icon or emoji font is used in combination with dark or light mode, or multi-colored icon fonts that are colorised using font-palette to harmonise with the content's color scheme. font-palette increases efficiency of color font uses, as no server roundtrip is needed for changing the colors of the font. #
This feature was specified in this Spec.
Samples: Plakato Color Grade (currently polyfilled): https://underware.nl/fonts/plakato/features/color/
HWB (short for Hue-Whiteness-Blackness) is another method of specifying sRGB colors, similar to HSL, but often even easier for humans to work with. It describes colors with a starting hue, then a degree of whiteness and blackness to mix into that base hue. https://drafts.csswg.org/css-color/#the-hwb-notation #
This feature was specified in this Spec.
This release of Chrome had 5 new origin trials.
This API measures ad conversions (e.g. purchases) and attributes them to ad interactions without using cross-site persistent identifiers like third-party cookies. The API allows measurement through both event-level reports sent directly from the browser, and aggregatable reports which can be processed through a trusted service to create summary reports of attribution data. An earlier version of this API was in Origin Trial from Chrome 86 through Chrome 97 which only supported click-through #
This feature was specified in this Spec.
A collection of APIs to facilitate advertising: FLEDGE, Topics, Fenced Frames and Attribution Reporting.
Provides a privacy advancing API to facilitate interest group based advertising. The Protected Audience API shifts the interest data and the final ad decision browser-side instead of server-side, offering many advantages: strong privacy guarantees, as well as time limits on group membership, transparency into how the advertiser interest groups are built and used, and granular or global controls over this type of ad targeting.
This feature was specified in this Spec.
Calls to setTimeout(..., 0) were previously clamped to a 1 ms timeout, instead of resulting in a callback as soon as possible. This clamping is being removed. To get the old behavior, use setTimeout(..., 1) instead. #
This feature was specified in this Spec.
The intent of the Topics API is to provide callers (including third-party ad-tech or advertising providers on the page that run script) with coarse-grained advertising topics that the page visitor might currently be interested in. These topics will supplement the contextual signals from the current page and can be combined to help find an appropriate advertisement for the visitor. Explainer: https://github.com/jkarlin/topics
This feature was specified in this Spec.
This release of Chrome had 1 are available behind a flag.
The Web SQL Database standard was first proposed in April 2009 and abandoned in November 2010. Gecko never implemented this feature and WebKit deprecated this feature in 2019. The W3C encouraged those needing web databases to adopt Web Storage or Indexed Database. Ever since its release, it has made it incredibly difficult to keep our users secure. SQLite was not initially designed to run malicious SQL statements, and yet with WebsQL we have to do exactly this. Having to react to a flow of stability and security issues is an unpredictable cost to the storage team. With SQLite over WASM as its official replacement, we want to remove WebSQL entirely. #
This feature was specified in this Spec.
Docs: https://developer.chrome.com/blog/deprecating-web-sqlhttps://docs.google.com/document/d/1bTj_nDqbdvE102sCm3KuwvN5c_HneLNPl9mmPeUjG4M/edit?usp=sharinghttps://docs.google.com/document/d/1CDdEO65pCIo60NM8CWHNNN7EunJ-wd8v1dGUxTOBJrM/edit?resourcekey=0-R0fxP199QQ-8gnMqzmQyrw
No linked samplesTo 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.
We intend to deprecate and remove usage of WebSQL in third party contexts. Deprecation is targeted for M94 and removal is targeted for M97. #
This feature was specified in this Spec.
This release of Chrome had 0 features removed.