WorryFree Computers   »   [go: up one dir, main page]

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 71 on ChromeStatus.com. Chrome 71 is beta as of October 25, 2018.

International Relative Time Format

When writing (and speaking), phrases such as 'yesterday' or 'in three months' are common. Yet such phrases are not part of built-in date and time APIs. To fill this need, libraries provide utility functions to provide localized versions of such phrases. The downside to this approach is that using these functions on the web requires downloading lists of customary words or phrases for each supported language. This increases a library's bundle size and download time.

Chrome 71 introduces Intl.RelativeTimeFormat(), which shifts the burden to the JavaScript engine. A few examples show how this works.


const rtf = new Intl.RelativeTimeFormat('en');

rtf.format(3.14, 'second');
// → 'in 3.14 seconds'

rtf.format(-15, 'minute');
// → '15 minutes ago'

This new API has a number of capabilities beyond what is shown here including such things as retrieving information for multiple languages, dealing with parts of a date or time individually (in other words, formatToParts()), and more. Read our article for details.

Other features in this release

Add FullscreenOptions

The Element.requestFullscreen() method can now be customized on Android using an optional options parameter. Its navigationUI parameter allows you to choose between making the navigation bar visible versus a completely immersive mode where no user agent controls are shown until a gesture is performed. Possible values are "auto", "show", and "hide". This value expresses an application preference, with "auto" meaning no preference. The UI may overrule this vale in any case.

Add 'persistent-storage' property to the Permission API

The "persistent-storage" property is a new permission for the Permission API. The permission state can already be queried with navigator.storage.persisted(), with this change navigator.permissions.query({name:"persistent-storage"}) can be used as well.

Async touchpad pinch zoom events

Async touchpad pinch zoom events are for improving the page pinch zoom performance. Currently, the touchpad pinch zoom exposes a control wheel event that allows JS to cancel it. With this change, if the user doesn't make a pinch action on the touchpad, effectively canceling the control wheel event, then following control wheel events are not cancelable. But JavaScript does not know which ctrl wheel is the first one in the sequence, so if you want to cancel pinch zoom, you need to cancel all of them.

COLR/CPAL font support

Chrome now supports COLR/CPAL fonts which are a type of OpenType color font composed of layers of vector outline glyphs and color palette information into the final colored glyph. With this change, Chrome supports three color font formats cross-platform, the other two being CBDT/CBLC and SBIX. Because they are vector based, COLR/CPAL fonts provide for faster downloads and require less storage. An example of a COLR/CPAL font is the Twemoji color font.

CSS gradient color stop double-position syntax

Support is added for the stop position syntax from the CSS Image Values and Replaced Content Module Level 4 spec. Currently, repeating colors require explicit positions. For example:

linear-gradient(45deg, black 25%, black 50%, white 50%, white 75%)

To simplify the definition of solid color bands, two positions may be specified instead. For example: 

linear-gradient(45deg, black 25% 50%, white 50% 75%)

Implement 'left' and 'right' values for 'text-underline-position'

Currently, in vertical flow for Chinese and Japanese, which side the underline appears on is not the same across browsers. To fix this, Chrome is adding support for 'left' and 'right' values of the 'text-underline-position' property. This property is part of the CSS3 Text Decoration spec which adds properties that implement new text decoration styling features such as lines, color, and style, including 'text-underline-position'.

JavaScript Modules: Credentials mode defaults to "same-origin"

The default credentials mode for module script requests is changing from "omit" to "same-origin", providing credentials to same-origin module script requests and their descendant scripts (static and dynamic imports). The current behavior can be surprising in that it's misaligned with other high-level features like the Fetch API, and in the web platform's current architecture, causes a second server connection. This is undesirable for developers looking to reduce latency.

TextEncoderStream and TextDecoderStream APIs

Text encoding and decoding supports streams to enable you to easily convert streams of binary data to text and vice-versa. An example of its usefulness is with readable streams. With a non-stream Response object, response.body.text() returns text. There is no equivalent for the ReadableStream returned by Response.Body, which can only return bytes. With the new API a streaming response body may be converted to text as so: Response.Body.pipeThrough(new TextDecoderStream()).

Unprefixed Fullscreen API

The Fullscreen API has features for entering, and exiting fullscreen mode as well as event handlers for monitoring such changes. A prefixed version of the API has been supported since Chrome 15. This update adds an unprefixed version of the API.

MediaElement and MediaStream nodes defined only for AudioContext

Chrome now only allows creation of MediaElementAudioSourceNode, MediaStreamAudioSourceNode, and MediaStreamAudioDestinationNode elements using an AudioContext. Previously these could be created using an OfflineAudioContext, but that does not comply with the spec. The behavior with an OfflineAudioContext is not well-defined and contrary to the real-time nature of the nodes themselves.

Interoperability improvements

Call capture event listeners in capturing phase at shadow hosts

To be interoperable with other browsers, Chrome now calls capture event listeners in the capturing phase at shadow hosts. Previously this was done in the bubbling phase on Chrome. A complete discussion may be read on the WHATWG repo on GitHub.

Improve :host, :host-context, and ::slotted specificity

Chrome now calculates the specificity for the :host() and :host-context() pseudo classes as well as for the arguments for ::slotted(). This brings it into compliance with the Shadow DOM v1 spec.
Shipping this will ensure interoperability between browsers since other browsers have or are about to ship this in their stable releases.

Deprecations and Removals

Chrome sometimes deprecates, removes, or changes features to increase interoperability with other browsers. This version of Chrome includes the following such changes.

Remove SpeechSynthesis.speak without user activation

The speechSynthesis.speak() method now fires an error if the document has not received user activation. This API is being abused by sites since it is one of the only remaining APIs which didn't adhere to autoplay policies in Chrome.

