Deprecations and removals in Chrome 63

In nearly every version of Chrome, we see a significant number of updates and
improvements to the product, its performance, and also capabilities of the Web
Platform. This article describes some of the deprecations and removals in
Chrome 63, which is in beta as of October 26. Visit the
deprecations page
for more deprecations and removals from this and previous versions of Chrome.
This list is subject to change at any time.

Interface properties with a Promise type no longer throw exceptions

Interface properties and functions that return a promise have been inconsistent
about whether error conditions throw exceptions or reject, which would invoke a
promise's catch() block. The current version of the IDL
spec
calls for all promise-returning properties and functions to reject rather than
throw an exception.

For example, previously, a call to MediaKeySession.closed would throw a
TypeError for illegal invocation if called at the wrong time. With this change
such calls must now implement a catch() block.

This change brings Chrome inline with the specification. This change has already
been made for functions.

Remove getMatchedCSSRules()

The getMatchedCSSRules() method is a webkit-only API to get a list of all the
style rules applied to a particular element. Webkit has an open bug to remove
it. For these reasons it is
removed from Chrome in version 63. Developers who need this functionality can
look at this Stackoverflow post

Remove RTCRtcpMuxPolicy of "negotiate"

The rtcpMuxPolicy is used by Chrome to specify its preferred policy regarding
use of RTP/RTCP multiplexing. In Chrome 57, we changed the default
rtcpMuxPolicy to "require" and deprecated "negotiate" for following reasons:

Non-muxed RTCP uses extra network resources.

Removing "negotiate" will make the API surface simpler, since an
"RtpSender"/"RtpReceiver" will then only ever have a single transport.

Deprecation policy

To keep the platform healthy, we sometimes remove APIs from the Web Platform
which have run their course. There can be many reasons why we would remove an
API, such as:

They are superseded by newer APIs.

They are updated to reflect changes to specifications to bring alignment
and consistency with other browsers.

They are early experiments that never came to fruition in other browsers
and thus can increase the burden of support for web developers.

Some of these changes will have an effect on a very small number of sites. To
mitigate issues ahead of time, we try to give developers advanced notice so
they can make the required changes to keep their sites running.

Set warnings and give time scales in the Chrome DevTools Console when usage
is detected on the page.

Wait, monitor, and then remove the feature as usage drops.

You can find a list of all deprecated features on chromestatus.com using the
deprecated filter and removed features by applying the
removed filter.
We will also try to summarize some of the changes, reasoning, and migration
paths in these posts.