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 19 new features.
Dialog elements can be closed through a variety of mechanisms, sometimes developers want to have the ability to prevent closure. To achieve this dialogs fire a cancel event. Originally this was only fired via a close request (e.g. ESC key press), recently a `requestClose()` JS function was added which also fires the cancel event. The 'request-close' command brings that new ability to the declarative invoker commands API. #
This feature was specified in this Spec.
This feature consists in exposing to the Web the audio level of an encoded frame transmitted via RTCPeerConnection and exposed using WebRTC Encoded Transform. #
This feature was specified in this Spec.
Custom Functions are similar to custom properties, but instead of returning a single, fixed value, they return values based on other custom properties, parameters, and conditionals. #
This feature was specified in this Spec.
When the transition related properties change, they are only supposed to affect newly started transitions. This means that if you change the transition properties, unless you also change the properties which have active transition animations, those transition animations will continue with the previously specified duration, easing, etc. Blink incorrectly canceled transitions when the transition property was set to "none", even though it doesn't cancel them if you only change the transition-duration. With this feature, blink will be consistent with webkit and gecko, allowing active transitions to continue running, unless/until their property value changes triggering a new transition update.
This feature was specified in this Spec.
Samples: https://jsbin.com/tesuliz/edit?html,css,js,output
Enable styling corners, on top of the existing border-radius, by expressing the shape/curvature of the corner as a superellipse. This allows shapes like squircles, notches, scoops etc., and animating between them. #
This feature was specified in this Spec.
This feature ensures developers receive only crash reports by specifying the endpoint named `crash-reporting `. By default, crash reports are delivered to the `default` endpoint which receives many other kinds of reports besides crash reports. Developers can supply a separate URL to the well-known endpoint named `crash-reporting`, to direct crash reports there, instead of the `default` endpoint. See https://wicg.github.io/crash-reporting/#crash-reports-delivery-priority. #
This feature was specified in this Spec.
Docs: https://github.com/WICG/crash-reporting/pull/30
No linked samplesShortens the time to freezing background pages (and associated workers) from 5 minutes to 1 minute on Android. See the original intent to ship for background: https://groups.google.com/a/chromium.org/g/blink-dev/c/NKtuFxLsKgo/m/XmQganj9EAAJ. Android 15 has introduced a 1 minute background network restriction on apps, and faster background freezing aligns with this OS-level restriction which causes any network requests made by the site to fail after the 1 minute mark anyways. #
When blocked by CSP, Chromium currently throws SecurityError from constructor of Worker and SharedWorker. Spec requires CSP to be checked as part of fetch and fires error event asynchronously instead of throwing exception when script runs "new Worker(url)" or "new SharedWorker(url)". This aims to make Chromium spec conformant, which is not throwing during constructor and fires error event asynchronously. #
This feature was specified in this Spec.
This feature adds on-device speech recognition support to the Web Speech API, allowing websites to ensure that neither audio nor transcribed speech are sent to a third-party service for processing. Websites can query the availability of on-device speech recognition for specific languages, prompt users to install the necessary resources for on-device speech recognition, and choose between on-device or cloud-based speech recognition as needed.
This feature was specified in this Spec.
This launch enables TCP port randomization on versions of Windows (2020 H1 or later) where we do not expect to see issues with re-use of prior ports occurring too fast (causing rejection due to timeouts on port re-use). The rapid port re-use issue arises from the Birthday problem, where the probability of randomly re-picking a port already seen rapidly converges with 100% for each new port chosen when compared to port re-use in a sequential model. #
Currently, scroll anchoring algorithm selects priority candidates when they are available as anchor targets. The priority candidates are currently a focused editable element and find-in-page highlights. This can cause suboptimal user experience if there is a large focused contenteditable element that has content changed offscreen (the cursor ends up being shifted as a consequence). A simple fix is to change the algorithm: instead of selecting the priority candidate as the anchor, chose the candidate as the scope/root of the regular anchor selection algorithm which will select the deepest onscreen element as the anchor. This feature tracks this change.
When the fallback is not taken, var()/attr() functions evaluate without looking for cycles in that fallback.
Chromium now recognizes all valid JSON MIME types as defined by the WHATWG mimesniff specification. This includes any MIME type whose subtype ends with “+json”, in addition to the traditional application/json and text/json. This change ensures that web APIs and features relying on JSON detection behave consistently with the web platform standard and other browsers. A key motivation for this change is to fix JSON module import behavior, where previously valid JSON MIME types like text/html+json and image/svg+json would fail to load as modules. Draft CL: https://chromium-review.googlesource.com/c/chromium/src/+/6525687 Related Issues: https://github.com/whatwg/mimesniff/issues/112. The consensus was to retain the broad definition of JSON MIME types—including all */*+json.
This feature was specified in this Spec.
As CSS allows fine control over font features using 'font-feature-settings' at the element level, Chromium-based browsers currently lack support for these properties within '@font-face' declarations. This feature supports the string-based syntax for font-feature-settings as defined in CSS Fonts Level 4. Invalid or unrecognized feature tags will be ignored per specification. No binary or non-standard forms are supported. As OpenType fonts become more widely adopted, this enhancement will improve typographic control, reduce redundancy, and support a more scalable, modern approach to web design. #
This feature was specified in this Spec.
Adds a "scope_extensions" web app manifest field that enables web apps to extend their scope to other origins. Example usage: { "name": "Example", "display": "standalone", "start_url": "/index.html", "scope_extensions": [ {"type" : "origin", "origin" : "https://example.com"} ] } This allows sites that control multiple subdomains and top level domains to be presented as a single web app. Requires listed origins to confirm association with the web app using a .well-known/web-app-origin-association configuration file. { "https://sample-app.com/": { "scope": "/" } } #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1-idhx8heajbPYl3cdXFVCjpIuf96cRa_DrRk6147ELI/edit?usp=sharing
Samples: https://main-pwa-origin-2.glitch.me
The 'core-features-and-limits' feature signifies a WebGPU adapter and device support the core features and limits of the spec. Explainer: https://gist.github.com/greggman/0dea9995e33393c546a4c2bd2a12e50e #
This feature was specified in this Spec.
Functionality added to the WebGPU spec after its first shipment in a browser. The “texture-compression-bc-sliced-3d” and “texture-compression-astc-sliced-3d” WebGPU features add respectively 3D texture support for BC and ASTC compressed formats. #
This feature was specified in this Spec.
Samples: https://webgpu.github.io/webgpu-samples/?sample=volumeRenderingTexture3D
Exposes several new mechanisms to customize the behavior of the depth sensing feature within a WebXR session, with the goal of improving the performance of the generation or consumption of the depth buffer. The key mechanisms exposed are: the ability to request the raw or smooth depth buffer, the ability to request that the runtime stop or resume providing the depth buffer, and the ability to expose a depth buffer that does not align with the user's view exactly, so that the user agent does not need to perform unnecessary re-projections every frame. #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1Nx3hCHqq8UZ6E1nxctmkr6BBQKwf3AgIai7WVsQ_nUM/edit?usp=sharing
Samples: https://immersive-web.github.io/webxr-samples/layers-samples/proj-multiview-occlusion.htmlhttps://immersive-web.github.io/webxr-samples/proposals/phone-ar-depth-gpu.htmlhttps://immersive-web.github.io/webxr-samples/proposals/phone-ar-depth.html
This is a Javascript API to provide an easier way to check if the Secure Payment Confirmation[1] feature is available. Currently, the only way to determine SPC’s availability is to create a PaymentRequest with the required parameters[2], which is clunky and difficult in the case where a developer wants to check for SPC before starting to process a payment. [1] https://www.w3.org/TR/secure-payment-confirmation/ [2] https://github.com/w3c/secure-payment-confirmation/issues/81#issuecomment-868473461 #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/1ZgNRqyJyB36ItqUr6vtlJ19rd7fqpS7Vo0w_GSMz0DA/edit?tab=t.0#heading=h.jdq7x74yk5iphttps://docs.google.com/document/d/10zFazJRJMwNLKmH-GJRFMDs4rONIO5kF8TvdFydmGek/edit
No linked samplesThis release of Chrome had 8 new origin trials.
This update adds a new option, `extendedLifetime: true`, to the `SharedWorker` constructor. This new option requests that the shared worker be kept alive even after all current clients have unloaded. This allows pages to perform asynchronous work that requires JavaScript after a page unloads, without needing to rely on a service worker. #
This feature was specified in this Spec.
Allow web developers to indicate that a fetch() request should be retried, to have a greater guarantee on it being reliably sent, even if network is flaky. This is especially important for keepalive fetches, where the request might outlive the document, which can no longer watch for its failure and do manual retry. We intend to only support this for keepalive fetches for now because of implementation simplicity, and also the fact that all the use cases would benefit from being keepalive first. #
Docs: https://docs.google.com/document/d/1C9lAn3tqXsrjxiid1qCC9qSL7jfA1PZdoo2lgL8L5Pw/edit?tab=t.0
No linked samplesWe propose to add a new render blocking token full-frame-rate to the blocking attributes. When the renderer is blocked with the full-frame-rate token, the renderer will work at a lower frame rate so as to reserve more resources for loading. An example use case of the proposed API will be: The web page contains an element <link rel="expect" href="#critical-content" blocking="full-frame-rate"/> in the page head. After parsing this element, the renderer will work at an implementation-specific lower frame rate. After the #critical-content element is parsed, the renderer will restore its frame rate. It is worth noting that the frame rate instructions will be informative. The browser may decide to lower the frame rate before parsing a blocking element. For instance, the frame rate may be lowered at the very beginning of the loading phase. On the other hand, the browser may also decide to restore the frame rate before the frame rate blocking element list gets empty. For instance, the frame rate may be restored after a timeout or certain user interactions. #
Prompt API gives web developers direct access to a browser-provided on-device AI language model. The API design offers fine-grained control, aligned with cloud API shapes, for progressively enhancing sites with model interactions tailored to individualized use cases. This complements task-based language model APIs, for example, Summarizer API, as well as a variety of APIs and frameworks for generalized on-device inference with developer-supplied ML models. The initial implementation supports text, image, and audio inputs. In addition, response constraints ensure that generated text conforms with predefined regex and JSON schema formats. This supports a variety of use cases, from generating image captions and performing visual searches to transcribing audio, classifying sound events, generating text following specific instructions, and extracting information or insights from multi-modal source material. This API has been shipped in [Chrome Extensions](https://chromewebstore.google.com/category/extensions). An enterprise policy [GenAILocalFoundationalModelSettings](https://chromeenterprise.google/policies/#GenAILocalFoundationalModelSettings) is available to disable the underlying model downloading, which would render this API unavailable. Enterprise admins can also set the [BuiltInAIAPIsEnabled](https://chromeenterprise.google/policies/#BuiltInAIAPIsEnabled) policy to block Built-In AI API usage, while still permitting other on-device GenAI features. Language support log: - Chrome M139 and earlier only supported English ('en') - Chrome M140 added support for Spanish and Japanese ('es' and 'ja') #
This feature was specified in this Spec.
Samples: https://chrome.dev/web-ai-demos/prompt-api-playgroundhttps://chrome.dev/web-ai-demos/prompt-api-weatherhttps://ai.etiennenoel.com/prompt-apihttps://ai.etiennenoel.com/multimodal-prompt-apihttps://www.clarkduvall.com/ai
This experiment evaluates the impact of changing the per-profile TCP socket pool size from 256 (the current default), down to 255, and up to 257, 512, and 1024 (possibly at 1-2 numbers between those based on findings). We will study the performance impact of these changes in stages, starting with 255 and 257. If no ill effects are seen, 512 will be evaluated and then 1024 after that. We expect that some platforms (e.g., mobile or older OS versions) will have to drop off as we get to the 512/1024 experiments. We will study changes to both normal and websocket pool global limits, but will not touch the per-host or per-proxy limits. This experiment will not be rolled directly into a full launch, but rather evaluated for use in a future experiment that attempts to partition the TCP socket pool to mitigate a network traffic timing attack. See the motivation section for more. #
This feature implements two new PerformanceEntry types, added to the performance timeline (i.e. via PerformanceObserver): "soft-navigation", and "interaction-contentful-paint". The `InteractionContentfulPaint` PerformanceEntry reports any new Contentful Paints within parts of the page that are known to have been previously modified by an Interaction. The `PerformanceSoftNavigation` PerformanceEntry reports on same document history state changes that are known to have been initiated by an Interaction, but only if it has also made some contentful update to the page. This new entry helps define the criteria, and establish a new "time origin" for "slicing" the performance timeline by "soft-navigations" (i.e. attributing all performance data to the correct url/route, rather than the initial URL of the initial document). Both entries rely on a common infrastructure: - Observing new Interactions (via Event Timing integrations) - Establishing a Task-scheduling-persistent "context"(i.e. AsyncContext, via Task Attribution) - Observing effects such as dom content modifications, or same document history state changes, and checking if the currently running task has an "active context" to attribute this change to. - Integration with Paint Timing and LCP (partially modelling new Container Timing concepts). #
This feature was specified in this Spec.
A new mode for navigator.credentials.get() that causes browser sign-in UI to be displayed to the user if there is a passkey or password for the site that is immediately known to the browser, or else rejects the promise with NotAllowedError if there is no such credential available. This allows the site to avoid showing a sign-in page if the browser can offer a choice of sign-in credentials that are likely to succeed, while still allowing a traditional sign-in page flow for cases where there are no such credentials. #
This feature was specified in this Spec.
Docs: https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation
Samples: https://deephand.github.io/webauthn-immediate-demo
Adds an opt-in, lightly restricted subset of the WebGPU API capable of running older graphics APIs such as OpenGL and Direct3D11. By opting into this mode and obeying its constraints, developers can extend the reach of their WebGPU applications to many older devices that do not have the modern, explicit graphics APIs that core WebGPU requires. For simple applications, the only required change is to specify the "compatibility" featureLevel when calling requestAdapter. For more advanced applications, some modifications may be necessary to accommodate the mode's restrictions. Since Compatibility mode is a subset, the resulting applications are also valid WebGPU Core applications and will run even on user agents that do not support Compatibility mode. #
This feature was specified in this Spec.
Samples: https://webgpu.github.io/webgpu-samples/?sample=helloTrianglehttps://webgpu.github.io/webgpu-samples/?sample=computeBoidshttps://webgpu.github.io/webgpu-samples/?sample=deferredRendering
This release of Chrome had 5 are available behind a flag.
CSS Gap Decorations enables styling of gaps in container layouts like Grid and Flexbox, similar to ‘column-rule’ in multicol layout. This feature is highly requested by web authors who must use hacks to style the gaps in Grid and Flexbox layouts today. #
This feature was specified in this Spec.
Samples: https://microsoftedge.github.io/Demos/css-gap-decorations
Allow web developers to indicate that a fetch() request should be retried, to have a greater guarantee on it being reliably sent, even if network is flaky. This is especially important for keepalive fetches, where the request might outlive the document, which can no longer watch for its failure and do manual retry. We intend to only support this for keepalive fetches for now because of implementation simplicity, and also the fact that all the use cases would benefit from being keepalive first. #
Docs: https://docs.google.com/document/d/1C9lAn3tqXsrjxiid1qCC9qSL7jfA1PZdoo2lgL8L5Pw/edit?tab=t.0
No linked samplesA JavaScript API for proofreading input text with suggested corrections, backed by an AI language model. #
This feature was specified in this Spec.
Updates the UX elements for the SPC dialog on Android Chrome. Other than just UX presentation the following are being added: - Allowing merchants to provide an optional list of payment entity logos related to the payment that will be displayed in the UX (https://github.com/w3c/secure-payment-confirmation/pull/294). - Returning different output states back to the merchant depending on whether the user wants to continue the transaction without SPC or to cancel the transaction (https://github.com/w3c/secure-payment-confirmation/pull/292). Currently, we only send a single output state back for both cases. - A new payment detail label field will be added to the payment instrument so the text be presented across 2 lines in SPC (https://github.com/w3c/secure-payment-confirmation/pull/298) #
This feature was specified in this Spec.
Docs: https://github.com/w3c/secure-payment-confirmation/issues/197https://github.com/w3c/secure-payment-confirmation/issues/275https://github.com/w3c/secure-payment-confirmation/pull/292https://github.com/w3c/secure-payment-confirmation/pull/294https://github.com/w3c/secure-payment-confirmation/pull/298
Samples: https://rsolomakhin.github.io/pr/spc-payment-entities-logoshttps://rsolomakhin.github.io/pr/spc-opt-out
Allows a website to install a web app. The API provides 3 signatures, with 0, 1, and 2 parameters, respectively. When invoked, the website installs either itself, or another site from a different origin, as a web app (depending on the provided parameters). All 3 signatures will be experimented with in parallel. *Terminology - A site installing itself is a "current document install". A site installing another site is a "background document install". #
This feature was specified in this Spec.
Docs: https://docs.google.com/document/d/12nSXJLm8mW0gWZ_yjlXfrV8r9gwJliVt4WVa-209-KA/edit?tab=t.0
Samples: https://kbhlee2121.github.io/pwa/web-install/index.htmlhttps://microsoftedge.github.io/Demos/pwa-pwastore
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.
Chrome 138 will be the last release to support macOS 11; Chrome 139+ will no longer support macOS 11, which is outside of its support window with Apple. Running on a supported operating system is essential to maintaining security. On Macs running macOS 11, Chrome will continue to work, showing a warning infobar, but will not update any further. If a user wishes to have their Chrome be updated, they need to update their computer to a support version of macOS. For new installations of Chrome 139+, macOS 12+ will be required.
Allowing automatic fallback to WebGL backed by the software renderer SwiftShader is deprecated and WebGL context creation will fail instead of falling back to SwiftShader. This was done for two primary reasons: 1. SwiftShader is a high security risk due to JIT-ed code running in Chromium's GPU process. 2. Users have a poor experience when falling back from a high-performance GPU-backed WebGL to a CPU-backed implementation. Users have no control over this behavior and it is difficult to describe in bug reports. SwiftShader is a useful tool for web developers to test their sites on systems that are headless or do not have a supported GPU. This use case will still be supported by opting in but is not intended for running untrusted content. To opt-in to lower security guarantees and allow SwiftShader for WebGL, run the chrome executable with the --enable-unsafe-swiftshader command-line switch. During the deprecation period, a warning will appear in the javascript console when a WebGL context is created and backed with SwiftShader. Passing --enable-unsafe-swiftshader will remove this warning message. Chromium and other browsers do not guarantee WebGL availability. Please test and handle WebGL context creation failure and fall back to other web APIs such as Canvas2D or an appropriate message to the user. #
There are known[1] security issues around charset auto-detection for ISO-2022-JP. Given that the usage is very low, and Safari does not support auto-detection of ISO-2022-JP, we will remove support for it to eliminate the security issues. [1]: https://www.sonarsource.com/blog/encoding-differentials-why-charset-matters/ #
This release of Chrome had 0 features removed.