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. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 89 is beta as of January 28, 2021.

WebHID API

There is a long tail of human interface devices (HIDs) that are too new, too old, or too uncommon to be accessible by systems' device drivers. The WebHID API solves this by providing a way to implement device-specific logic in JavaScript.

A human interface device is one that takes input from or provides output to humans. Examples of devices include keyboards, pointing devices (mice, touchscreens, etc.), and gamepads.

The inability to access uncommon or unusual HID devices is particularly painful, for example, when it comes to gamepad support. Gamepad inputs and outputs are not well standardized and web browsers often require custom logic for specific devices. This is unsustainable and results in poor support for the long tail of older and uncommon devices.

With its origin trial over, WebHID is enabled by default in Chrome 89 on desktop. To learn how to use it, check out Connecting to uncommon HID devices, and see demos in Human interface devices on the web: a few quick examples.

Web NFC

NFC stands for Near Field Communications, a short-range wireless technology for transmitting small amounts of data, usually between a specialized NFC device and a reader. If you've scanned a badge to enter a building, you may have used NFC.

Web NFC allows a web app to read from and write to NFC tags. This opens new use cases to the web, including providing information about museum exhibits, inventory management, providing information in a conference badge, and many others. In Chrome 89 on Android, Web NFC is enabled by default.

Web NFC cards demo at Chrome Dev Summit

With NFC reading and writing are simple operations. You'll need a little instruction for constructing and interpreting payloads, but it's not complicated. Fortunately, we have an article, Interact with NFC devices on the web. Check it out. We have some samples you can play with. Here's a taste:

Writing a string to an NFC tag:

if ("NDEFReader" in window) {
  const ndef = new NDEFReader();
  await ndef.write("Hello world!");
}

Scanning messages from NFC tags:

if ("NDEFReader" in window) {
  const ndef = new NDEFReader();
  await ndef.scan();
  ndef. message }) => {
    console.log(`Records read from a NFC tag: ${message.records.length}`);
  };
}

Web Serial API

A serial port is a bidirectional communication interface that allows sending and receiving data byte by byte. The Web Serial API brings this capability to websites, letting them control devices such as microcontrollers and 3D printers.

In educational, hobbyist, and industrial settings, peripheral devices are already controlled through web pages. In all such cases device control requires installation of adapters and drivers. The Web Serial API improves the user experience by enabling direct communication between a website and a peripheral.

Its origin trial is over and the Web Serial API is now enabled on desktop. A demo is available on GitHub. For information about using it, see Read to and write from a serial port.

Web Sharing on Desktop

To allow users to easily share content on social networks, developers have manually integrated sharing buttons into their site for each social service. This often leads to users not being able to share with the services they actually use, in addition to bloated page sizes and security risks from third-party code. On the receiving end, only platform apps could register to be share targets and receive shares from other apps.

Chrome for Android started adding these features between Chrome 61 and 75. In Chrome 89, web sharing is available on Windows and ChromeOS, while registering as a share target is supported on ChromeOS. On these platforms, sites can now use navigator.share() on desktop to trigger a share dialog box. And an entry to the web app manifest allows a PWA to act as a share target.

For information on web sharing, see Integrate with the OS sharing UI with the Web Share API. To learn to configure a PWA as a share target, see Receiving shared data with the Web Share Target API.

Origin Trials

There are no new origin trials in this version of Chrome. To register for current origin trials, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

Other features in this release

AVIF Image Decode

Chrome now supports decoding AVIF content natively using existing AV1 decoders on Android and WebView. (Desktop support was added in Chrome 85.) AVIF is a next generation image format standardized by the Alliance for Open Media. There are three primary motivations for supporting AVIF:

  • Reducing bandwidth consumption to load pages faster and reduce overall data consumption. AVIF offers significant file size reduction for images compared with JPEG or WebP.
  • Adding HDR color support. AVIF is a path to HDR image support for the web. JPEG is limited in practice to 8-bit color depth. With displays increasingly capable of higher brightness, color bit depth, and color gamuts, web stakeholders are increasingly interested in preserving image data that is lost with JPEG.
  • Supporting ecosystem interest. Companies with a large web presence have expressed an interest in shipping AVIF images on the web.

Cross-origin opener policy reporting API

A new reporting API helps developers deploy cross-origin opener policy. In addition to reporting breakages when COOP is enforced, the API provides a report-only mode for COOP. The report-only mode for COOP will not enforce COOP, but it will report potential breakages that would have happened had we enforced COOP. Developers can inspect the reporting API with Chrome DevTools.

Display override in web app manifests

The new display_override field for the web app manifest allows developers to specify an explicit fallback chain for the display field. The following example specifies a "minimal-ui", falling back to "standalone".

{
  "display": "standalone",
  "display_override": ["minimal-ui"],
}

This API is intended for advanced use cases and display modes, and its capabilities are limited. You can learn more in its Chrome Status entry.

Expose ReadableStreamDefaultController interface