Remove importScripts() of new scripts after service worker installation.

Previously, a service worker could use importScripts() to import any script at any time. After this change, a service worker can only use importScripts() in two cases:
  • Before installation finishes (from the initial execution of the service worker until it reaches the `installed` state).
  • After installation finishes, only for scripts that were already imported in the previous phase.

Remove prefixed versions of several APIs

Chrome has removed non-standard aliases for two widely supported standard interfaces.

Remove URL.createObjectURL for MediaStream

The URL.createObjectURL() method has been removed from the MediaStream interface. This method has been deprecated in 2013 and superseded by assigning streams to srcObject.

Remove document.origin

The document.origin property has been removed. This property was only ever implemented in Chromium and WebKit. It is redundant with self.origin which can be used in both window and worker contexts and has wider support.
Labels:


Incredibly, it’s been nearly a decade since we launched the Chrome extensions system. Thanks to the hard work and innovation of our developer community, there are now more than 180,000 extensions in the Chrome Web Store, and nearly half of Chrome desktop users actively use extensions to customize Chrome and their experience on the web.
The extensions team's dual mission is to help users tailor Chrome’s functionality to their individual needs and interests, and to empower developers to build rich and useful extensions. But, first and foremost, it’s crucial that users be able to trust the extensions they install are safe, privacy-preserving, and performant. Users should always have full transparency about the scope of their extensions’ capabilities and data access.
We’ve recently taken a number of steps toward improved extension security with the launch of out-of-process iframes, the removal of inline installation, and significant advancements in our ability to detect and block malicious extensions using machine learning. Looking ahead, there are more fundamental changes needed so that all Chrome extensions are trustworthy by default.
Today we’re announcing some upcoming changes and plans for the future:
User controls for host permissions
Beginning in Chrome 70, users will have the choice to restrict extension host access to a custom list of sites, or to configure extensions to require a click to gain access to the current page.



While host permissions have enabled thousands of powerful and creative extension use cases, they have also led to a broad range of misuse - both malicious and unintentional - because they allow extensions to automatically read and change data on websites. Our aim is to improve user transparency and control over when extensions are able to access site data. In subsequent milestones, we’ll continue to optimize the user experience toward this goal while improving usability. If your extension requests host permissions, we encourage you to review our transition guide and begin testing as soon as possible.

Changes to the extensions review process
Going forward, extensions that request powerful permissions will be subject to additional compliance review. We’re also looking very closely at extensions that use remotely hosted code, with ongoing monitoring. Your extension’s permissions should be as narrowly-scoped as possible, and all your code should be included directly in the extension package, to minimize review time.

New code readability requirements
Starting today, Chrome Web Store will no longer allow extensions with obfuscated code. This includes code within the extension package as well as any external code or resource fetched from the web. This policy applies immediately to all new extension submissions. Existing extensions with obfuscated code can continue to submit updates over the next 90 days, but will be removed from the Chrome Web Store in early January if not compliant.
Today over 70% of malicious and policy violating extensions that we block from Chrome Web Store contain obfuscated code. At the same time, because obfuscation is mainly used to conceal code functionality, it adds a great deal of complexity to our review process. This is no longer acceptable given the aforementioned review process changes.


Additionally, since JavaScript code is always running locally on the user's machine, obfuscation is insufficient to protect proprietary code from a truly motivated reverse engineer. Obfuscation techniques also come with hefty performance costs such as slower execution and increased file and memory footprints.
Ordinary minification, on the other hand, typically speeds up code execution as it reduces code size, and is much more straightforward to review. Thus, minification will still be allowed, including the following techniques:

  • Removal of whitespace, newlines, code comments, and block delimiters
  • Shortening of variable and function names
  • Collapsing the number of JavaScript files
If you have an extension in the store with obfuscated code, please review our updated content policies as well as our recommended minification techniques for Google Developers, and submit a new compliant version before January 1st, 2019.
Required 2-Step Verification
In 2019, enrollment in 2-Step Verification will be required for Chrome Web Store developer accounts. If your extension becomes popular, it can attract attackers who want to steal it by hijacking your account, and 2-Step Verification adds an extra layer of security by requiring a second authentication step from your phone or a physical security key. We strongly recommend that you enroll as soon as possible.

For even stronger account security, consider the Advanced Protection Program. Advanced protection offers the same level of security that Google relies on for its own employees, requiring a physical security key to provide the strongest defense against phishing attacks.

Looking ahead: Manifest v3
In 2019 we will introduce the next extensions manifest version. Manifest v3 will entail additional platform changes that aim to create stronger security, privacy, and performance guarantees. We want to help all developers fall into the pit of success; writing a secure and performant extension in Manifest v3 should be easy, while writing an insecure or non-performant extension should be difficult.


Some key goals of manifest v3 include:
  • More narrowly-scoped and declarative APIs, to decrease the need for overly-broad access and enable more performant implementation by the browser, while preserving important functionality
  • Additional, easier mechanisms for users to control the permissions granted to extensions
  • Modernizing to align with new web capabilities, such as supporting Service Workers as a new type of background process

We intend to make the transition to manifest v3 as smooth as possible and we’re thinking carefully about the rollout plan. We’ll be in touch soon with more specific details.


We recognize that some of the changes announced today may require effort in the future, depending on your extension. But we believe the collective result will be worth that effort for all users, developers, and for the long term health of the Chrome extensions ecosystem. We’re committed to working with you to transition through these changes and are very interested in your feedback. If you have questions or comments, please get in touch with us on the Chromium extensions forum.
Posted by James Wagner, Chrome Extensions Product Manager

Labels: , , ,