Source: Chrome 74 beta: reducing unwanted motion, private class fields, and feature policy API from Chromium

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Android WebView, Chrome OS, Linux, macOS, and Windows. View a complete list of the features in Chrome 74 on ChromeStatus.com. Chrome 74 is beta as of March 22, 2019.

CSS prefers-reduced-motion media query

Some users have reported getting motion sick when viewing parallax scrolling, zooming, and other motion effects. To address this, many operating systems like Android depicted in the screenshot below provide an accessibility option to reduce motion whenever possible.

Chrome now provides a media query, prefers-reduced-motion (part of Media Queries Level 5), that allows websites to honor these options when they are available.

Here’s a short example to give you a taste of how it works. Imagine I have a sign-up button that draws attention to itself with a slight motion. The new query lets me shut off the motion for just the button.

@media (prefers-reduced-motion: reduce) {
  button {
    animation: none;
  }
}

For all the details and options, read Move Ya! Or maybe, don’t, if the user prefers-reduced-motion!.

Private class fields

Chrome 72 introduced ECMAScript’s new public class fields. Class fields simplify class syntax by avoiding the need for constructor functions just to define instance properties. Starting in Chrome 73, you can mark a field as private and no consumer of the class can ever access its value.

To mark a field as private, prepend it with a pound sign (#). As with public class fields, your properties do not need to be in a constructor.

class IncreasingCounter {
  #count = 0;
  get value() {
    console.log('Getting the current value!');
    return this.#count;
  }
  increment() {
    this.#count++;
  }
}

Unlike public fields, private fields are not accessible outside of the class body. To read more about private class fields as well as the existing public class fields, read Public and private class fields. See Specification Compliance in this article for more on CSS changes.

JavaScript API for feature policy

Feature policies, which were introduced in Chrome 60, allow websites to selectively enable, disable, and modify the behavior of APIs and other web features. This is done either through the Feature-Policy header or through the allow attribute on an iframe.

In Chrome 74, feature policies are enhanced with the addition of a JavaScript API, available from document.featurePolicy and frame.featurePolicy. The new API encompasses three functions:

• allowedFeatures() returns a list of features allowed by the current domain. 
• allowsFeature() returns a boolean indicating whether a specific feature is allowed by either the current domain or by the specified domain. 
• getAllowlistForFeature() returns a list of domains used on the current page that allow a specified feature.

For examples of these methods and for information about feature policy in general, read Introduction to Feature Policy.

Other features in this release

sampleRate option for the AudioContext constructor

Sets the “sampleRate” to a particular value for an AudioContext that will be created. This allows developers to set an arbitrary sample rate for audio processing in Web Audio API that is separate from the hardware rate. Use this to reduce complexity (by using a lower sample rate) or make the sample rate consistent across all devices by using a fixed rate and letting WebAudio resample appropriately for the hardware rate.

Intl.Locale

Chrome now supports the Intl.Locale class, which allows the following:

• Parsing and manipulating the language, region, and script of a locale
• Reading or writing the Unicode extension tags in a locale
• Storing user locale preferences for this API in a serializable, standard format (rather than using a combination of language and the options object).

Signed exchange reporting for distributors

Signed Exchange Reporting for distributors extends Network Error Logging to enable the distributors of signed exchanges to investigate signed exchange loading errors such as certificate verification errors.

TextEncoder encodeInto() method

Chrome now supports TextEncoder.prototype.encodeInto(), which allows an encoded string to be written directly “into” a supplied pre-allocated buffer, offering a performant alternative to using encode() to produce a buffer, and copying its contents into an existing buffer.

Service worker: client.postMessage() is buffered until the document is ready.

To prevent messages from being delivered before the destination is ready, client.postMessage() does not dispatch the message until one of the following has occurred on the destination:

• DOMContentLoaded event is fired.
• onmessage is set.
• startMessages() is called.

Specification compliance

CSS transition events

The CSS Transitions specification requires that transition events are sent when a transition is enqueued, starts, ends, or is canceled as transitionrun, transitionstart, transitionend, and transitioncancel respectively. These events mirror the CSS animation events which allow developers to observe CSS animations. Chrome now follows the specification.

RTCIceCandidate and RTCIceCandidateInit

RTCIceCandidate and RTCIceCandidateInit now comply with the specification. The RTCIceCandidate interface describes an ICE candidate in WebRTC. It is available in Chrome, but it is not spec compliant as it is missing some fields. There are also some deviations from the specification in terms of nullable and read-only attributes and errors thrown by the constructor.

XHR falls back to UTF-8 when invalid encoding is specified

When an invalid encoding is specified for an XMLHttpRequest (via overrideMimeType() or the response’s MIME type), UTF-8 is used in conformance with the specification. Previously Latin-1 was used.

Note: This applies to desktop Chrome only.

Deprecations and removals

Remove Custom Elements v0

Custom Elements are a web components technology that lets you create new HTML tags, beef up existing tags, or extend components authored by other developers. Custom Elements v1 have been implemented in Chrome since version 54, which shipped in October 2016.

Remove PaymentAddress’s languageCode property

The PaymentAddress’s languageCode property has been removed from the Payment Request API. This property is the browser’s best guess for the language of the text in the shipping, billing, delivery, or pickup address in Payment Request API. The languageCode property is marked at risk in the specification and has already been removed from Firefox and Safari. Usage in Chrome is small enough for safe removal.

Don’t allow popups during page unload

Pages may not use the window.open() API to open a new page during its unload event. The popup blocker already prohibited this, but now it is prohibited whether or not the popup blocker is enabled. For now, enterprises can use the AllowPopupsDuringPageUnload policy flag to allow popups during unload. We expect to remove this flag in Chrome 82.

Note: This was originally targeted at Chrome 72, but was actually removed to Chrome 74.

Deprecate drive-by downloads in sandboxed iframes

Chrome will soon prevent downloads in sandboxed iframes that lack a user gesture, though this restriction could be lifted via an allow-downloads-without-user-activation keyword in the sandbox attribute list. This allows content providers to restrict malicious or abusive downloads.
Downloads can bring security vulnerabilities to a system. Even though additional security checks are done in Chrome and the operating system, we feel blocking downloads in sandboxed iframes also fits the general thought behind the sandbox. Apart from security concerns, it would be a more pleasant user experience for a click to trigger a download on the same page, compared with downloads starting automatically when a user lands on a new page, or started non-spontaneously after the click.