Chrome 96 Beta: Conditional Focus, Priority Hints, and More

Thursday, October 21, 2021

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 96 is beta as of October 21, 2021.Preparing for a Three Digit Version NumberNext year, Chrome will release version 100. This will add a digit to the version number reported in Chrome's user agent string. To help site owners test for the new string, Chrome 96 introduces a runtime flag that causes Chrome to return '100' in its user agent string. This new flag called chrome://flags/#force-major-version-to-100 is available from Chrome 96 onward.Origin TrialsThis 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. New Origin TrialsConditional FocusApplications that capture other windows or tabs currently have no way to control whether the calling item or the captured item gets focus. (Think of a presentation feature in a video conference app.) Chrome 96 makes this possible with a subclass of MediaStreamTrack called FocusableMediaStreamTrack, which supports a new focus() method. Consider the following code:stream = await navigator.mediaDevices.getDisplayMedia(); let [track] = stream.getVideoTracks(); Where formerly, getVideoTracks() would return an array of MediaStreamTrack objects, it now returns FocusableMediaStreamTrack objects. (Note that this is expected to change to BrowserCaptureMediaStreamTrack in Chrome 97. At the time of this writing, Canary already does this.)To determine which display media gets focus, the next line of this code would call track.focus() with either "focus-captured-surface" to focus the newly captured window or tab, or with "no-focus-change" to keep the focus with the calling window. On Chrome 96 or later, you can step through our demo code to see this in action. Priority HintsPriority Hints introduces a developer-set "importance" attribute to influence the computed priority of a resource. Supported importance values are "auto", "low", and "high". Priority Hints indicate a resource's relative importance to the browser, allowing more control over the order resources are loaded. Many factors influence a resource's priority in browsers including type, visibility, and preload status of a resource.Other Features in this ReleaseAllow Simple Range Header Values Without PreflightRequests with simple range headers can now be sent without a preflight request. CORS requests can use the Range header in limited ways (only one valid range) without triggering a preflight request.Back-forward Cache on DesktopThe back-forward cache stores pages to allow for instant navigations to previously-visited pages after cross-site navigations.Cross-Origin-Embedder-Policy: credentiallessCross-Origin-Embedder-Policy has a new credentialless option that causes cross-origin no-cors requests to omit credentials (cookies, client certificates, etc.). Similarly to COEP:require-corp, it can enable cross-origin isolation.Sites that want to continue using SharedArrayBuffer must opt-in to cross-origin isolation. Doing so using COEP: require-corp is difficult to deploy at scale and requires all subresources to explicitly opt-in. This is fine for some sites, but creates dependency problems for sites that gather content from users (Google Earth, social media generally, forums, etc).CSS:autofill Pseudo ClassThe new autofill pseudo class enables styling autofilled form elements. This is a standardization of the :-webkit-autofill pseudo class which is already supported in WebKit. Firefox supports the standard version.Disable Propagation of Body Style to Viewport when ContainedSome properties like writing-mode, direction, and backgrounds are propagated from body to the viewport. To avoid infinite loops for CSS Container Queries, the spec and implementation were changed to not propagate those properties when containment is applied to HTML or BODY.font-synthesis PropertyThe font-synthesis CSS property controls whether user agents are allowed to synthesize oblique, bold, and small-caps font faces when a font family lacks faces.EME MediaKeySession Closed ReasonThe MediaKeySession.closed property now uses an enum to indicate the reason the MediaKeySession object closed. The closed property returns a Promise that resolves when the session closes. Where previously, the Promise simply resolved, it now resolves with a string indicating the reason for closing. The returned string will be one of "internal-error", "closed-by-application", "release-acknowledged", "hardware-context-reset", or "resource-evicted".HTTP to HTTPS Redirect for HTTPS DNS RecordsChrome will always connect to a website via HTTPS when an HTTPS record is available from the domain name service (DNS).InteractionID in EventTimingThe PerformanceEventTiming interface now includes an attribute called interactiveID. This is a browser-generated ID that enables linking multiple PerformanceEventTiming entries when they correspond to the same user interaction. Developers can currently use the Event Timing API to gather performance data about events they care about. Unfortunately, it is hard to link events that correspond to the same user interaction. For instance, when a user taps, many events are generated, such as pointerdown, mousedown, pointerup, mouseup, and click. New Media Query: prefers-contrastChrome supports a new media query called 'prefers-contrast', which lets authors adapt web content to the user's contrast preference as set in the operating system (specifically, increased contrast mode on macOS and high contrast mode on Windows). Valid options are 'more', 'less', 'custom', or 'no-preference'.Unique id for Desktop PWAsWeb app manifests now support an optional id field that globally identifies a web app. When the id field is not present, a PWA falls back to start_url. This field is currently only supported on desktop.URL Protocol Handler Registration for PWAs Enable web applications to register themselves as handlers of custom URL protocols/schemes using their installation manifest. Operating system applications often register themselves as protocol handlers to increase discoverability and usage. Web sites can already register to handle schemes via registerProtocolHandler(). The new feature takes this a step further by letting web apps be launched directly when a custom scheme link is invoked.WebAssemblyContent Security PolicyChrome has enhanced Content Security Policy to improve interoperability with WebAssembly. The wasm-unsafe-eval controls WebAssembly execution (with no effect on JavaScript execution). Additionally, the script-src policies now include WebAssembly.Reference TypesWebAssembly modules can now hold references to JavaScript and DOM objects. Specifically, they can be passed as arguments, stored in local and global variables, and stored in WebAssembly.Table objects.Deprecations and RemovalsThis version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.The "basic-card" Method of PaymentRequest APIThe PaymentRequest API has deprecated the basic card payment method. Its usage is low and declining. It underperforms when compared to other payment methods in time-to-checkout and completion rate. Developers can switch to other payment methods as an alternative. Examples include Google Pay, Apple Pay, and Samsung Pay.