Chrome now exposes the ReadableStreamDefaultController interface on the global object, as with the other ReadableStream-related classes. This eliminates a previous limitation where instances had to be created inside stream constructors.

performance.measureUserAgentSpecificMemory()

The feature adds a performance.measureUserAgentSpecificMemory() function which estimates the memory usage of the web page. The method is gated behind COOP/COEP thus the web site needs to be cross-origin isolated to use it.

Potentially trustworthy data: urls

To conform to current web standards, Chrome now treats all data: urls as potentially trustworthy.
For background, It's often necessary to evaluate whether a URL is secure in order to only enable certain features when minimum standards of authentication and confidentiality are met. For that purpose, web standards rely on the definition of "potentially trustworthy URL", which includes URLs with the "data" scheme in the latest version of the Secure Contexts specification. Blink previously only treated some data: URLs as potential trustworthy.

Streams API: Byte Streams

The streams APIs provide ubiquitous, interoperable primitives for creating, composing, and consuming streams of data. For streams representing bytes, Chrome now supports an extended version of the readable stream to handle bytes efficiently, specifically by minimizing copies.


Byte streams allow for Bring Your Own Buffer (BYOB) readers to be acquired. The default implementation can give a range of different outputs such as strings or array buffers in the case of web sockets, whereas byte streams guarantee byte output. Furthermore, being able to have BYOB readers has stability benefits. This is because if a buffer detaches, there's now a guarantee that the same buffer won't be written to twice, hence avoiding race conditions. BYOB readers also do not need to garbage collect for every read, because buffers are reused.

Support for full 'filter' property syntax on SVG elements

Chrome now allows the full syntax of the 'filter' property to be used on SVG elements which previously only supported single url() references. This lets filter functions such as blur(), sepia() and grayscale() apply to both SVG elements and non-SVG elements. It makes the platform support for 'filter' more uniform and allows for easier application of some "canned" effects. Without this feature developers need to use a full SVG <filter> element definition even for basic filters such as grayscale() or blur().

WebAuthentication API: ResidentKeyRequirement and credProps extension

Chrome now supports two new features related to the Web Authentication API. The AuthenticatorSelectionCriteria.residentKey property specifies for web authentication credential registration whether a client-side discoverable credential should be created.

The Web Authentication credProps extension indicates to the relying party whether a created credential is client-side discoverable. "Client-side discoverable credentials" are a type of WebAuthn credential that can be challenged by a relying party without needing to provide the credential ID in the WebAuthn API request. Browsers display a list of all discoverable credentials from a given authenticator (either external security key or built-in) and let the user choose one to sign in with.

CSS

::target-text pseudo-element

Adds a highlight pseudo element to allow authors to style scroll-to-text fragments differently from the default user agent highlighting.

flow-relative Corner Rounding properties

Flow-relative corner rounding properties now allow control of corners using logical mappings rather than physical properties. Additionally, this allows authors to set different corner border radii depending on the direction and writing mode of the page.This brings Chrome in line with the CSS Logical Properties and Values spec. The following logical properties have been added:

  • border-start-start-radius
  • border-start-end-radius
  • border-end-start-radius
  • border-end-end-radius

Forced colors property

The forced-colors media feature detects whether the user agent is enforcing a user-chosen limited color palette on the page.

Forced colors adjust property

The forced-color-adjust property allows authors to opt particular elements out of forced colors mode, restoring full control over the colors to CSS.

JavaScript

This version of Chrome incorporates version 8.9 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent features in the V8 release notes.

Top-level await

Chrome now allows the await keyword at the top level within JavaScript modules. This allows more seamless integration of asynchronous calls into the module loading process. Today this is accomplished by wrapping modules in async functions, but this pushes complexity into dependent modules and exposes implementation details.

Developer Notes

Image Orientation with EXIF

EXIF information is now always used to orient cross-origin images. That is, setting image-orientation: none in CSS has no effect on non-secure-origin images. The spec discussion behind the change is available in a CSS working group draft.

Deprecations and Removals

This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.

Remove prefixed events for <link rel=prerender>

The legacy prefixed events (webkitprerenderstart, webkitprerenderstop, webkitprerenderload, and webkitprerenderdomcontentloaded) dispatched on <link rel=prerender> are now removed from Chrome.

Stop cloning sessionStorage for windows opened with noopener

When a window is opened with noopener, Chrome will no longer clone the sessionStorage of its opener; it will instead start an empty sessionStorage namespace. This brings Chrome in conformance with the HTML specification.

Labels:

A year ago we announced our intention to phase out third-party cookies and replace them with new browser features that are fundamentally more private. Since then, we've been working closely with the broader web community, including W3C, to design and implement new privacy-preserving technology, while also preserving the vitality and sustainability of the open web.

Today more than 30 different proposals have been offered by Chrome and others, including many that we believe are key to rendering third-party cookies obsolete. Early test results are also looking promising (see below)!

