Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 92 is beta as of June 3, 2021
Now that web apps are capable of reading and writing files, the next logical step is to let developers declare web apps as file handlers for files they create and process. The File Handling API allows you to do exactly this. For example, after a text editor PWA has registered itself as a file handler, you can right-click a .txt file in your operating system's file manager and instruct this PWA to (always or just once) open .txt files. This means PWAs are just a (double) click away from the file manager.
This improves the user experience for PWA use cases, making them more like OS apps than they are already. For example:
File Handling is starting an origin trial in 92 that is expected to run until around the end of August, 2021. For more information on this feature, see Let web applications be file handlers. For information about other origin trials in this release, see Origin Trials, below.
This version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Chrome Origin Trials dashboard. To learn more about origin trials in Chrome, visit the Origin Trials Guide for Web Developers. Microsoft Edge runs its own origin trials separate from Chrome. To learn more, see the Microsoft Edge Origin Trials Developer Console.
Shared Element Transitions allows a simple set of transitions in both single-page applications (SPAs) and multi-page applications (MPAs). This enhances the visual polish of pages with minimal effort by letting developers select from a set of user-agent provided transition effects. Without this, single-page app transitions are difficult since they require a careful coordination of animations and DOM manipulations to achieve the desired effect. Multi-page app transitions are, for the most part, not possible since each page can only control the contents of its own view. This origin trial is only for SPA use cases.
Most Android launchers now allow only three app shortcuts instead of the previously allowed four. A shortcut to the site settings was added to the application icon in the Android launcher, taking one of the available shortcut slots for the app. For more information, see Get things done quickly with app shortcuts.
Adds the size-adjust descriptor for @font-face allowing scaling of glyph sizes for a particular font face without affecting the CSS font-size and derived metrics such as em. CSS font-size can be seen as a scale factor for a box that the font draws in. Glyph sizes within that box vary between fonts, and size-adjust enables harmonising them across different fonts. That's why it reduces cumulative layout shift by matching up the fallback font and primary web font using this descriptor.
@font-face
font-size
Imperative slotting allows node-to-slot assignments without needing the slot attribute in markup. This enables dynamic slotting behavior based on input conditions and types. The feature originally shipped in Chrome 86; in this release some adjustments to the API have been made to ensure interoperability with other browsers.
This version of Chrome incorporates version 9.2 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent features in the V8 release notes.
A dayPeriod option (part of ECMA402 2021) has been added to the Intl.DateTimeFormat() method so the caller can format times such as "7 in the morning", "11 in the morning", "12 noon", "1 in the afternoon", "6 in the evening", "10 at night" (or in Chinese, "清晨7時", "上午11時", "中午12時", "下午1時" ,"下午6時" ,"晚上10時").
Intl.DateTimeFormat()
This enhances Intl.DateTimeFormat() to match what is already possible in C++ and Java by calling ICU and ICU4J. Without this feature, developers need to either format the quarter in the server or ship a set of day period patterns and hour to day period mappings from the server to client to perform such tasks.
Adds a new method named at(), to Array.prototype, String.prototype, and the TypedArray prototypes, that permit relative indexing with negative indices. For example: let arr = [1,2,3,4]; arr.at(-1); // Returns 4
at()
Array.prototype
String.prototype
TypedArray
let arr = [1,2,3,4]; arr.at(-1); // Returns 4
The ICU LocaleMatcher now implements the BestFitMatcher abstract operation to better match locale data.
SharedArrayBuffers on desktop platforms are now restricted to cross-origin isolated environments, matching the behavior recently shipped on Android and Firefox. A Cross-origin isolated page is considered a secure environment because it blocks loading cross-origin resources that are not opt-in and communicating with cross-origin windows. Only pages that opt-in to cross-origin isolation will be able to use SharedArrayBuffers. Learn more about the upcoming options at SharedArrayBuffer updates in Android Chrome 88 and Desktop Chrome 92.
SharedArrayBuffers
SharedArrayBuffer
Adds actions to the Media Session API, specifically "togglemicrophone", "togglecamera", and "hangup". This enables developers of video conferencing websites to handle these actions from the browser interface. For example, if the user puts their video call into a picture-in-picture window, the browser could display buttons for mute/unmute, turn-on/turn-off camera, and hanging up. When the user clicks these, the website handles them through the Media Session API. For more information, see the section from our recent article, or try our demo.
"togglemicrophone"
"togglecamera"
"hangup"
Chrome now accounts for the tainted origin flag when computing whether a fetched resource passes the timing allow origin check. The timing allow origin check is used in resource timing to determine whether the page can receive detailed timing information about a resource used in the page. The tainted origin flag impacts this check in cases where there are multiple redirects that cross origins. In those cases, the header should be '*'. In other words, it can no longer be a specific origin.
If a resource performs two cross-origin crosses (via redirects), then the developer needs to use Timing-Allow-Origin: * for the checks to pass. For example if a page on origin A fetches a resource on origin B, which redirects to a resource on origin C, then the tainted origin flag is set and the final resource needs to have Timing-Allow-Origin: * in order to receive detailed timing information."
Timing-Allow-Origin: *
Web applications can now register themselves as handlers of custom URL protocols or schemes using their web app manifests. Operating system applications often register themselves as protocol handlers to increase discoverability and usage. Websites can already register to handle schemes via registerProtocolHandler(), it is desirable to have web apps be first-class citizens and be launched directly when a custom-scheme link is invoked.
The Web Bluetooth API can now filter based on manufacturer data such as vendor ID and product ID. Developers have been able to prompt users through a browser picker to select a nearby Bluetooth device that matches their advertised name and services. However it hasn't been possible to filter nearby Bluetooth devices based on advertised manufacturer specific data. Manufacturer data is specified through new properties on options.filters, which is passed to Bluetooth.requestDevice(). For more information, see Communicating with Bluetooth devices over JavaScript or try our demo.
Bluetooth.requestDevice()
This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.
This feature, which enabled web-based payment handlers to receive paymentrequest events with non-URL, but standardized payment method identifiers, such as "basic-card" or "tokenized-card", has been removed.
paymentrequest
"basic-card"
"tokenized-card"
Updates
A little over a year ago we announced our plans to reduce the granularity of information available from the User-Agent string, which is sent by default for every HTTP request. Shortly after, we made the decision to put this effort on pause so as not to create an additional migration burden on the web ecosystem in the early days of the COVID-19 pandemic. Since then, we’ve spent a lot of time gathering valuable feedback from the ecosystem, proposing ergonomic improvements to the User-Agent Client Hints API (UA-CH)—our proposed replacement for content negotiation and detection—as well as making web compatibility fixes.
UA-CH is now shipping by default in Chrome (since M89). We’ve also started the roll-out of both Client Hints Reliability mechanisms (Critical-CH & ACCEPT_CH) to address use cases where hints are needed on the first request. While we don’t yet have exact dates and milestones to announce for the planned User-Agent string reduction changes, we’re ready to resume our efforts on this front.
That said, we feel it's important to proceed in a way that gives the ecosystem and developers sufficient time to test use cases, provide feedback, and migrate to UA-CH where appropriate, which is why no User-Agent string changes will be coming to the stable channel of Chrome in 2021. Our intent with this post is to provide transparency into our thinking and roadmap early on so you can plan to adapt accordingly.
We plan to gradually reduce, in a phased manner, the granularity of available information in the User-Agent header field, as well as the navigator.userAgent, navigator.appVersion, and navigator.platform JS APIs.
Once this is complete, you will still be able to reliably get the browser major version, platform name, and distinguish between desktop and mobile (or tablet), solely from the User-Agent string. For more advanced use cases, you should migrate to the User Agent Client Hints API.
Note: We have no plans to change the User-Agent string on Android WebView or Chrome for iOS at this time, but will make public updates if and when that changes.
Our current high-level plan is as follows:
We plan to roll out these changes slowly and incrementally in 7 Phases—pending Origin Trial feedback—and plan to publish an update soon on the proposed timing and milestones beyond Phase 1.
Phase 1: Warn about accessing navigator.userAgent, navigator.appVersion, and navigator.platform in DevTools, beginning in M92.
Phase 2: Launch an Origin Trial for sites to opt into the final reduced UA string for testing and feedback, for at least 6 months.
Phase 3: Launch a reverse Origin Trial, for instances where a site may need more time for migration, for at least 6 months.
Phase 4: Ship reduced Chrome MINOR.BUILD.PATCH version numbers (“0.0.0”). Once rolled-out, the reduced UA string would apply to all page loads on desktop and mobile OSes that do not opt into the reverse Origin Trial.
Phase 5: Begin roll-out of reduced Desktop UA string and related JS APIs (navigator.userAgent, navigator.appVersion, navigator.platform). Once rolled-out, the reduced UA string would apply to all page loads on desktop OSes that do not opt into the reverse Origin Trial.
Phase 6: Begin roll-out of reduced Android Mobile (and Tablet) UA string and related JS APIs. Once rolled-out, the reduced UA string would apply to all page loads on Android that do not opt into the reverse Origin Trial.
Phase 7: reverse Origin Trial ends and all page loads receive the reduced UA string and related JS APIs.
See the companion Reduced User Agent string updates page for more details and example User Agent strings at each of these phases.
Our plan was designed with backwards compatibility in mind, and while any changes to the User Agent string need to be managed carefully, we expect minimal friction for developers as we roll this out (i.e., existing parsers should continue to operate as expected).
If your site, service, library or application relies on certain bits of information being present in the User Agent string such as Chrome minor version, OS version number, or Android device model, you will need to begin the migration to use the User Agent Client Hints API instead.
If you don’t require any of these, then no changes are required and things should continue to operate as they have to date.
As noted in the User Agent Client Hints explainer, the User Agent string presents challenges for two reasons. Firstly, it passively exposes quite a lot of information about the browser for every HTTP request that may be used for fingerprinting. Secondly, it has grown in length and complexity over the years and encourages error-prone string parsing. We believe the User Agent Client Hints API solves both of these problems in a more developer- and user-friendly manner.
In some ways Chrome is playing catch up on this front: Safari was the first to cap the macOS version number in the UA string and Firefox has followed suit. Firefox has also capped the Windows version number to 10.
Back in February, we announced that cross-origin isolation will be required on all platforms in order to access APIs like SharedArrayBuffer and performance.measureUserAgentSpecificMemory() starting in Chrome 91. Based on your feedback and issues reported, we've decided to adjust the timeline for SharedArrayBuffer usage in none cross-origin isolated sites to be restricted in Chrome 92.
Your feedback is important and we are listening.