Removal timeline:

Chrome 96: the basic-card method is deprecated in the Reporting API.

Chrome 100: the basic-card method will be removed.

Sunsetting the "basic-card" payment method in the Payment Request API

Thursday, October 21, 2021

The Payment Request API is a soon-to-be-recommended web standard that aims to make building low-friction and secure payment flows easier for developers. The browser facilitates the flow between a merchant website and "payment handlers". A payment handler can be built-in to the browser, a native app installed on user’s mobile device, or a Progressive Web App. Today, developers can use the Payment Request API to access several payment methods, including “basic-card” and Google Pay in Chrome on most platforms, Apple Pay in Safari, Digital Goods API on Google Play, and Secure Payment Confirmation in Chrome.

Earlier last year, we announced that we will deprecate the "basic-card" payment handler on iOS Chrome, followed by other platforms in the future. The "basic-card" is a payment method that is typically built into the browser to help users easily enter credit card numbers without remembering and typing them. This was designed to make a good transition from a form based credit card payment to an app based tokenized card payment. In order to better pursue the goal of app based payment (and a few other reasons), the Web Payments WG decided to remove it from the specification.

Starting from version 96, Chrome will show a warning message in DevTools Console (together with creating a report to Reporting API) when the "basic-card" payment method is used. In version 100, the "basic-card" payment method will be no longer available and canMakePayment() will return false unless other capable payment methods are specified. This applies to all platforms including Android, macOS, Windows, Linux, and Chrome OS.

If you are using the Payment Request API with the "basic-card" payment handler, we suggest removing it as soon as possible and using an alternative payment method such as Google Pay or Samsung Pay.

Posted by Eiji Kitamura, Developer Advocate on the Chrome team

Extending Chrome App Support on Chrome OS

Thursday, October 14, 2021

Posted by Paul Rossman, Technical Program Manager, Chrome

Today we're announcing an important update to the previously communicated Chrome app support timeline. Based on feedback from our Enterprise and Education customers and partners, we have made the decision to extend Chrome app support for those users on Chrome OS until at least January 2025.

We continue to invest and have made significant progress in rich new capabilities on the Web platform with Progressive Web Apps (PWA), and we recommend that Chrome app developers migrate to PWAs as soon as possible. PWAs are built and enhanced with modern APIs to deliver enhanced capabilities, reliability, and installability while reaching anyone, anywhere, on any device with a single codebase. There is a growing ecosystem of powerful desktop web apps & PWAs, from advanced graphics products like Adobe Spark to engaging media apps like YouTube TV to productivity and collaboration apps like Zoom.

For additional support with Chrome app migration, please visit our Web apps on Chrome OS page. This page will be kept up to date as we progress together through this process.

We thank our community of developers who have provided feedback to help us shape this modified and simplified approach. We are inspired by a future beyond Chrome apps, where the ecosystem continues forward progress leveraging open Web standards across all modern browsers.

RenderingNG: an architecture that makes and keeps Chrome fast for the long term

Wednesday, October 6, 2021

Our continual investments in the performance of Chrome have led to significant improvements in battery life, memory, and the speed of the web. This post in The Fast & the Curious series highlights the rendering journey of Chrome over the past eight years, a journey that has led to a browser that is better across the board. For example, Chrome 94, as compared with Chrome 93:

is up to 8% more responsive on real pages,

