Biometric authentication for payment methods in Chrome on Android.
Starting in Chrome 85 (scheduled to go to stable in late August), Chrome will automatically generate a tagged PDF when you print a web page and choose the "Save as PDF" destination. A tagged PDF is one that contains extra metadata about the structure of a document, including things like headings, lists, tables, paragraphs, and image descriptions. Tagged PDFs are more accessible to users with disabilities, such as blind users who use a screen reader to access PDF files. Tagged PDFs can have other uses too, like making it easier for software that needs to automatically process and extract data from PDFs.
We think adding this metadata to PDFs is a perfect fit for Chrome, because that information is already available in well-structured, accessible web pages. We hope this helps make more content exported from Chrome to be accessible to even more users.
Organizations that publish content for the general public online often require that all of their PDFs are accessible, either as a matter of policy or to comply with local laws such as Section 508 in the U.S. Unfortunately, a lot of software programs that are otherwise great for authoring content don't have any support for directly generating a tagged PDF. In these cases, separate remediation software or services are used to make PDFs compliant. By building this into Chrome, we're hoping some organizations that already use HTML as part of their document workflow might be able to take advantage of this new functionality and generate compliant PDFs more easily. This feature also works with Chrome Headless when you use both the --print-to-pdf and --export-tagged-pdf flags.
When we started our journey to make PDFs more accessible, we reached out to the experts - CommonLook, an organization that's been offering PDF accessibility software and services for more than 20 years and which is active in setting PDF standards. We made use of CommonLook's PDF Validator and consulted with them to ensure we were focusing our efforts on the areas that would have the biggest impact.
"To improve the accessibility of PDF documents in Chrome, Google reached out to CommonLook because of our expertise in PDF accessibility. At the time, we recognized the potential impact on PDF accessibility due to the massive number of Chrome users around the world. Two years later, we are pleased to announce that significant progress has been made, and now Chrome is rolling out this feature to all users every time they generate a PDF from Chrome. We will continue to support Google as they work to make Chrome more accessible to all their users." - Monir ElRayes, President and CEO, CommonLook
This feature is rolling out as an experiment. Use chrome://flags/#export-tagged-pdf if you'd like to try it out before it's enabled automatically for all users.
While this is an important milestone, we're not done. Future work includes both improving the quality of generated tagged PDFs, and also improving Chrome's built-in PDF reader to better consume tagged PDFs.
Posted by Dominic Mazzoni, technical lead for Chrome accessibility.
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 85 is beta as of July 23, 2020.
Fetch upload streaming lets web developers make a fetch with a ReadableStream body. Starting in Chrome 85, it's available for an origin trial.
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.
See the Origin Trials section for information on signing up and for a list of other origin trials starting in this release. This origin trial is expected to run through Chrome 87 in January 2021.
Note: At the time this was originally published, WebHID was scheduled to begin an origin trial in Chrome 85. The timeline has since been pushed back to Chrome 86.
There is a long tail of human interface devices (HIDs) that are too new, too old, or too uncommon to be accessible by systems' device drivers. The WebHID API solves this by providing a way to implement device-specific logic in JavaScript.
An HID is one that takes input from or provides output to humans. Examples of devices include keyboards, pointing devices (mice, touchscreens, etc.), and gamepads.
The inability to access uncommon or unusual HID devices is particularly painful when it comes to gamepad support. Gamepad inputs and outputs are not well standardized and web browsers often require custom logic for specific devices. This is unsustainable and results in poor support for the long tail of older and uncommon devices.
We're working on an article to show you how to use the new API. In the meantime, we've found some demos from a few eager engineers that you can use to try the new API. To see those demos, check out Human interface devices on the web: a few quick examples.
The navigator.getInstalledRelatedApps() method determines whether a site's corresponding native app is installed. This allows customization of a user experience for already-installed apps. For example, users can be redirected from a product marketing page directly into an app. Functionality can be centralized to prevent users from seeing duplicate notifications and save developers from maintaining two code bases. Sites can even avoid prompting for installation of a PWA if a native app is already on a user's device.
It does all this while protecting user privacy. Entries in the web app manifest and the Android manifest file ensure that sites cannot use the API to request arbitrary information about users' installed apps.
This method was implemented on Android in Chrome 80. Starting in Chrome 85, it's available on Microsoft Windows. This addition is the result of work from Microsoft. For details on using this method, see Is your app installed? getInstalledRelatedApps() will tell you!.
CSS Houdini is a set of APIs and CSS features that exposes the CSS rendering engine. It lets developers create new CSS features without waiting for a native implementation in browsers. CSS Houdini's @property rule is part of the CSS Properties and Values API, which allows defining custom properties with inheritance, type checking, and default values. The first part of this API, CSS.registerProperty(), was implemented in Chrome 78. That method's capabilities are now available in stylesheets through the @property.
Take the image below, for example. What you're seeing is a transition created with a CSS custom property. In addition to being impossible without the new API, this transition is also type safe. For more information, see @property: giving superpowers to CSS variables.
In addition to those listed above, this version of Chrome introduces the new 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 Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.
A declarative API to allow the creation of shadow roots using only HTML and no JavaScript. This API allows Web Components that use Shadow DOM to also make use of server-side rendering (SSR), to get rendered content on screen quickly without requiring JavaScript for shadow root attachment. The origin trial is expected to run through Chrome 87 in January 2020.
The RTCRtpEncodingParameters.adaptivePtime property lets a sender in a real-time communication (RTC) system enable or disable adaptive packet rates. Because the packet rate is a big determining factor to the overall bitrate of an audio stream, an optimal congestion control is needed to adapt the packet rate. The audio packet rate is analogous to the video frame rate, which also plays an important role in the video bitrate adaptation. Although adaptive packet rate may be ubiquitously beneficial, we need this API for applications to enable and disable it, since, otherwise, it may introduce interoperability problems. Some implementations have taken a fixed packet rate as an assumption, and thus may fail or perform sub-optimally with an adaptive packet rate. The origin trial is expected to run through Chrome 87 in January 2021.
Portals enable seamless navigations between sites or pages by allowing a page to show another page as an inset. For more information, see Hands-on with Portals: seamless navigation on the Web. The origin trial is expected to run through Chrome 86 in early November.
App shortcuts are now available on desktop in addition to Android, which debuted in Chrome 84. This feature improves users' productivity and facilitates reengagement with key tasks by providing quick access to common actions. For sites that are already Progressive Web Apps, creating shortcuts requires only adding items to the web app manifest. This addition is the result of work from Microsoft. For more information, see Get things done quickly with app shortcuts.
Chrome is now auto-upgrading images served over HTTP from HTTPS sites by rewriting URLs to HTTPS without falling back to HTTP when secure content is not available. Chrome has been auto-upgrading audio and video content since version 80.
Adds support for decoding AVIF content natively using existing AV1 decoders. AVIF is a next generation image format standardized by the Alliance for Open Media. There are three primary motivations for supporting AVIF:
Getting persistent storage is easier and more predictable for installed web apps, including PWAs and Trusted Web Activities. If an installed web app requests persistent storage by calling navigator.storage.persist(), it will be granted automatically. Other sites will continue to use the existing heuristics.
navigator.storage.persist()
Chrome made two changes to match those made in the CSS Color Adjustment level 1 spec.
This means content which has a dark theme in its CSS will be able to match it with dark themed UA controls. This change improves interoperability with WebKit which already had this behavior for 'color-scheme: dark'.
Adds a CSS property called content-visibility, which allows automatic or script management of content visibility. When hidden, the element's contents (subtree or replaced element contents) are not drawn or hit-tested and have CSS containment applied, allowing for rendering optimizations. The 'auto' keyword allows for the user-agent to manage content visibility based on proximity to the viewport, whereas the 'hidden' keyword allows full script control of content visibility.
CSS counter-set is an additional property introduced in CSS Lists Module Level 3 to control counters by setting an existing counter to a specified value. This builds on other implemented counter control properties, specifically counter-reset (which creates a new counter with a specified value) and counter-increment (which increments an existing counter by a specified amount). This feature is needed for precise counter control, since otherwise it is not possible to set an existing counter to a value other than figuring out how to increment or decrement it.
The Event Timing API enables web developers to measure event latency both before and after the page load. Monitoring event latency requires an event listener. This precludes measuring event latency early in page load, and adds unnecessary performance overhead.
(Desktop only) The leavepictureinpicture event now exposes a reference to pictureInPictureWindow so that web developers no longer need to keep a global reference to that object.
Support is added for several CSS properties and descriptors for printing.
Web developers may specify a referrer policy on their documents, which impacts the Referer header sent on outgoing requests and navigations. When no such policy is specified, Chrome will now use strict-origin-when-cross-origin as the default policy, instead of no-referrer-when-downgrade. On cross-origin requests made from documents without a specified referrer policy, this reduces the Referer header to the initiating origin.
Changes the behavior of fallback content for ImageInputType and HTMLImageElement. Such content will now render exactly the same as alt text would.
Corrects several spec inconsistencies related to the <link> tag's disabled attribute.
These behaviors are eliminated in compliance with a spec update.
Adds two new methods, writeValueWithResponse() and writeValueWithoutResponse(), which resolve several issues with the existing method for writing to GATT characteristics and enable developers to control whether the device returns a response. The existing writeValue() method will remain for backwards compatibility, but its use is discouraged. The following problems with the existing method have been corrected:
The new APIs also do not depend on the GATT characteristic properties being set correctly which allows working around buggy Bluetooth devices.
WebAssembly now imports and exports WebAssembly function parameters of type i64 using BigInt.
Several methods from the Web Authentication Level 2 spec have been added.
This version of Chrome incorporates version 8.1 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.
Adds the logical assignment operators ||=, &&=, and ??= to JavaScript. This rounds out the compound assignment operators to also include logical binary operators. Currently only mathematical and bitwise binary operators are supported. This improvement is for shipping terser, clearer JavaScript. For more information, see Logical assignment.
Adds two new JavaScript features to V8. Promise.any() accepts an iterable of promises and returns a promise that is fulfilled by the first given promise to be fulfilled, or rejected with an AggregateError holding the rejection reasons if all of the given promises are rejected. AggregateError is a support class that aggregates one or more errors into a single object. This rounds out standard JS support for commonly available Promise combinators already available in userland libraries.
JavaScript now has support for global substring replacement through the new String.prototype.replaceAll() method.
This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.
Chrome 85 starts a spec-mandated turn down of AppCache in Chrome. For details and instructions for managing the transition gracefully, see Preparing for AppCache removal. For information on a feature that will help you identify uses of this and other deprecated APIs, see Know your code health.
Use of cookies with SameSite set to None without the Secure attribute is no longer supported. Any cookie that requests SameSite=None but is not marked Secure will be rejected. This feature started rolling out to users of Stable Chrome on July 14, 2020. See SameSite Updates for a full timeline and details. Cookies delivered over plaintext channels may be cataloged or modified by network attackers. Requiring secure transport for cookies intended for cross-site usage reduces this risk.
Trusted Web Activities are Chrome's recommended way to integrate fullscreen Progressive Web App content into an Android app. Unlike a WebView, a Trusted Web Activity is an instance of the Chrome browser and implements a complete and evergreen set of web platform APIs thanks to Chrome auto update. Since the release of Trusted Web Activity, we’ve been working on improving the integration of apps built using a Trusted Web Activity into the native ecosystem with features such as automatically generated splash screens and web notification delegation.
In Chrome 86, we’ll take this integration a step further by delegating web application crash events into native equivalents.
Web apps crash, but they crash differently
Web developers are more used to thinking about “errors” rather than crashes. When a user encounters an HTTP error in their web app journey, such as a 404 or a 5xx error, that’s effectively an application crash. Another example of a web app error that could be considered a crash is when the Chrome dino page appears because the user lost their internet connection and the app didn’t have a handler in the ServiceWorker for an offline resource request. This kind of ServiceWorker handling of errors can be used for 404 and 5xx resource loading errors as well.
Crashes in the Android ecosystem
Android Vitals is an initiative by Google to improve the stability and performance of Android devices. The Google Play Console aggregates Android Vitals data and displays it in the Android vitals dashboard. Problems in Android Vitals indicate a low quality user experience in the app and can result in bad ratings and poor discoverability on the Play Store.
Starting in Chrome 86, Chrome will integrate critical web application crashes into native app crash events and Android Vitals. As this change will cause user facing crashes if these events are unhandled, developers using or planning to use a Trusted Web Activity should review this post carefully.
Critical web application crashes that will be delegated in Chrome 86 are:
an HTTP 404 or 5xx error in the application
failure to return HTTP 200 for an offline network resource request
failure to verify digital asset links at application launch
In this article we’ll provide more details on the exception conditions, impact on the application behavior and how to avoid these exceptions.
Users installing an Android application from the Play Store expect the application to look and feel native. Native applications do not have a 404 or 5xx error page. Native applications are expected to handle internet service interruptions, at a minimum by providing a branded offline indicator. Finally, when digital asset links fail to verify, we cannot verify that the app owner is also the owner of the web content. Previously, this circumstance resulted in a fallback from Trusted web Activity to a CCT view. In practice we’ve found that a CCT fallback does not meet user expectations. Furthermore, the silent fallback bypasses a feedback mechanism (a Play console crash report) that is important for developers to understand what’s going wrong with their application.
By integrating crash events into Android Vitals, Android app developers using Trusted Web Activity can make use of the Android Vitals dashboard to view information about the user experience of their app. This approach also rewards developers building high quality apps, since apps with better scores in Android vitals have better discoverability in the Play store.
The table below details the web application crash triggers, the corresponding action and recommended mitigations. The Trusted Web Activity crash event will include a log message viewable in the Android Console with details about which trigger caused the exception and the URL at which the exception occurred to facilitate debugging.
Exception trigger
Action
Recommended mitigations
HTTP 404 or 5xx error code returned on HTTP request for the main document to a trusted origin
Exception raised by the Trusted Web Activity
Make sure your app doesn’t have 404 or 5xx errors
Use a ServiceWorker and handle 404 or 5xx errors using a ServiceWorker fetch event fallback response
Failure to return HTTP 200 on an HTTP request for the main document to a trusted origin when offline
Use a ServiceWorker
Handle offline resource requests using a ServiceWorker [tutorial]
Digital assetlinks verification failure
(excludes failures when offline)
Review the Trusted Web Activity quick start guide for how to correctly implement Digital Assetlinks
TLS verification failure on a trusted origin
Ensure your TLS certificate is valid
Exceptions raised by a Trusted Web Activity can also be handled using Android exception handling. However, consider avoiding these exceptions altogether with the mitigations recommended in the table above.
First, the Trusted Web Activity exception will cause Chrome to exit. Even if the exception is handled, it will still be a janky user experience.
Second, implementing the mitigations in the web app will improve the experience of all users of your PWA in all web browsers.
Over time, we will continue to add integrations of important web application events into Android Vitals to make the user experience of web applications more consistent with native applications.
For example, app startup time, battery usage, permission denials or App Not Responding (ANR) events.
Policies. Android apps using Trusted Web Activity must comply with all Play store policies, including for web content in the Trusted Web Activity, including policies for payments in-app purchases and other digital goods.
To ensure the quality of experience, content in a Trusted Web Activity must meet PWA installability criteria and load fast at the start URL. Loading speed is measured using Lighthouse at the Trusted Web Activity start URL and must achieve a performance score of 80.
Lighthouse is an open-source, automated tool for auditing performance & progressive web apps and is useful both as a benchmark and to help you build better websites.
Since the release of Trusted Web Activity, we’ve created the open source utility library Bubblewrap, which helps developers build high quality Android applications using their Progressive Web App. The Trusted Web Activity quick start guide helps developers new to Trusted Web Activity and Bubblewrap get going fast.
We are continuously improving Bubblewrap, adding tools and scaffolds to make it easy for developers to build high quality Android apps using Trusted Web Activity and to provide build time warnings for common mistakes.
Posted by PJ McLachlan, Product Manager
Last year, MDN ran the 2019 Web Developer Needs Assessment (DNA) survey. The DNA survey drew responses from over 28,000 developers from around the world, together contributing more than 10,000 hours of insights into what is and isn't working on the web today, and how the web needs to change to meet the needs of the developer community.
There were many needs expressed in the survey results, but one that stood out clearly was browser compatibility - the manner in which websites look or behave differently on different web browsers. It is clear that it is still painful to develop a website or web app that works reliably across browsers.
To help focus in on specific developer needs, MDN ran a follow-up survey in March 2020 - the MDN Browser Compatibility Survey. This survey, taken by over 3000 web developers and augmented by post-survey interviews, aimed to uncover the specific pain-points the web developer community is having with browser compatibility. Today I'd like to talk about our takeaways from the results, and what we - Google Chrome - are doing about them.
It is important to stress that these are just some early findings from the MDN Browser Compatibility survey and are focused on pain points developers have relating to Chrome.
Flexbox is a powerful tool for layout on the web. It offers an ergonomic way to define layouts that will respond gracefully on different sized viewports. But this power isn't much good when it can't be relied on across browsers. Flexbox is one of our top priorities for browser compatibility across the web in 2020, and we've put heavy investment into it already.
The Chrome rendering team has been working on a rearchitecture of the Chromium flexbox implementation on top of our modern LayoutNG layout engine. This work, which we plan to bring to Chrome 84, is expected to fix a number of Flexbox compatibility issues in Chromium.
We're also working towards bringing flex-gap and fieldset+flex support to Chromium this year. In fact, flex-gap will be available in Chrome 84 - try it out and let us know what you think.
Getting scrolling right in one browser can be tricky. Getting scrolling right across multiple browsers can be painful (for example, it takes an entire library to consistently lock body scrolling). We're still digging through the feedback on scrolling compatibility, but a few key areas have stood out so far:
How virtual keyboards affect - or don't affect - viewport units in different browsers. (Note recent work from Microsoft Edge on a VirtualKeyboard API that may help here.)
A lack of consistency in input-related events, and the outcome of interacting with them (e.g. what happens when you preventDefault() a touchmove).
Difficulty controlling how scrolling behaves across browsers (e.g. via scroll anchoring).
We plan to start here by investing more in understanding how we can effectively improve scrolling on the web. As part of that, we need to keep hearing from you. Please continue to tell us about your scrolling compatibility pains - especially as they relate to Chrome.
Forms are a very old part of the web, added before even CSS. Form controls were intended to mimic the look and feel of the native platform, but it's clear that they have failed to do so consistently and have also failed to keep up with the needs of modern web development. The compatibility survey turned up two general themes here: stylability and inconsistent behavior across browsers.
On styling form controls, the Microsoft Edge and Google Chrome teams recently finished a year-long project to refresh and update the default form styles in Chromium-based browsers. This much needed refresh modernizes the default look and brings improved accessibility and touch support. However it's clear that without more control over how form controls are styled, they still present a compatibility pain for web developers. We don't have anything to announce here today, but we will be continuing to look at form stylability during 2020.
In terms of behavior, there appears to be a general concern that form control behaviors either aren't well specified or that those specifications aren't consistently followed by browsers. Some concrete examples of inconsistencies across browsers that we heard are support for certain <input> types, autofill behaviors, and content restoration behavior when navigating away from and back to pages that contain forms. Again we have nothing specific to announce yet, but will be looking at this area going forward.
Like Flexbox, CSS Grid is an important component of modern layout. Looking at the early survey results it seems like the story for CSS Grid support in Chromium is fairly good (we have our friends from Igalia to thank for that!). There is one clear exception - Chromium still doesn't support subgrid.
Hopefully it won't be an exception for much longer. It's still early days, but I'm excited to share that a team at Microsoft Edge are working on rearchitecting Chromium's Grid support to use the new LayoutNG engine - and as part of this are intending to add subgrid support! We're excited to see this feature land and want to express our appreciation to our partners at Microsoft, Igalia, and the many other Chromium contributors who have worked on CSS Grid support.
Unlike many platforms, the web has multiple implementations. This has downsides but it is also one of the web's greatest strengths. It vastly widens the diversity of inputs into the web platform, and provides a guarding factor against architectural mistakes that can occur when one blurs a platform (the web) and an implementation (a single browser).
In Chrome we strongly believe in moving the web forward, and in shipping new features that bring benefits to users and developers. But it is clear from the MDN Browser Compatibility Survey that some developers have concerns about how this may impact compatibility. We aren't going to stop moving the web forward, but we are planning to be more rigorous in how we approach it and in how we communicate about compatibility. Look out for more on this soon.
When it comes to browser compatibility, there are still too many missing features and edge-case bugs. But it doesn't have to be this way. Things can and will get better, if browser vendors can understand what is causing the most pain, and take action to address the causes. In Chrome we're doing our best to listen, and we're doing our best to address what we're hearing. We hope it helps, and we're looking forward to a more compatible 2021.
For all of the above, please tell us if we're right or wrong. Tweet us, file bugs and star the issues that you think we should prioritize, fill in this form, take part in the next web survey you see. Your voice matters to us and is a major factor in determining what work we prioritize.
postMessage()
WebAssembly.Module
contentBoxSize
borderBoxSize
devicePixelContentBoxSize
ResizeObserverSize
ResizeObserver
document.onresize
-webkit-appearance
appearance
ruby-position
over
under
inter-character
sheet.replace("@import('some.css');")
replace()
@import