We announced in October that passkey support was available in Chrome Canary. Today, we are pleased to announce that passkey support is now available in Chrome Stable M108.
What are passkeys?
Passwords are typically the first line of defense in our digital lives. However, they are at risk of being phished, leaked in data breaches, and even suffering poor password hygiene. Google has long recognized these issues, which is why we have created defenses like 2-Step Verification and Google Password Manager.
To address these security threats in a simpler and more convenient way, we need to move towards passwordless authentication. This is where passkeys come in. Passkeys are a significantly safer replacement for passwords and other phishable authentication factors. They cannot be reused, don't leak in server breaches, and protect users from phishing attacks. Passkeys are built on industry standards, can work across different operating systems and browser ecosystems, and can be used with both websites and apps.
Using passkeys
You can use passkeys to sign into sites and apps that support them. Signing in with a passkey will require you to authenticate yourself in the same way that you unlock a device.
With the latest version of Chrome, we're enabling passkeys on Windows 11, macOS, and Android. On Android your passkeys will be securely synced through Google Password Manager or, in future versions of Android, any other password manager that supports passkeys.
Once you have a passkey saved on your device it can show up in autofill when you're signing in to help you be more secure.
On a desktop device you can also choose to use a passkey from your nearby mobile device and, since passkeys are built on industry standards, you can use either an Android or iOS device.
A passkey doesn't leave your mobile device when signing in like this. Only a securely generated code is exchanged with the site so, unlike a password, there's nothing that could be leaked.
To give you control over your passkeys, from Chrome M108 you will be able to manage your passkeys from within Chrome on Windows and macOS.
Enabling passkeys
For passkeys to work, developers need to build passkey support on their sites using the WebAuthn API. We’ve been working with others in the industry, especially Apple and Microsoft, members within the FIDO Alliance and the W3C to drive secure authentication standards for years.
Our goal is to keep you as safe as possible on the web and we’re excited for what the passkeys future holds. Enabling passkeys to be used in Chrome is a major milestone, but our work is not done. It will take time for this technology to be widely adopted across sites and we are working on enabling passkeys on iOS and Chrome OS. Passwords will continue to be part of our lives as we make this transition, so we’ll remain dedicated to making conventional sign-ins safer and easier through Google Password Manager.
Posted by Ali Sarraf, Product Manager, Chrome
In 2020, we announced we were in the early phases of establishing the Chrome Root Program and launching the Chrome Root Store.
The Chrome Root Program ultimately determines which website certificates are trusted by default in Chrome, and enables more consistent and reliable website certificate validation across platforms.
This post shares an update on our progress and how these changes help us better protect Chrome’s users.
Chrome uses digital certificates (often referred to as “certificates,” “HTTPS certificates,” or “server authentication certificates”) to ensure the connections it makes on behalf of its users are secure and private. Certificates are responsible for binding a domain name to a public key, which Chrome uses to encrypt data sent to and from the corresponding website.
As part of establishing a secure connection to a website, Chrome verifies that a recognized entity known as a “Certification Authority” (CA) issued its certificate. Certificates issued by a CA not recognized by Chrome or a user’s local settings can cause users to see warnings and error pages.
Root stores, sometimes called “trust stores”, tell operating systems and applications what certification authorities to trust. The Chrome Root Store contains the set of root CA certificates Chrome trusts by default.
A root program is a governance structure that establishes the requirements and security review functions needed to manage the corresponding root store. Members of the Chrome Security Team are responsible for the Chrome Root Program. Our program policy, which establishes the minimum requirements for CAs to be included in the Chrome Root Store, is publicly available here.
Historically, Chrome integrated with the root store and certificate verification process provided by the platform on which it was running. Standardizing the set of CAs trusted by Chrome across platforms through the transition to the Chrome Root Store, coupled with a consistent certificate verification experience through the use of the Chrome Certificate Verifier, will result in more consistent user and developer experiences.
Launching the Chrome Root Program also represents our ongoing commitment to participating in and improving the Web PKI ecosystem. Innovations like ACME have made it easier than ever for website owners to obtain HTTPS certificates. Technologies like Certificate Transparency promote increased accountability and transparency, further improving security for Chrome’s users. These enhancements, only made possible through community collaboration, make the web a safer place. However, there’s still more work to be done.
We want to work alongside CA owners to define and operationalize the next generation of the Web PKI. Our vision for the future includes modern, reliable, highly agile, purpose-driven PKIs that promote automation, simplicity, and security - and we formed the Chrome Root Program and corresponding policy to achieve these goals.
A “rollout” is a gradual launch of a new feature. Sometimes, to ensure it goes smoothly, we don’t enable a new feature for all of our users at once. Instead, we start with a small percentage of users and increase that percentage over time to ensure we minimize unanticipated compatibility issues. The Chrome Root Store and Certificate Verifier began rolling out on Windows and macOS in Chrome 105, with other platforms to follow.
We expect the transition to the Chrome Root Store and Certificate Verifier to be seamless for most users, enterprises, and CA owners.
The Chrome Certificate Verifier considers locally-managed certificates during the certificate verification process. This means if an enterprise distributes a root CA certificate as trusted to its users (for example, by a Windows Group Policy Object), it will be considered trusted in Chrome.
Troubleshooting procedures and other frequently asked questions are available here.
While we don’t know exactly what the future of the Web PKI will look like, we remain focused on promoting changes that increase speed, security, stability, and simplicity throughout the ecosystem.
With that in mind, the Chrome team continues to explore introducing future root program policy requirements related to the following initiatives:
Encouraging modern infrastructures and agility
Focusing on simplicity
Promoting automation
Reducing mis-issuance
Increasing accountability and ecosystem integrity
Streamlining and improving domain validation practices
Preparing for a “post-quantum” world
We look forward to continuing our collaboration with members of the CA/Browser Forum and other Web PKI ecosystem participants to make the Internet a safer place.
We believe that "good enough" is never enough when it comes to pushing the performance of Chrome. Today’s The Fast and the Curious post explores how we sped up the startup times of Chrome on Android by more than 20% by providing an interactive freeze-dried preview of a tab on startup. Read on to see how the screenshot falls short, and freeze-drying your tabs makes for a better browser.
Rendering web content can be computationally intensive and can feel slow at times compared to a native application. A lot of work needs to be done to dynamically load resources over the network, run JavaScript, render CSS, fonts, etc. On mobile devices this is particularly challenging and Chrome can often only keep a handful of web pages loaded at a time due to the memory constraints of the device.
This leads to the question of whether there is a lighter-weight way to represent web content when the situation calls for it—for example, in transitional UI like the tab switcher or during startup when a lot of warm-up work is occurring. The de-facto option for this is a screenshot which is visually accurate and allows a user to see at a glance what they are opening. However, a screenshot is also more limited than a web page as it is constrained to whatever was last visible and is entirely static.
What if we could make these transitional glimpses of web content more useful, interactable and engaging while waiting for the real page to be ready?
Chrome App cold startup on Android is expensive. To start drawing a web page at the median takes 3.4s from launch (First Contentful Paint /FCP). This can feel slow compared to other apps and is due to all the work needed to process a page’s HTML, CSS, JS and Fonts.
What if, instead, we showed an interactive snapshot of the page at startup?
We call this snapshot a Freeze Dried Tab as it removes a number of features from a live web page, but provides enough content and interactivity to be more helpful than a static screenshot. The key elements we felt that a screenshot lacked were the ability to navigate through links and scroll through a page’s content beyond what is shown in the viewport (including iframes).
A Freeze Dried Tab provides all these capabilities and more. It is faster to start than a live web page and provides enough capabilities to get started with the content until the full page is ready. Once the page is loaded, we then transition to it automatically and seamlessly!
Testing has shown that by using a Freeze Dried Tab we can speed up the median time taken to draw all the content of the page to just 2.8s from launch (~20% faster compared to starting to draw normally). Since all the content is there and there’s often no layout shift, it feels even faster!
The distribution shift in startup time caused by Freeze Dried Tabs.
Data source for all statistics: Real-world data anonymously aggregated from Chrome clients [1]
To Freeze Dry a web page we capture the visual state of the page as a set of vector graphics along with any hyperlinks. We can then “reconstitute” (play back) these vector graphics in a lighter-weight fashion by simply rastering the vector graphics. This reduces the rendering cost of showing a full web page (including the content outside the viewport) and still supports hyperlinks.
This format provides a number of benefits over a screenshot, but is still not as fully featured as a web page. This is why we believe they are an ideal candidate for transitional views where loading the live page might take some time, but we want to have a more interactive view than a screenshot.
*Values are estimates from an emulated Pixel 2 XL running Android P.
1Utility process is 30 MB overhead with on average ~10 MB of content and 20 MB of bitmaps
Building this technology was an interesting and challenging experience. In particular, aggregating content from iframes, supporting subframe scrolling, and handling all the geometry is a complicated process.
However, the most interesting challenges came from performance!
During capture of the page, saving the content is mostly straightforward; geometry from the DOM with CSS styling is easily converted into vector graphics which are small and easy to store.
Storing images from the page in this format is also straightforward, although high-resolution images are both large (0.1-10 MB) and slow to compress O(100 ms) + MBs of memory overhead. For this reason, images are usually stored without modification in their default encoding; however, sometimes particularly large images might get dropped.
Fonts are files describing how to draw each glyph they contain. These files are particularly large for fonts from languages with a large number of characters such as Chinese or which are composed of images such as emoji. A single English-language font is often around 100 kB in size, and fonts for emoji can easily be several MB. Pages often embed multiple fonts and these fonts are not saved on the local system, so we need to save them as part of the captured data. In early testing, we tried to store every font used in the page to ensure visual fidelity. However, some pages were as large as 100 MB when stored in this manner. This was simply unacceptable from a performance and storage point of view.
To overcome this challenge we turned to font subsetting. Subsetting strips every unused glyph from a font file. This reduces the data in a font to only what is required by the page. As such, that 100 MB page was reduced to just 400 kB, < 1% of the original size!
Keeping playback performance within a reasonable bound was also a challenge. The vector graphics are rasterized into a bitmap for display; however, at 32-bits per pixel, on a modern phone screen just a single viewport of content is easily larger than 10 MB. To mitigate the memory overhead of these bitmaps, we generate them dynamically as a user scrolls.
More details: the page’s contents are divided into tiles which are smaller than a single viewport. We generate bitmaps for all tiles currently in the viewport and those for a region around the viewport are prefetched to keep scrolling smooth. Experimentation with compressing the out-of-viewport bitmaps until they were in view showed potential memory savings from 10 MB down to just 100 kB. However, after gathering more performance data it was determined that the compression resulted in a significant increase in browser jankiness and for example [FID] due to the additional CPU overhead. Consequently, this behavior was removed in favor of smaller tiles and more proactive discarding of out-of-viewport bitmaps.
Freeze Dried Tabs are a compelling alternative to screenshots particularly for transitional views or places where web content might not be immediately available and waiting for it to become available would be slow. They provide additional fidelity over a screenshot and allow some useful user behavior such as links and scrolling to behave similarly to how they would in a web page.
Currently, Freeze Dried Tabs are being used in Chrome to provide a 20% perceptible speedup in cold startup on Android. We are exploring additional places where this technology might be used.
Posted by Calder Kitagawa, Chrome Software Engineer
Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, ChromeOS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 106 is beta as of September 1, 2022. You can download the latest on Google.com for desktop or on Google Play Store on Android.
This version of Chrome supports 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.
Anonymous iframes give developers a way to load documents in third-party iframes using new and ephemeral contexts. Anonymous iframes are a generalization of COEP, i.e. Cross-Origin-Embedder-Policy: credentialless to support third-party iframes that may not deploy COEP. As with COEP: credentialless, it replaces the opt-in of cross-origin subresources with avoiding loading of non-public resources. This removes the constraint that third party iframes must support COEP in order to be embedded in a COEP page and unblocks developers looking to adopt cross-origin-isolation.
The origin trial is expected to last through Chrome 108. To sign up for the origin trial, visit its sign up page.
The Pop-Up API lets developers build transient user interface elements to display on top of other web app interface elements. This API is useful for creating interactive elements such as action menus, form element suggestions, content pickers, and teaching user interfaces.
This API uses a new popup content attribute to enable any element to be displayed in the top layer. This attribute's effect on the pop-up is similar to that of the <dialog> element, but has several important differences, including light-dismiss behavior, pop-up interaction management, animation, event support, and non-modal mode.
popup
<dialog>
The origin trial is expected to last through Chrome 110. To sign up for the origin trial, visit its sign up page.
Client Hints are now persisted on Android WebView, creating parity with the rest of the web platform. Previously, WebView did not persist the list of Client Hints a page requests, so the initial load of a website would never include Client Hints. Only subresources on a given page would receive them. This undermined the use of the Client Hints system, which is to empower websites to adapt content to the user agent. For more information on Client Hints, see HTTP Client hints.
In CSS Grid, the 'grid-template-columns' and 'grid-template-rows' properties allow developers to define line names and track sizing of grid columns and rows respectively. Supporting interpolation for these properties allows grid layouts to smoothly transition between states, instead of snapping at the halfway point of an animation or transition.
'grid-template-columns'
'grid-template-rows'
The 'ic' length unit expresses CSS lengths relative to the advanced measure of the water ideograph used in some Asian fonts such as Chinese and Japanese. This allows authors to size elements to fit a given number of full width glyphs for such fonts. Gecko and WebKit already support this unit. Adding this to Chrome is part of Interop 2022.
'ic' length unit
The 'preserve-parent-color' value has been added to the 'forced-color-adjust' CSS property. Previously, when the forced colors mode was enabled, the 'color' property was inherited. Now, when the 'preserve-parent-color' value is used, the 'color' property will use the value of its parent. Otherwise, the 'forced-color-adjust: preserve-parent-color' value behaves the same as 'forced-color-adjust: none'.
'preserve-parent-color' value has been added
'forced-color-adjust'
'color'
'preserve-parent-color'
'forced-color-adjust: preserve-parent-color'
'forced-color-adjust: none'
Chrome now supports the unprefixed hyphenate-character property in addition to the -webkit-hyphenate-character property. The -webkit-hyphenate-character property will be deprecated at a later date.
-webkit-hyphenate-character
Intl.NumberFormat has the following new features:
Intl.NumberFormat
formatRange()
formatRangeToParts()
selectRange()
For more information, see the original proposal's README.
The underlying data source for a ReadableStream provided by a SerialPort is now a readable byte stream. SerialPort "bring your own buffer" (BYOB) is backwards-compatible with existing code that calls port.readable.getReader() with no parameters. To detect support for this feature, pass 'byob' as the mode parameter when calling getReader(). For example:
ReadableStream
SerialPort
port.readable.getReader()
'byob'
getReader()
port.readable.getReader({ mode: 'byob' });
Older implementations will throw a TypeError when the new parameter is passed.BYOB readers allow developers to specify the buffer into which data is read instead of the stream allocating a new buffer for each chunk. In addition to potentially reducing memory pressure, this allows the developer to control how much data is received because the stream cannot return more than there is space for in the provided buffer. For more information, see Read from and write to a serial port.
TypeError
A dequeue event and associated callback have been added to the audio and video interfaces, specifically: AudioDecoder, AudioEncoder, VideoDecoder, and VideoEncoder.
dequeue
AudioDecoder
AudioEncoder
VideoDecoder
VideoEncoder
Developers may initially queue encoding or decoding work by calling encode() or decode() respectively. The new dequeue event is fired to indicate when the underlying codec has ingested some or all of the queued work. The decrease in the queue size is already reflected by a lower value of encoder.encodeQueueSize and decoder.decodeQueueSize attributes. The new event eliminates the need to call setTimeout() to determine when the queue has decreased (in other words, when they should queue more work).
encode()
decode()
encoder.encodeQueueSize
decoder.decodeQueueSize
setTimeout()
Applications using the WebXR Device API can now access pose-synchronized camera image textures in the contexts that also allow interacting with other AR features provided by WebXR.
This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.
To align with the latest spec (RFC 6265bis), Chromium now rejects cookies with a Domain attribute that contains non-ASCII characters (for example, éxample.com).
Domain
éxample.com
Support for IDN domain attributes in cookies has been long unspecified, with Chromium, Safari, and Firefox all behaving differently. This change standardizes Firefox's behavior of rejecting cookies with non-ASCII domain attributes.Since Chromium has previously accepted non-ASCII characters and tried to convert them to normalized punycode for storage, we will now apply stricter rules and require valid ASCII (punycode if applicable) domain attributes.
Chrome has removed the ability to receive, keep in memory, and use HTTP/2 push streams sent by the server. See Removing HTTP/2 Server Push from Chrome for details and suggested alternative APIs.
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 105 is beta as of August 5th, 2022. You can download the latest on Google.com for desktop or on Google Play Store on Android.
The Custom Highlight API extends the concept of highlighting pseudo-elements by providing a way to style the text of arbitrary ranges, rather than being limited to the user agent-defined ::selection, ::inactive-selection, ::spelling-error, and ::grammar-error. This is useful in a variety of scenarios, including editing frameworks that wish to implement their own selection, find-in-page over virtualized documents, multiple selection to represent online collaboration, or spell checking frameworks. Without this feature, web developers and framework authors are forced to modify the underlying structure of the DOM tree to achieve the rendering they desire. This is complicated in cases where the desired highlight spans across multiple subtrees, and it also requires DOM updates to adjust highlights as they change. The custom highlight API provides a programmatic way of adding and removing highlights that does not affect the underlying DOM structure, but instead applies styles to text based on range objects.
::selection
::inactive-selection
::spelling-error
::grammar-error
In 105, only the color and background-color pseudo elements are supported. Support for other items will be added later.
Container queries allow authors to style elements according to the size of a container element. This capability means that a component owns its responsive styling logic. This makes the component much more resilient, as the styling logic is attached to it, no matter where it appears on the page.
Container queries are similar to media queries, but evaluate against the size of a container rather than the size of the viewport. A known issue is that container queries do not work when an author combines it with table layout in a multicolumn layout. We expect to fix this in 106. For more information, see @container and :has(): two powerful new responsive APIs. For other CSS features in this release, see below.
The :has() pseudo class specifies an element having at least one element that matches the relative selector passed as an argument. Unlike other selectors, the :has() pseudo class applies, for a specified element, a style rule to preceding elements, specifically, siblings, ancestors, and preceding siblings of ancestors. For example, the following rule matches only anchor tags that have an image tag as a child.
:has()
a:has(> img)
For more information, see @container and :has(): two powerful new responsive APIs. For other CSS features in this release, see below.
Fetch upload streaming lets web developers make a fetch with a ReadableStream body. Previously, you could only start a request once you had the whole body ready to go. But now, you can start sending data while you're still generating the content, improving performance and memory usage.
For example, an online form could initiate a fetch as soon as a user focuses a text input field. By the time the user clicks enter, fetch() headers would already have been sent. This feature also allows you to send content as it's generated on the client, such as audio and video. For more information, see Streaming requests with the fetch API.
fetch()
Window controls overlay extends an app's client area to cover the entire window, including the title bar, and the window control buttons (close, maximize/restore, minimize). The web app developer is responsible for drawing and input handling for the entire window except for the window controls overlay. Developers can use this feature to make their installed desktop web apps look like operating system apps. For more information, see Customize the window controls overlay of your PWA's title bar.
No origin trials are beginning in this version of Chrome. However there are a number of ongoing origin trials which you can find on the Chrome Origin Trials dashboard. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. 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.
The following features, previously in a Chrome origin trial, are now enabled by default.
The Media Source Extensions (MSE) API is now available from DedicatedWorker contexts to enable improved performance of buffering media for playback by an HTMLMediaElement on the main Window context. By creating a MediaSource object in a DedicatedWorker, an application may then obtain a MediaSourceHandle from it and call postMessage() to transfer it to the main thread for attaching to an HTMLMediaElement. The context that created the MediaSource object may then use it to buffer media.
DedicatedWorker
HTMLMediaElement
MediaSource
MediaSourceHandle
postMessage()
Chrome supports the new Sec-CH-Viewport-Height client hint. This is a counterpart to the Sec-CH-Viewport-Width previously introduced in Chrome. Together they provide information about a viewport's size to an origin. To use these hints, pass Sec-CH-Viewport-Height or Sec-CH-Viewport-Width to the Accept-CH header.
Sec-CH-Viewport-Height
Sec-CH-Viewport-Width
Accept-CH
This release enhances the screen label strings provided by the Multi-Screen Window Placement API. Specifically, it refines ScreenDetailed.label property by replacing the previous placeholders with information from the device's Extended Display Identification Data (EDID) or from a higher-level operating system API. For example, instead of returning "External Display 1", the label property will now return something like "HP z27n" or "Built-in Retina Display". These more accurate labels match those shown by operating systems in display settings dialog boxes. The labels are only exposed to sites that have been granted the "window-placement" permission by the user.
ScreenDetailed.label
"window-placement"
Setting an element's position CSS property to fixed (unless the element's containing block is not the root) will now prevent it from performing the effects specified by overscroll-behavior. In particular, fixed-position elements will not move during overscroll effects.
position
fixed
fixed-position
A new constraint is being added to MediaDevices.getDisplayMedia() to indicate whether system audio should be offered to the user. User agents sometimes offer audio for capturing alongside video. But not all audio is created alike. Consider video-conferencing applications. Tab audio is often useful, and can be shared with remote participants. But system audio includes participants' own audio, and may not be appropriate to share back. To use the new constraint, pass systemAudio as a constraint. For example:
MediaDevices.getDisplayMedia()
systemAudio
const stream = await navigator.mediaDevices.getDisplayMedia({ video: true, audio: true, systemAudio: "exclude" // or "include" });
This feature is only supported on desktop.
To conform with spec the TransformStreamDefaultController class is now available on the global scope. This class already exists and can be accessed using code such as let TransformStreamDefaultController; new TransformStream({ start(c) { TransformStreamDefaultController = c.constructor; } }); This change makes such code unnecessary since TransformStreamDefaultController is now on the global scope. Possible uses for this class include monkey patching properties onto TransformStreamDefaultController.prototype, or feature-testing existing properties of it more easily. Note that the class is not constructible. In other words, this throws an error:
TransformStreamDefaultController
let TransformStreamDefaultController; new TransformStream({ start(c) { TransformStreamDefaultController = c.constructor; } });
TransformStreamDefaultController.prototype
new TransformStreamDefaultController()
The HTML Sanitizer API is an easy to use and safe way to remove executable code from arbitrary, user-supplied content. The goal of the API is to make it easier to build web applications that are free of cross-site scripting vulnerabilities and ship part of the maintenance burden for such apps to the platform.
In this release, only basic functionality is supported, specifically Element.setHTML(). The Sanitize interface will be added at a later stage. Namespaced content (SVG + MathML) is not yet supported, only HTML. For more information on the API, see HTML Sanitizer API - Web APIs.
Element.setHTML()
The import.meta.resolve() method returns the URL to which the passed specifier would resolve in the context of the current script. That is, it returns the URL that would be imported if you called import(). A specifier is a URL beginning with a valid scheme or one of /, ./, or ../. See the HTML spec for examples.
import.meta.resolve()
import()
/
./
../
This method makes it easier to write scripts which are not sensitive to their exact location, or to the web application's module setup. Some of its capabilities are doable today, in a longer form, by combining new URL() and the existing import.meta.url() method. But the integration with import maps allows resolving URLs that are affected by import maps.
new URL()
import.meta.url()
Chrome 105 introduces two new methods on the NavigateEvent of the Navigation API (introduced in 102) to improve on methods that have proved problematic in practice. intercept(), which let's developers control the state following the navigation, replaces transitionWhile(), which proved difficult to use. The scroll() method, which scrolls to an anchor specified in the URL, replaces restoreScroll() which does not work for all types of navigation. For explanations of the problems with the existing methods and examples of using the new, see Changes to NavigateEvent.
intercept()
transitionWhile()
scroll()
restoreScroll()
The transitionWhile() and restoreScroll() methods are also deprecated in this release. We expect to remove them in 108. See below for other deprecations and removals in this release.
The nbeforeinput global content attribute is now supported in Chrome. The beforeinput form was already available via addEventListener(). Chrome now also allows feature detection by testing against document.documentElement.onbeforeinput
nbeforeinput
beforeinput
addEventListener()
ocument.documentElement.onbeforeinput
Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read Blocking (CORB). CORB and ORB are both heuristics that attempt to prevent cross-origin disclosure of "no-cors" subresources.
The Picture-in-Picture API allows websites to create a floating video window that is always on top of other windows so that users may continue consuming media while they interact with other sites or applications on their device. This feature has been available on desktop since Chrome 70. It's now available for Chrome running on Android 11 or later. This change only applies to <video> elements. For information on using the Picture-in-Picture API, see Watch video using Picture-in-Picture.
<video>
The Response() constructor allows for creating the body of the response from many types; however the existing response.json() instance method does not let you directly create a JSON object. The Response.json() static method fills this gap.
Response()
response.json()
Response.json()
Response.json() returns a new Response object and takes two arguments. The first argument takes a string to convert to JSON. The second is an optional initialization object.
The syntax for the delegation of client hints to third-party content that requires client information lost by user agent reduction, which shipped in Chrome 100, is changing.
Previous syntax: <meta name="accept-ch" value="sec-ch-dpr=(https://foo.bar https://baz.qux), sec-ch-width=(https://foo.bar)"> New syntax: <meta http-equiv="delegate-ch" value="sec-ch-dpr https://foo.bar https://baz.qux; sec-ch-width https://foo.bar">
<meta name="accept-ch" value="sec-ch-dpr=(https://foo.bar https://baz.qux), sec-ch-width=(https://foo.bar)">
<meta http-equiv="delegate-ch" value="sec-ch-dpr https://foo.bar https://baz.qux; sec-ch-width https://foo.bar">
Chromium now allows returning a directory with both read and write permissions in a single prompt for the File System Access API. Previously, Window.showDirectoryPicker() returned a read-only directory (after showing a read access prompt), requiring a second prompt to get write access. This double prompt is a poor user experience and contributes to confusion and permission fatigue among users.
Window.showDirectoryPicker()
This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of planned deprecations, current deprecations and previous removals.
WebSQL in non-secure contexts is now removed. The Web SQL Database standard was first proposed in April 2009 and abandoned in November 2010. Gecko never implemented this feature and WebKit deprecated it in 2019. The W3C encourages Web Storage and Indexed Database for those needing alternatives.
Developers should expect that WebSQL itself will be deprecated and removed when usage is low enough.
The CSS keyword 'default' is no longer allowed within CSS custom identifiers, which are used for many types of user-defined names in CSS (for example, names created by @keyframes rules, counters, @container names, custom layout or paint names). This adds 'default' to the list of names that are restricted from use in custom identifiers, specifically 'inherit', 'initial', 'unset', 'revert', and 'revert-layer'.
'default'
@keyframes
@container
'inherit'
'initial'
'unset'
'revert'
'revert-layer'
The transitionWhile() and restoreScroll() methods are also deprecated in this release, and we expect to remove them in 108. Developers who need this functionality should use the new intercept() and scroll() methods. For explanations of the problems with the existing methods and examples of using the new, see Changes to NavigateEvent .
To align with the latest spec (RFC 6265bis), Chromium will soon reject cookies with a Domain attribute that contains a non-ASCII character (for example, Domain=éxample.com). Support for IDN domain attributes in cookies has been long unspecified, with Chromium, Safari, and Firefox all behaving differently. This change standardizes Firefox's behavior of rejecting cookies with non-ASCII domain attributes. Since Chromium has previously accepted non-ASCII characters and tried to convert them to normalized punycode for storage, we will now apply stricter rules and require valid ASCII (punycode if applicable) domain attributes.
Domain=éxample.com
A warning is printed to the console starting in 105. Removal is expected in 106.
The gesture scroll DOM events have been removed from Chrome, specifically, gesturescrollstart, gesturescrollupdate and gesturescrollend. These were non-standard APIs that were added to Blink for use in plugins, but had also been exposed to the web.
gesturescrollstart
gesturescrollupdate
gesturescrollend