saves more than 1400 years of CPU time per day, and

improves battery life by up to 0.5%

In addition, recent versions of Chrome are much better than those of years past with:

150% or more faster graphics rendering, and

greater reliability, due to a 6x reduction in GPU driver crashes on problematic hardware

IntroductionRenderingNG

RenderingNGcoming to a conclusion

The pyramid of success

Performance

GPU & multi-core

A great way Chrome can render content faster is to take advantage of the multi-core CPUs and advanced GPUs present in today’s devices. Multi-core means we can do multiple kinds of work in parallel. For example, Chrome parallelizes running JavaScript, scrolling a web page, decoding an image or video, and rastering new content that will be on-screen soon. GPUs enable even more parallelization by rastering every pixel on-screen, rather than one-at-a-time, yielding a large speedup.

Earlier generations of browsers were not built to natively support these technologies, because at the time GPUs and multi-core computers were not widespread. It turned out that bolting on highly parallel features was extremely challenging, requiring the team to re-architect the entire Chrome rendering pipeline over time. This re-architecture is RenderingNG.

Scaling up and scaling down

To avoid exhausting available resources and potentially diminishing the user experience of the web, browsers must be respectful of efficiency. They should not slow down your ability to interact with your computer or phone, or keep you from multitasking between the browser and other apps. Likewise, browsers also need to maximize battery life of your phone and laptop, and prevent the device itself from getting too hot (here’s looking at you, CPU cooling fans!). And finally, the browser must always be smooth and responsive to the user.

This means that the browser needs to be able to scale up and down its use of the GPU and multi-threading to balance multitasking, battery, and device temperature. As one example of scaling up, it’s important that scrolling happen in parallel with JavaScript on all devices; otherwise the browser will have poor user responsiveness. On the other hand, there are times when the browser must scale down because battery life may be considered more important than maximum use of GPU and CPU resources to make rendering faster.

It turns out to be challenging to be able to scale up and scale down seamlessly, and in a way that doesn’t break web content or make the browser unresponsive in key situations. RenderingNG applies novel technologies throughout the stack to make this work, including a complete rewrite of how compositing works, enabling the flexible use of GPU or CPU computations for arbitrary pieces of web pages, in order to pick the right fit for each web page and device.

Performance isolation

The third key technique is performance isolation. Performance isolation is what allows you to have a nice experience reading your email while music and video is playing in the background: your computer and operating system (OS) architecture makes sure that they all share the CPU fairly and smoothly. (This feature has been around for native apps for so long, we just take it for granted, but it wasn’t always that way!)

Browsers already have good isolation from other apps on your computer (thanks to the OS), but within a web page, it can be difficult to isolate all the pieces, such as iframes for ads and other embedded content, video and audio, animations, scrolling, JavaScript, and various other browser tasks. In earlier eras of the web, it was a huge achievement to simply make all these features work at all. Now the bar has been raised, and they need to fit together seamlessly in order to create a reliably fast user experience on the web.

RenderingNG’s architecture implements performance isolation for all of these features.

Reliability

Most of our work has been focused on reliability of the user experience. This is especially true when rewriting the entire rendering stack of a web browser--a huge and potentially risky undertaking.

We did this with four key techniques:

Comprehensive testing, such as a huge battery of Web Platform Tests,
Measuring progress in reliability, through metrics that track performance & quality, and committed goals such as Compat2021,
Listening to and acting on bug reports and feedback,
Good software design patterns.

Compat2021 improvements over time

Extensibility

Finally, we always have one eye toward what web apps will need now and in the future to unlock better and better experiences for users. These apps are always pushing at the boundary of what is possible to do well on the web, and sometimes beyond. When they go beyond what current web APIs or architectures were designed for, the web app may still work, but it’ll sometimes be slower and more cumbersome to use---and more taxing on your computer than necessary. We are filling these gaps with new APIs that allow web apps to continue doing all these things, but in a way that is much easier to implement performantly.

Extensibility has been part of the design of RenderingNG from the beginning, and is a big reason why the system is clean and modular.

Results

The first RenderingNG performance optimization shipped in 2015. Below we’ve highlighted a few of the many subsequent performance improvements since then.

CompositeAfterPaint: faster and more responsive on all pages [1]

In the M94 release, we will ship CompositeAfterPaint, a new compositing subsystem that allows for arbitrary scaling up and down of GPU use for web app content. Even better, due to more efficient, purpose-built algorithms in this subsystem, CompositeAfterPaint will substantially improve:

Scroll latency by up to 8%
Responsiveness by up to 3%
Peak rendering speed by up to 3%
GPU memory use by more than 3%
CPU time spent rendering and interacting with tabs, resulting in a savings of more than 1400 years of CPU time per day
Battery life by up to 0.5%

