Chrome 72 Beta: Public class fields, user activation and more
Tuesday, December 18, 2018
Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, macOS, and Windows. View a complete list of the features in Chrome 72 on ChromeStatus.com. Chrome 72 is beta as of December 13, 2018.
To implement public class fields, declare them inside a class declaration but outside of any member functions. They can be either initialized or uninitialized. For example, instead of this:
you can now write this:
Declaring class fields makes class definitions more self-documenting. Because these fields are always present, class instances go through fewer transitions. Head over to our article on class fields and the ChromeStatus entry for more information.
The new
The following example shows how an iframe would notify a parent that a user activation is present.
The parent could then verify that the activation is still active before responding to it.
For more information, read our Web Fundamentals article.
for lone surrogates, making its output valid Unicode (and representable in UTF-8). The example below demonstrates how this works in practice.
of the File interface previously returned a value different from other major browsers, now it returns the same value.
For example, if a user has the following local files:
and they selected /tmp with a file chooser dialog, webkitRelativePath in Chrome was:
Other browsers, which Chrome now matches, return this:
Note: This was originally targeted at Chrome 72, but was actually removed to Chrome 74.
Public class fields
Chrome now allows declaration of public class fields in scripts. This is the first part of class field declarations in JavaScript; support for private class fields is coming soon.To implement public class fields, declare them inside a class declaration but outside of any member functions. They can be either initialized or uninitialized. For example, instead of this:
class MyComponent extends Component {
constructor() {
super();
this.state = {};
}
render() {
doStuff(this.state);
}
}
you can now write this:
class MyComponent extends Component {
// Create a public field named `state`.
state = {};
render() {
doStuff(this.state);
}
}
Declaring class fields makes class definitions more self-documenting. Because these fields are always present, class instances go through fewer transitions. Head over to our article on class fields and the ChromeStatus entry for more information.
User Activation Query API
Chrome now provides an API for querying whether there has been a user activation. This is useful for APIs that are deliberately restricted to avoid annoying web page behaviors. Examples includerequestFullScreen(), autoplay, and window.open(). This also allows embedded iframes to vet postMessage() calls to determine whether they occurred within the context of a user activation.The new
userActivation property, available on both navigator and MessageEvent, supports the following properties:hasBeenActive: Indicates whether the associated window has ever seen a user activation in its lifecycle. This property does not reflect whether the current task was triggered by a user activation.isActive: Indicates whether the associated window currently has a user activation in its lifecycle.
postMessage() method now also takes an options argument on the Window, Worker, and MessagePort objects. This object subsumes existing arguments and adds the includeUserActivation boolean property to notify the message recipient that there has been a user activation. The following example shows how an iframe would notify a parent that a user activation is present.
// Check that WindowPostOptions is supported
if (window.parent.postMessage.length === 1) {
window.parent.postMessage('resize', {includeUserActivation: true});
} else {
window.parent.postMessage('resize', '/');
}
The parent could then verify that the activation is still active before responding to it.
if (event.userActivation && event.userActivation.isActive) {
return Promise.resolve();
}
Other features in this release
Cache API: reject addAll() when requests would overwrite each other
TheCache.prototype.addAll() API, which allows multiple entries to be added to the cache at once, previously violated a specification requirement that each request/response pair avoid overwriting another entry being added in the same call. Chrome would resolve such conflicts by storing the later entry and ignoring the earlier one. Cache.prototype.addAll() now rejects with an InvalidStateError.Intl.ListFormat
The new
Intl.ListFormat() API helps libraries and frameworks format a list in a localized fashion by providing internationalized messages using a customary local word or phrase when available. Here's an example:const lf = new Intl.ListFormat('en');
lf.format(['dogs']);
// → 'dogs'
lf.format(['dogs', 'cats']);
// → 'dogs and cats'
lf.format(['dogs', 'cats', 'hamsters']);
// → 'dogs, cats, and hamsters'
For more information, read our Web Fundamentals article.
Service worker improvements
FetchEvent.resultingClientId
FetchEvent.resultingClientId, set on navigation requests or requests for workers, is the ID of the client, either a document or a worker, and is created by the request. It's useful for associating the main resource request from a document with subsequent subresource requests from the same document, for example, for logging and metrics purposes.FetchEvents on requests for same-origin favicons.
Previously, technical limitations prevented service workers from receivingFetchEvent objects for favicon requests. Now, service workers will receive FetchEvent objects as long as the request URL is on the same origin as the service worker.MediaStreamTrack resizeMode constraint
A new property controls how the browser derives the resolution of aMediaStreamTrack. There are two supported values: "none": the track has the native resolution provided by the camera, its driver, or the operating system."crop-and-scale": the browser may use cropping and re-scaling to adjust the resolution of the video produced by the camera.
RTCPeerConnection.connectionState and RTCPeerConnection.onconnectionstatechanged
Chrome now supportsRTCPeerConnection.connectionState, which is an aggregate value computed from the transport states of the peerconnection's underlying ICE and DTLS transports. It's intended to provide a more complete overview of the connection state than RTCPeerConnection.iceConnectionState, which is only supposed to be based on the ICE transports.Well-formed JSON.stringify
A Stage 3 ECMAScript proposal changesJSON.stringify() to prevent it from returning ill-formed Unicode strings. Previously, JSON.stringify() would output lone surrogates themselves if the input contained any. With this change, JSON.stringify() outputs escape sequencesfor lone surrogates, making its output valid Unicode (and representable in UTF-8). The example below demonstrates how this works in practice.
JSON.stringify("\uD800");
- Previously, this returned '"�"'
- Starting in Chrome 72, this returns '"\ud800"'
Worker unhandled exception propagation
For dedicated workers, unhandled errors now propagate to the parent context and the error reporting process begins again one layer up (for example, to the window's onerror handler). This allows for errors to be propagated up to the original document, giving developers the freedom to choose when and how to handle worker errors.Interoperability Improvements
Interoperable File.webkitRelativePath property
TheFile.webkitRelativePathof the File interface previously returned a value different from other major browsers, now it returns the same value.
For example, if a user has the following local files:
/tmp/a/foo/bar/1.txt, /tmp/a/foo/2.txt
and they selected /tmp with a file chooser dialog, webkitRelativePath in Chrome was:
foo/bar/1.txt, foo/2.txt
Other browsers, which Chrome now matches, return this:
tmp/a/foo/bar/1.txt, tmp/a/foo/2.txt
Treat '#' as ending data URI body content
Chrome currently allows '#" symbols to exist in the body of a data URI in violation of the URL specification. More specifically, it treats a '#' as both part of the data body and the start of the URL fragment such that there is an overlap between the two components. Chrome now aligns with both the specification and Firefox by treating the first '#' of a data URL as the end of the data body and the start of the fragment.Removals
Don't allow popups during page unload
Pages may no longer usewindow.open() to open a new page during unload. The Chrome 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.
Remove HTTP-Based Public Key Pinning
HTTP-Based Public Key Pinning (HPKP) was intended to allow websites to send an HTTP header that pins one or more of the public keys present in the site's certificate chain. Unfortunately, it has very low adoption, and although it provides security against certificate mis-issuance, it also creates risks of denial of service and hostile pinning. For these reasons, this feature is being removed.Remove rendering FTP resources.
FTP is a non-securable legacy protocol. When even the linux kernel is migrating off of it, it's time to move on. One step toward deprecation and removal is to deprecate rendering resources from FTP servers and instead download them. Chrome will still generate directory listings, but any non-directory listing will be downloaded rather than rendered in the browser.Deprecations
Deprecate TLS 1.0 and TLS 1.1
TLS (Transport Layer Security) is the protocol which secures HTTPS. It has a long history stretching back to the nearly twenty-year-old TLS 1.0 and its even older predecessor, SSL. Both TLS 1.0 and 1.1 have a number of weaknesses.- TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the transcript hash for the Finished message.
- TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature. (Note: this is not the signature in the certificate.)
- TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken and has since been removed. TLS's CBC mode construction is flawed and was vulnerable to attacks.
- TLS 1.0's CBC ciphers additionally construct their initialization vectors incorrectly.
- TLS 1.0 is no longer PCI-DSS compliant.
Deprecate PaymentAddress.languageCode
PaymentAddress.languageCode is the browser's best guess for the language of the text in the shipping, billing, delivery, or pickup address in the Payment Request API. The languageCode is marked at risk in the specification and has already been removed from Firefox and Safari. Usage in Chrome is small enough for safe deprecation and removal. Removal is expected in Chrome 74.