Chrome Platform Status - Featureshttp://www.chromestatus.com/features2018-07-13T16:53:54ZImage Decode API: img.decode()2018-07-13T16:53:54ZChrome Platform Statustag:www.chromestatus.com,2018-07-13:/feature/5637156160667648/This change allows web developers to request to decode an img element. The call to a new HTML <img> element’s decode() function returns a promise, which, when fulfilled, ensures that the image can be appended to the DOM without causing a decoding delay on the next frame.ImageCapture support for focusDistance constraint2018-07-13T15:35:36ZChrome Platform Statustag:www.chromestatus.com,2018-07-13:/feature/5181454237564928/Image Capture API has an API for setting focusMode to manual, but it is not very useful if we cannot set focus distance. This API provides an interface for getting focus range values as well as setting focus distance value. ImageCapture support for exposureTime constraint2018-07-13T15:33:42ZChrome Platform Statustag:www.chromestatus.com,2018-07-13:/feature/5682072505024512/Image Capture API has an API for setting exposureMode to manual, but it was not very useful if the exposure time (aka shutter speed, aka exposure duration) cannot be set in manual exposure mode. This API provides an interface for getting the exposure time range values as well as setting the exposure time in time units.Remove OS build number from user-agent string2018-07-13T14:53:26ZChrome Platform Statustag:www.chromestatus.com,2018-07-13:/feature/4558585463832576/Remove the OS build number (e.g. “NJH47F” or “OPM4.171019.021.D1” on Android) from the user-agent identification, i.e. the User-Agent header and navigator.userAgent. This is to prevent abuse of that information such as exploit targeting and fingerprinting. Also to bring Chrome closer in line with RFC 7231 section 5.5.3.User Activation v22018-07-12T19:35:18ZChrome Platform Statustag:www.chromestatus.com,2018-07-12:/feature/5722065667620864/Browsers control access to "abusable" of APIs (e.g. opening popups or vibrating) through user activation (or "user gesture"). However, the web exposed behavior vary widely among major browsers. To unify the web, this feature defines a new user activation model that is simple enough for cross-browser implementation. The main changes introduced by this model are: (a) there is no concept of token passing, and (b) activation visibility changes from stack-scoped to frame-scoped.Three new network quality client hints2018-07-12T15:30:12ZChrome Platform Statustag:www.chromestatus.com,2018-07-12:/feature/5407907378102272/Three new client hints (and corresponding HTTP request headers) were added to convey the HTTP client's network connection speed. The headers surface the same data as the Network Information API to make it easy to make network speed-related decisions. The three new headers are “rtt”, “downlink”, and “ect” and they provide the same value as existing NetInfo APIs (navigator.connection.rtt, navigator.connection.downlink, and navigator.connection.effectiveType, respectively). Feature Policy: control synchronous script execution2018-07-11T21:35:48ZChrome Platform Statustag:www.chromestatus.com,2018-07-11:/feature/6218263637786624/Allows developers to selectively enable and disable use of synchronous script execution through the feature policy HTTP header or the <iframe> "allow" attribute. The identifier for the feature in policies is "sync-script". By default, synchronous script execution is allowed in all frames. If developers wish to disable this on any page, they can include a header like: Feature-Policy: sync-script 'none' Stronger popup blocker on sites with abusive experiences2018-07-11T19:30:30ZChrome Platform Statustag:www.chromestatus.com,2018-07-11:/feature/5243055179300864/On sites with very abusive experiences (see documentation link below), Chrome will start enforcing a more aggressive popup blocker. This will invoke Chrome's popup blocking UI for new windows or tabs regardless of whether there is a user gesture. Note: As of Chrome 69, Chrome will apply the stronger popup blocker on a site (e.g. destination.com) if it was redirected to from a site (e.g. source.com) that has abusive experiences. Stop showing ads on websites that are not compliant with the Better Ads Standards.2018-07-11T19:29:20ZChrome Platform Statustag:www.chromestatus.com,2018-07-11:/feature/5738264052891648/Stop showing ads (including those owned or served by Google) on websites that are not compliant with the Better Ads Standards(https://www.betterads.org/standards/). Introduction to this feature: https://blog.chromium.org/2017/06/improving-advertising-on-web.html Note: As of Chrome 69, Chrome will stop showing ads on a site (e.g. destination.com) if it was redirected to from a site (e.g. source.com) that is not compliant with the Better Ads Standard.Accept-Language Headers Fix2018-07-11T19:02:14ZChrome Platform Statustag:www.chromestatus.com,2018-07-11:/feature/4842627392339968/We want to fix an issue in how Chrome generates the Accept-Language HTTP headers from user language preferences. As websites sometimes only accept languages without region (i.e. “en” vs “en-AU”), a user could receive websites in an unexpected language. We plan to add the base language in the correct position so that users receive webpages in their preferred language.Web Locks API2018-07-11T17:05:03ZChrome Platform Statustag:www.chromestatus.com,2018-07-11:/feature/5712361335816192/The API allows script running in one tab to asynchronously acquire a lock, hold it while work is performed, then release it. While held, no other script in the origin can acquire the same lock. A lock represents some potentially shared resource, identified by a name chosen by the web app. For example, if a web app running in multiple tabs wants to ensure that only one tab is syncing to the network, each tab could try to acquire a "my_net_sync" lock, but only one tab will succeed. Reflect redirects to worker global scope's URL2018-07-11T14:11:57ZChrome Platform Statustag:www.chromestatus.com,2018-07-11:/feature/4816360374796288/Worker global scope's URL (self.location, referrer, and base URL) should reflect redirects (i.e. should be the response URL, not the request URL), according to the spec. The worker global scope's URL has been the response URL in Firefox and the request URL in Chromium/Safari/Edge. Chromium is changing it to the response URL to match with the spec. Spec issue: https://github.com/whatwg/html/issues/3760Window postMessage with options2018-07-10T17:53:14ZChrome Platform Statustag:www.chromestatus.com,2018-07-10:/feature/5548196159815680/Add a new Window.postMessage override that takes a dictionary as a 3rd argument. In order to add additional arguments to postMessage a dictionary should be allowed to be passed in. targetOrigin will be specified as a member of the options dictionary. window.postMessage('example', '/'); will be equivalent to window.postMessage('example'); and window.postMessage('example', 'http://example.com'); will be equivalent to window.postMessage('example', [], {targetOrigin: 'http://example.com'}); Feature Policy: Fullscreen2018-07-10T17:21:30ZChrome Platform Statustag:www.chromestatus.com,2018-07-10:/feature/5094837900541952/Allow developers to selectively enable and disable use of Fullscreen through the Feature-Policy HTTP header or the <iframe> "allow" attribute. The identifier for the feature in policies is "fullscreen". By default, fullscreen is allowed in all top-level documents, and in same-origin frames. This is similar to the existing <iframe> "allowfullscreen" attribute, but allows control over which origins will be allowed to use the feature when hosted inside of the frame. RTCRtpSender / RTCRtpReceiver.getCapabilities()2018-07-10T16:49:49ZChrome Platform Statustag:www.chromestatus.com,2018-07-10:/feature/6206698196828160/The getCapabilities() method returns the most optimistic view of the capabilities of the system for sending media of the given kind. It does not reserve any resources, ports, or other state but is meant to provide a way to discover the types of capabilities of the browser including which codecs or RTP extensions may be supported.