We are excited to continue testing this foundational tech with the active involvement of ecosystem partners and industry forums – all to move the web forward, together. What follows are key updates since our announcements last January and October.


Early results, and new proposals ready for testing
Five different Privacy Sandbox proposals are available for testing now – or will be very soon – in key areas like fraud detection, the tailoring of content, first-party treatment of a company’s owned and related domains, ads measurement, and a private-by-default way to request browser info. In fact, early testing of the Federated Learning of Cohorts (FloC) algorithm shows that new privacy-preserving ad solutions can be similarly effective to cookie-based approaches. This is great news for users, publishers, and advertisers – all of whom are critical for the future of the web – so we’re excited to carry this work forward.


Another important area of focus is user-facing controls. In particular, it’s clear that people will want to tune whether content is tailored to them (or not) – in addition to keeping their private info private. With the Chrome 90 release in April, we’ll be releasing the first controls for the Privacy Sandbox (first, a simple on/off), and we plan to expand on these controls in future Chrome releases, as more proposals reach the origin trial stage, and we receive more feedback from end users and industry. You can find a full update on all trials on our blog.


Involvement across the ecosystem
It’s great to see companies like Salesforce, White Ops, and Yahoo! JAPAN, starting (or preparing) to test initial solutions like Trust Tokens, First Party Sets, and Conversion Measurement. In fact, all developers have access to public Chrome experiments, and the latest guidance can be found on web.dev, so please do test and share feedback. This type of engagement helps ensure that the various APIs work as expected in real-world scenarios, so the more ecosystem participation, the better!


Building better. Together.
One of the things that makes the web so great is that it’s by and for all of us; this is a special quality amongst today’s platforms, and is definitely worth celebrating! It also creates complexity and trade-offs that we have to manage thoughtfully – and collectively – as we introduce new technology. That’s why we continue to engage in industry forums like the W3C, and are in active discussions with independent authorities –  including privacy regulators and the UK’s Competition and Markets Authority – to help identify and shape the best approach for online privacy, and the industry and world as a whole.


So here’s to the users, and coders, and advertisers, and content creators (and so many others) who’ve made, and continue to make the platform what it is today. And here’s to coming together, in service of a more private web.


Posted by Justin Schuh - Director, Chrome Engineering
Labels:

Custom Tabs is a browser feature, introduced by Chrome, that is now supported by most major browsers on Android. It gives apps more control over their web experience, and makes transitions between native and web content more seamless without having to resort to a WebView. Similar to when using the browser, users frequently want to share the content that is rendered inside the Custom Tabs.

Custom Tabs do not provide a default sharing experience and many apps don’t provide a way for users to share content at all. This results in a poor user experience where users must find the share action from the overflow menu in the browser. This action takes the user outside of the app and opens the link in the browser, resulting in decreased app engagement.

In Chrome 88 we're running an experiment to automatically add a default share action in certain scenarios. For example, where an app has not specified its own Action Button, we will display one in the top bar. Where a site has specified its own top bar Action Button, a default share action is added to the overflow menu.


A default Action Button that shares the URL is added to the top bar when the application doesn’t provide one.

What do I need to do to enable the new default share action button in?Nothing! The default Action Button will be automatically added to the application, as long as the application doesn’t set its own. Since this change will happen in the browser, it will be automatically applied to all apps using Custom Tabs.

Please note: this is a change in Chrome’s behavior and we hope other browsers will add similar functionality.


How can I opt-out from the share icon showing in my App?
Starting with androidx.browser version 1.3.0, developers can use the setShareState() method from the CustomTabsIntent.Builder to disable the default share:

val customTabsIntent = CustomTabsIntent.Builder()

        .setShareState(CustomTabsIntent.SHARE_STATE_OFF)

        .build();


As part of this change, the addDefaultShareMenuItem() and setDefaultShareMenuItemEnabled() methods from CustomTabsIntent.Builder have been deprecated and developers should use setShareState() instead.


If your application uses Custom Tabs, we’d like to hear your feedback, and you can reach out to us using this form.


Posted by André Bandarra, Developer Relations Engineer and Chirag Desai, Product Manager

Labels: , , ,

During a recent audit, we discovered that some third-party Chromium based browsers were able to integrate Google features, such as Chrome sync and Click to Call, that are only intended for Google’s use. This meant that a small fraction of users could sign into their Google Account and store their personal Chrome sync data, such as bookmarks, not just with Google Chrome, but also with some third-party Chromium based browsers. We are limiting access to our private Chrome APIs starting on March 15, 2021.


For users who accessed Google features (like Chrome sync) through a third-party Chromium based browser, their data will continue to be available in their Google Account, and data that they have stored locally will continue to be available locally. As always, users can view and manage their data on the My Google Activity page. They can also download their data from the Google Takeout page, and/or delete it here. 

Guidance for vendors of third-party Chromium based products is available on the Chromium wiki.



Posted by Jochen Eisinger, Engineering Director, Google Chrome 
Labels: