Chrome 55 Beta: Input handling improvements and async/await functions

Friday, October 21, 2016

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

Input handling improvements

As usage of the mobile web grows, it is increasingly important for sites to react well to touch input. Historically, this meant handling MouseEvent and TouchEvent separately, which can be difficult to maintain. Chrome now enables unified input handling by dispatching PointerEvents. PointerEvents lead to more responsive pages, as they don’t block scrolling by default. To achieve the same performance with TouchEvent, pages can use passive event listeners.

Chrome also now supports two new ways to respond to input. The touch-action CSS property enables sites to react to gestures such as panning. For mouse buttons, the new auxclick input event type allows sites to manage the click behavior of non-primary buttons.

Async and await functions

Asynchronous JavaScript can be difficult to reason about. Promises help avoid the nesting problem of callbacks, but Promise-based code can still be difficult to read when a site has large chains of asynchronous dependencies. Chrome now supports the async and await JavaScript keywords, allowing developers to write Promise-based JavaScript that can be as structured and readable as synchronous code.

Fetching a URL and logging the response using Promises:

function logFetch(url) {

return fetch(url)

.then(response => response.text())

.then(text => {

console.log(text);

}).catch(err => {

console.error('fetch failed', err);

});

}

The same code using async and await:

async function logFetch(url) {

try {

const response = await fetch(url);

console.log(await response.text());

}

catch (err) {

console.log('fetch failed', err);

}

CSS automatic hyphenation

Formatting text to fill available space can be a challenge across devices and screen sizes. Chrome now supports CSS automatic hyphenation, one of Chrome’s most frequently requested layout features, on Android and Mac. CSS hyphenation allows the browser to hyphenate words when line-wrapping, improving the visual consistency of text blocks. Hyphenation support will be extended to other platforms in future releases.

A paragraph rendered with and without automatic hyphenation

Other features in this release

The once event listener option enables callbacks to be invoked only once before removing the event listener.
Sites can now mark web storage as persistent, preventing Chrome from automatically clearing storage for that site.
Cross-origin iframes now require a user gesture to start audio playback using the Web Audio API on Android, matching the behavior of the <audio> and <video> elements.
The TLS stack now implements GREASE, a mechanism to help prevent problems with buggy TLS servers.
Developers can create a MediaStreamTrackEvent in an alternative way with its new JavaScript constructor.
RSA-PSS signature algorithms have been added to TLS to prepare for TLS 1.3.
To improve load times and prevent failed navigations, cross-origin and parser-blocking scripts injected using document.write() will no longer load over 2G connections.
AudioNode constructors of the form new AudioNode(context, options) are now available, making it simpler to manage audio from scripts.
When the media player is too narrow to show every button, an overflow menu will appear to provide the hidden functionality to users.
Chrome media controls will now display a download button when the playback is associated with a file that can be downloaded.
The Web Share API is available for experimentation as an origin trial.

Deprecations and interoperability improvements

BaseAudioContext will replace AudioContext in the Web Audio API to conform to spec.
CSS Clipping Path properties no longer require the webkit prefix.
The MediaStream constructor is now available without prefix alongside the existing webkitMediaStream.
Non-script MIME types will no longer trigger script execution.
<textarea maxlength=""> and <textarea minlength=""> have been updated to count each line break as one character, instead of two.
The webkit prefix has been removed from the imageSmoothingEnabled property of CanvasRenderingContext2D.

Posted by Dan Ehrenberg, Asynchronous Adventurer

Canary channel for Chrome on Android

Tuesday, October 18, 2016

Chrome supports multiple release channels with varying degrees of stability and support. The Canary channel ships the most bleeding edge version of Chrome possible. It is primarily intended to be used by developers and early adopters to test recent Chromium changes, but anyone can install it and give it a try. Previously the Canary channel was only available on Windows and Mac, and it is now available for Android as well.

Just like the Canary channel for other platforms, new versions are built from the most recent code available and often contain a variety of new features, enhancements, and bug fixes. These builds are shipped automatically with no manual testing, which means that the build can be unstable and may even stop working entirely for days at a time. However, the goal is for Canary to remain usable at all times, and the Chrome team prioritizes fixing major issues as quickly as possible.

Initially, builds will ship every weekday. In the future new builds may also be available on weekends. The frequency of builds means that keeping the app updated will consume a lot of data, typically more than 100MB per week. This is especially important for phones set to update native apps over cellular data.

We hope the Canary channel will be useful when developing and testing changes for Chrome on Android. If you encounter any bugs, please help us by reporting them.Posted by Alex Mineer, APK Administrator & Bug Basher

Chrome 54 Beta: Custom Elements V1, BroadcastChannel, and media platform improvements

Thursday, September 15, 2016

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

Custom Elements V1 Complex user interfaces often require a large amount of HTML. Most languages allow developers to create their own components built on top of language primitives to mitigate this kind of verbosity. Custom elements allow developers to create their own custom HTML tags, and define the new element’s API and behavior in JavaScript. This enables a browser-native way to build reusable, interoperable components.
Chrome 54 provides support for the latest custom elements V1 spec, which is broadly agreed-upon by major browser vendors. Chrome will also continue to support the V0 API until enough developers have moved to V1.

BroadcastChannel It is not uncommon for desktop users to have multiple windows or tabs open simultaneously. Some sites utilize this behavior, such as web editors that open documents in their own tabs. Historically, communicating between those tabs has been difficult. BroadcastChannel is a new one-to-many messaging API between windows, tabs, iframes, web workers, and service workers. It allows scripts to establish named channels to send messages between browsing contexts of the same origin.

Media platform improvements on Chrome for Android Media is an increasingly large and important part of the browsing experience on mobile devices that requires fluidly utilizing the entire screen. Developers can now use Element.requestFullScreen() to trigger full screen mode after a screen orientation change in addition to after a user gesture. This allows experiences like rotate-to-fullscreen for media players.
In addition to fullscreen improvements, Chrome on Android now persists the media notification of a backgrounded HTMLVideoElement, allowing a user to continue playing videos while they aren’t visible. Developers can detect background video playback by using the Page Visibility API.
Playing background videos in Chrome 54.

Other features in this release

Navigations initiated in an unload handler will be blocked and any prior navigation will continue.

The imageSmoothingQuality attribute for CanvasRenderingContext2D allows developers to balance performance and image quality by adjusting resolution when scaling.

Sites can use Node.getRootNode(options) to obtain the root for a given node.

Using PushSubscription.options, sites can track applicationServerKeys without having to store them offline.

The Resource Timing API now supports transfer, encoded, and decoded size attributes, allowing developers to measure cache hit rates and byte usage.

The user-select property enables developers to specify which elements can be selected by the user and how.

Foreign Fetch and WebUSB are available for experimentation as origin trials.

The text-size-adjust property allows sites to control whether font size automatically scales on mobile devices.

Deprecations and interoperability improvements

To match behavior in other browsers, embedded YouTube Flash players will be rewritten by Chrome to use the HTML5 embed style, improving performance and security on Chrome Desktop.
CacheQueryOptions now conforms to spec across all CacheStorage methods.
initTouchEvent has been removed in favor of the new TouchEvent() constructor.
SVGZoomEvent has been removed as it is no longer part of the SVG 2.0 spec.
SVGSVGElement.currentView, SVGSVGElement.useCurrentView, SVGViewSpec interface, and SVGSVGElement.viewport have been removed as they are no longer part of the SVG 2.0 spec.
SVGTests.requiredFeatures attribute has been deprecated since it no longer provides useful functionality in the SVG 2.0 spec.
SVGElement now supports the dataset property.
The KeyEvent.keyIdentifier field has been removed in favor of the KeyboardEvent.key field.
window.external.IsSearchProviderInstalled() and AddSearchProvider() are now no-ops, since they are unsupported in most other browsers.

Posted by Marijn Kruisselbrink, Broadcast Buccaneer

Moving Towards a More Secure Web

Thursday, September 8, 2016

To help users browse the web safely, Chrome indicates connection security with an icon in the address bar. Historically, Chrome has not explicitly labelled HTTP connections as non-secure. Beginning in January 2017 (Chrome 56), we’ll mark HTTP pages that collect passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure.

Chrome currently indicates HTTP connections with a neutral indicator. This doesn’t reflect the true lack of security for HTTP connections. When you load a website over HTTP, someone else on the network can look at or modify the site before it gets to you. released our HTTPS reportdo not perceiveOur plan

easier and cheaper than ever beforebestperformancepowerfulnewfeaturesset-up guidesPosted by Emily Schechter, Chrome Security Team

Chromium Blog

Chrome 55 Beta: Input handling improvements and async/await functions

Canary channel for Chrome on Android

Chrome 54 Beta: Custom Elements V1, BroadcastChannel, and media platform improvements

Moving Towards a More Secure Web

Labels

Archive

Feed