GPU Raster: dramatically faster than before [2]

When it shipped on Mac in 2016, GPU raster resulted in a 37% improvement on the overall MotionMark benchmark, and 150% on HTML categories. We subsequently brought similar wins to all other platforms and content types, concluding in 2020. In 2021 we shipped improvements focused on further GPU acceleration for 2D Canvas rendering, with up to a 1000% improvement in the Path rendering test, and a 130% improvement overall on the MotionMark 1.2 benchmark, as measured on an Apple M1 Mac.

Out-of-process Raster: much-improved reliability [1]

Out-of-process raster shipped on Android in 2018. This reduced the crash rate for problematic GPU drivers by 6x, bringing reliability in line with other drivers.

Learn more

If you’d like to learn more about RenderingNG, head over to the Chrome Developers Blog, where we are publishing a whole series about the project, with more to come over time.

Thanks for reading!

Posted by Chris Harrelson, Lead Rendering Software Engineer

[1] Data source: Real-world data anonymously aggregated from Chrome clients.
[2] Data source: MotionMark.

Helping users explore the web and continue prior tasks

Friday, October 1, 2021

When you’re looking for a certain piece of information or working on a project, your path through the internet likely isn’t a linear one. You might search for the same thing multiple times, jump between pages, head back to Google Search again, or parse through your history for that one page you can’t seem to find again. It can be challenging, and more importantly, it can take up time that you could be using to get things done.

Now, we’re kicking off two new experiments with the goal of making it easier to navigate, explore and keep track of the things you find on the web.

Continue your explorations of the web
If you’ve already started exploring a topic and visited multiple sites along the way over a number of days or weeks, chances are you’ve found helpful information you might want to revisit. But you also undoubtedly took a few detours along this journey to read the news, email a friend and shop for a new pair of shoes in the meantime. To help you take stock of completed research, revisit that one helpful nugget and continue exploring a certain topic, we’re experimenting with a new feature called Journeys.

If you’ve been researching a trip to Yosemite for the past few weeks, Journeys will cluster all the pages you’ve visited related to Yosemite so you can easily view them without having to sift through your browsing history. You’ll also see related search suggestions so you can continue planning your trip right there.

Importantly, you're in control of your Journeys experience. For example: you can turn off Journeys at any time, and as always, you can easily clear your browsing history right from your Chrome settings, or by typing "clear browsing data" into the address bar. If you'd like, you can also clear history that's related to a particular journey vs. your history overall. Finally, the current Journeys experiment only groups history on your device — nothing is saved to your Google account. Based on user feedback and interest, future versions may offer the ability to access Journeys in Chrome across multiple devices (just like bookmarks or passwords).

We’re rolling out Journeys as an experiment in Chrome Canary on desktop and are looking forward to feedback so we can continue to improve it before rolling it out widely.

Easily compare search results on Chrome OS

In addition to helping you revisit past journeys, we’re also experimenting with ways to help you more easily find what you’re looking for when you’re actively searching for something. Whether you're shopping for a gift, planning a trip, comparing restaurants for a dinner with friends or seeking a recipe for dinner, you’ll likely visit more than one site to find what you need.

To make it easier to compare search results and find what you’re looking for more quickly in Chrome, we’re experimenting with a new side panel in the Chrome OS Dev channel, so you can view a page and the search results at the same time. This lets you view a page right in your main browser window without needing to navigate back and forth or losing your search results. The goal of this experiment is to explore how Chrome can better help users easily compare results, akin to the feature we announced last month.

To open the side panel and view the results, just click on the G icon next to the search bar. And if you’ve found what you’re looking for or don’t want to see the results any more, you can easily close the panel at any time. We’re experimenting with this feature first in the Chrome OS Dev channel with Google Search, and with any broader rollout in the future, we’d aim to bring it to more platforms with support for more default search engines.
These experiments are just two of the ways we’re iterating on how Chrome can be more helpful as you explore the web. You might start seeing Journeys in Chrome Canary on desktop and the new side panel on the Chrome OS Dev channel, so we wanted to explain a little bit more about how they’ll work and, as always, we’re looking forward to your feedback.
Posted by Yana Yushkina, Product Manager, Chrome

Chromium Blog

Chrome 96 Beta: Conditional Focus, Priority Hints, and More

Sunsetting the "basic-card" payment method in the Payment Request API

Extending Chrome App Support on Chrome OS

RenderingNG: an architecture that makes and keeps Chrome fast for the long term

Helping users explore the web and continue prior tasks

Labels

Archive

Feed