Planet Chromium

February 22, 2017

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 58.0.3018.3/4 for Windows and 58.0.3018.3 for Mac and Linux.


A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Abdul Syed
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 22, 2017 03:01 PM

Beta Channel Update for Desktop

The beta channel has been updated to 57.0.2987.74 for Windows, Mac, and Linux.


A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 22, 2017 12:38 PM

February 17, 2017

V8 JavaScript Engine

High-performance ES2015 and beyond

Over the last couple of months the V8 team focused on bringing the performance of newly added ES2015 and other even more recent JavaScript features on par with their transpiled ES5 counterparts.

Motivation

Before we go into the details of the various improvements, we should first consider why performance of ES2015+ features matter despite the widespread usage of Babel in modern web development:
  1. First of all there are new ES2015 features that are only polyfilled on demand, for example the Object.assign builtin. When Babel transpiles object spread properties (which are heavily used by many React and Redux applications), it relies on Object.assign instead of an ES5 equivalent if the VM supports it.
  2. Polyfilling ES2015 features typically increases code size, which contributes significantly to the current web performance crisis, especially on mobile devices common in emerging markets. So the cost of just delivering, parsing and compiling the code can be fairly high, even before you get to the actual execution cost.
  3. And last but not least, the client side JavaScript is only one of the environments that relies on the V8 engine. There’s also Node.js for server side applications and tools, where developers don’t need to transpile to ES5 code, but can directly use the features supported by the relevant V8 version in the target Node.js release.
Let’s consider the following code snippet from the Redux documentation:


function todoApp(state = initialState, action) {
switch (action.type) {
case SET_VISIBILITY_FILTER:
return { ...state, visibilityFilter: action.filter }
default:
return state
}
}

There are two things in that code that demand transpilation: the default parameter for state and the spreading of state into the object literal. Babel generates the following ES5 code:


"use strict";

var _extends = Object.assign || function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; };

function todoApp() {
var state = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : initialState;
var action = arguments[1];

switch (action.type) {
case SET_VISIBILITY_FILTER:
return _extends({}, state, { visibilityFilter: action.filter });
default:
return state;
}
}

Now imagine that Object.assign is orders of magnitude slower than the polyfilled _extends generated by Babel. In that case upgrading from a browser that doesn’t support Object.assign to an ES2015 capable version of the browser would be a serious performance regression and probably hinder adoption of ES2015 in the wild.

This example also highlights another important drawback of transpilation: The generated code that is shipped to the user is usually considerably bigger than the ES2015+ code that the developer initially wrote. In the example above, the original code is 203 characters (176 bytes gzipped) whereas the generated code is 588 characters (367 bytes gzipped). That’s already a factor of two increase in size. Let’s look at another example from the Async Iterators for JavaScript proposal:


async function* readLines(path) {
let file = await fileOpen(path);

try {
while (!file.EOF) {
yield await file.readLine();
}
} finally {
await file.close();
}
}

Babel translates these 187 characters (150 bytes gzipped) into a whopping 2987 characters (971 bytes gzipped) of ES5 code, not even counting the regenerator runtime that is required as an additional dependency:


"use strict";

var _asyncGenerator = function () { function AwaitValue(value) { this.value = value; } function AsyncGenerator(gen) { var front, back; function send(key, arg) { return new Promise(function (resolve, reject) { var request = { key: key, arg: arg, resolve: resolve, reject: reject, next: null }; if (back) { back = back.next = request; } else { front = back = request; resume(key, arg); } }); } function resume(key, arg) { try { var result = gen[key](arg); var value = result.value; if (value instanceof AwaitValue) { Promise.resolve(value.value).then(function (arg) { resume("next", arg); }, function (arg) { resume("throw", arg); }); } else { settle(result.done ? "return" : "normal", result.value); } } catch (err) { settle("throw", err); } } function settle(type, value) { switch (type) { case "return": front.resolve({ value: value, done: true }); break; case "throw": front.reject(value); break; default: front.resolve({ value: value, done: false }); break; } front = front.next; if (front) { resume(front.key, front.arg); } else { back = null; } } this._invoke = send; if (typeof gen.return !== "function") { this.return = undefined; } } if (typeof Symbol === "function" && Symbol.asyncIterator) { AsyncGenerator.prototype[Symbol.asyncIterator] = function () { return this; }; } AsyncGenerator.prototype.next = function (arg) { return this._invoke("next", arg); }; AsyncGenerator.prototype.throw = function (arg) { return this._invoke("throw", arg); }; AsyncGenerator.prototype.return = function (arg) { return this._invoke("return", arg); }; return { wrap: function wrap(fn) { return function () { return new AsyncGenerator(fn.apply(this, arguments)); }; }, await: function await(value) { return new AwaitValue(value); } }; }();

var readLines = function () {
var _ref = _asyncGenerator.wrap(regeneratorRuntime.mark(function _callee(path) {
var file;
return regeneratorRuntime.wrap(function _callee$(_context) {
while (1) {
switch (_context.prev = _context.next) {
case 0:
_context.next = 2;
return _asyncGenerator.await(fileOpen(path));

case 2:
file = _context.sent;
_context.prev = 3;

case 4:
if (file.EOF) {
_context.next = 11;
break;
}

_context.next = 7;
return _asyncGenerator.await(file.readLine());

case 7:
_context.next = 9;
return _context.sent;

case 9:
_context.next = 4;
break;

case 11:
_context.prev = 11;
_context.next = 14;
return _asyncGenerator.await(file.close());

case 14:
return _context.finish(11);

case 15:
case "end":
return _context.stop();
}
}
}, _callee, this, [[3,, 11, 15]]);
}));

return function readLines(_x) {
return _ref.apply(this, arguments);
};
}();

This is a 650% increase in size (the generic _asyncGenerator function might be shareable depending on how you bundle your code, so you can amortize some of that cost across multiple uses of async iterators). We don’t think it’s viable to ship only code transpiled to ES5 long-term, as the increase in size will not only affect download time/cost, but will also add additional overhead to parsing and compilation. If we really want to drastically improve page load and snappiness of modern web applications, especially on mobile devices, we have to encourage developers to not only use ES2015+ when writing code, but also to ship that instead of transpiling to ES5. Only deliver fully transpiled bundles to legacy browsers that don’t support ES2015. For VM implementors, this vision means we need to support ES2015+ features natively and provide reasonable performance.

Measurement methodology

As described above, absolute performance of ES2015+ features is not really an issue at this point. Instead the highest priority currently is to ensure that performance of ES2015+ features is on par with their naive ES5 and even more importantly, with the version generated by Babel. Conveniently there was already a project called six-speed by Kevin Decker, that accomplishes more or less exactly what we needed: a performance comparison of ES2015 features vs. naive ES5 vs. code generated by transpilers.

Six-Speed benchmark


So we decided to take that as the basis for our initial ES2015+ performance work. We forked it and added a couple of benchmarks. We focused on the most serious regressions first, i.e. line items where slowdown from naive ES5 to recommended ES2015+ version was above 2x, because our fundamental assumption is that the naive ES5 version will be at least as fast as the somewhat spec-compliant version that Babel generates.

A modern architecture for a modern language

In the past V8’s had difficulties optimizing the kind of language features that are found in ES2015+. For example, it never became feasible to add exception handling (i.e. try/catch/finally) support to Crankshaft, V8’s classic optimizing compiler. This meant V8’s ability to optimize an ES6 feature like for...of, which essentially has an implicit finally clause, was limited. Crankshaft’s limitations and the overall complexity of adding new language features to full-codegen, V8’s baseline compiler, made it inherently difficult to ensure new ES features were added and optimized in V8 as quickly as they were standardized.

Fortunately, Ignition and TurboFan (V8’s new interpreter and compiler pipeline), were designed to support the entire JavaScript language from the beginning, including advanced control flow, exception handling, and most recently for...of and destructuring from ES2015. The tight integration of the architecture of Ignition and TurboFan make it possible to quickly add new features and to optimize them fast and incrementally.

Many of the improvements we achieved for modern language features were only feasible with the new Ignition/Turbofan pipeline. Ignition and TurboFan proved especially critical to optimizing generators and async functions. Generators had long been supported by V8, but were not optimizable due to control flow limitations in Crankshaft. Async functions are essentially sugar on top of generators, so they fall into the same category. The new compiler pipeline leverages Ignition to make sense of the AST and generate bytecodes which de-sugar complex generator control flow into simpler local-control flow bytecodes. TurboFan can more easily optimize the resulting bytecodes since it doesn’t need to know anything specific about generator control flow, just how to save and restore a function’s state on yields.

How JavaScript generators are represented in Ignition and TurboFan

State of the union

Our short-term goal was to reach less than 2x slowdown on average as soon as possible. We started by looking at the worst test first, and from Chrome M54 to Chrome M58 (Canary) we managed to reduce the number of tests with slowdown above 2x from 16 to 8, and at the same time reduce the worst slowdown from 19x in M54 to just 6x in M58 (Canary). We also significantly reduced the average and median slowdown during that period:


You can see a clear trend towards parity of ES2015+ and ES5. On average we improved performance relative to ES5 by over 47%. Here are some highlights that we addressed since M54.


Most notably we improved performance of new language constructs that are based on iteration, like the spread operator, destructuring and for...of loops. For example, using array destructuring


function fn() {
var [c] = data;
return c;
}

is now as fast as the naive ES5 version


function fn() {
var c = data[0];
return c;
}

and a lot faster (and shorter) than the Babel generated code:


"use strict";

var _slicedToArray = function () { function sliceIterator(arr, i) { var _arr = []; var _n = true; var _d = false; var _e = undefined; try { for (var _i = arr[Symbol.iterator](), _s; !(_n = (_s = _i.next()).done); _n = true) { _arr.push(_s.value); if (i && _arr.length === i) break; } } catch (err) { _d = true; _e = err; } finally { try { if (!_n && _i["return"]) _i["return"](); } finally { if (_d) throw _e; } } return _arr; } return function (arr, i) { if (Array.isArray(arr)) { return arr; } else if (Symbol.iterator in Object(arr)) { return sliceIterator(arr, i); } else { throw new TypeError("Invalid attempt to destructure non-iterable instance"); } }; }();

function fn() {
var _data = data,
_data2 = _slicedToArray(_data, 1),
c = _data2[0];

return c;
}

You can check out the High-Speed ES2015 talk we gave at the last Munich NodeJS User Group meetup for additional details:



We are committed to continue improving the performance of ES2015+ features. In case you are interested in the nitty-gritty details please have a look at V8's ES2015 and beyond performance plan.

Posted by Benedikt Meurer @bmeurer, EcmaScript Performance Engineer

by Michael Hablich (noreply@blogger.com) at February 17, 2017 02:29 PM

February 16, 2017

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 58.0.3013.3/5 for Windows and 58.0.3013.3 for Mac and Linux.


A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Abdul Syed
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 16, 2017 01:27 PM

February 15, 2017

Google Chrome Releases

Beta Channel Update for Desktop

The beta channel has been updated to 57.0.2987.54 for Windows, Mac, and Linux.


A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 15, 2017 12:33 PM

February 14, 2017

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 58.0.3007.0 (Platform version: 9280.0.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements. A list of changes can be found here.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser). 

Bernie Thompson
Google Chrome

by Bernie Thompson (noreply@blogger.com) at February 14, 2017 05:43 PM

V8 JavaScript Engine

Help us test the future of V8!

The V8 team is currently working on a new default compiler pipeline that will help us bring future speedups to real-world JavaScript. You can preview the new pipeline in Chrome Canary today to help us verify that there are no surprises when we roll out the new configuration for all Chrome channels.

The new compiler pipeline uses the Ignition interpreter and Turbofan compiler to execute all JavaScript (in place of the classic pipeline which consisted of the FullCodegen and Crankshaft compilers). A random subset of Chrome Canary and Chrome Developer channel users are already testing the new configuration. However, anyone can opt-in to the new pipeline (or revert to the old one) by flipping a flag in about:flags.

You can help test the new pipeline by opting-in and using it with Chrome on your favorite web sites. If you are a web developer, please test your web applications with the new compiler pipeline. If you notice a regression in stability, correctness, or performance, please report the issue to the V8 bug tracker.

How to enable the new pipeline

  1. Install the latest Canary
  2. Open URL "about:flags" in Chrome
  3. Search for "Experimental JavaScript Compilation Pipeline" and set it to "Enabled"

How to report problems

Please let us know if your browsing experience changes significantly when using the new pipeline over the default pipeline. If you are a web developer, please test the performance of the new pipeline on your (mobile) web application to see how it is affected. If you discover that your web application is behaving strange (or tests are failing), please let us know:
  1. Ensure that you have correctly enabled the new pipeline as outlined in the previous section.
  2. Create a bug on V8's bug tracker.
  3. Attach sample code which we can use to reproduce the problem.
Posted by Daniel Clifford @expatdanno, Original Munich V8 Brewer

by Michael Hablich (noreply@blogger.com) at February 14, 2017 12:40 PM

February 09, 2017

Google Chrome

Program Manager

The new version of ChromeVox is now the default screen reader on all Chromebooks.

by Laura Palmaro at February 09, 2017 11:00 PM

Product Manager and collector of VR headsets

We want to bring Virtual Reality (VR) to everyone on any device, and in the coming months we’ll add support for more headsets, including Google Cardboard. Try out these VR-enabled sites to be one of the first to experience the magic of VR on the web.

by Megan Lindsay at February 09, 2017 06:00 PM

V8 JavaScript Engine

One small step for Chrome, one giant heap for V8

V8 has a hard limit on its heap size. This serves as a safeguard against applications with memory leaks. When an application reaches this hard limit, V8 does a series of last resort garbage collections. If the garbage collections do not help to free memory V8 stops execution and reports an out-of-memory failure. Without the hard limit a memory leaking application could use up all system memory hurting the performance of other applications.

Ironically, this safeguard mechanism makes investigation of memory leaks harder for JavaScript developers. The application can run out of memory before the developer manages to inspect the heap in DevTools. Moreover the DevTools process itself can run out memory because it uses an ordinary V8 instance. For example, taking a heap snapshot of this demo will abort execution due to out-of-memory on the current stable Chrome.

Historically the V8 heap limit was conveniently set to fit the signed 32-bit integer range with some margin. Over time this convenience lead to sloppy code in V8 that mixed types of different bit widths, effectively breaking the ability to increase the limit. Recently we cleaned up the garbage collector code, enabling the use of larger heap sizes. DevTools already makes use of this feature and taking a heap snapshot in the previously mentioned demo works as expected in the latest Chrome Canary.

We also added a feature in DevTools to pause the application when it is close to running out of memory. This feature is useful to investigate bugs that cause the application to allocate a lot of memory in a short period of time. When running this demo with the latest Chrome Canary, DevTools pauses the application before the out-of-memory failure and increases the heap limit, giving the user a chance to inspect the heap, evaluate expressions on the console to free memory and then resume execution for further debugging.


V8 embedders can increase the heap limit using the set_max_old_space_size function of the ResourceConstraints API. But watch out, some phases in the garbage collector have a linear dependency on the heap size. Garbage collection pauses may increase with larger heaps.

Posted by guardians of heap Ulan Degenbaev, Hannes Payer, Michael Lippautz and DevTools master Alexey Kozyatinskiy.

by Michael Hablich (noreply@blogger.com) at February 09, 2017 10:40 AM

February 08, 2017

Google Chrome Releases

Beta Channel Update for Desktop

The beta channel has been updated to 57.0.2987.37 for Windows, Mac, and Linux.


A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 08, 2017 02:24 PM

Stable Channel Update for Chrome OS

The Stable channel has been updated to 56.0.2924.87 (Platform version: 9000.82.0) for all Chrome OS devices except for ASUS Chromebook Flip C100PA,  Google Chromebook Pixel (2015), Acer Chromebook R11. This build contains a number of bug fixes, security updates, and feature enhancements. Systems will be receiving updates over the next several days.

Some highlights of these changes are:

  • Material Design Chrome OS shelf and system menu
  • Flash Component Updater for Chrome OS
  • New version of the ChromeVox screen reader is now the default across all Chromebooks

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser).

Grace Kihumba
Google Chrome

by Grace Kihumba (noreply@blogger.com) at February 08, 2017 10:23 AM

February 07, 2017

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 58.0.3004.3/4 for Windows and 58.0.3004.3 for Mac and Linux.


A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Abdul Syed
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 07, 2017 02:15 PM

February 06, 2017

V8 JavaScript Engine

V8 Release 5.7


Every six weeks, we create a new branch of V8 as part of our release process. Each version is branched from V8’s git master immediately before a Chrome Beta milestone. Today we’re pleased to announce our newest branch, V8 version 5.7, which will be in beta until it is released in coordination with Chrome 57 Stable in several weeks. V8 5.7 is filled will all sorts of developer-facing goodies. We’d like to give you a preview of some of the highlights in anticipation of the release.

Performance improvements

Native async functions as fast as promises

Async functions are now approximately as fast as the same code written with promises. The execution performance of async functions quadrupled according to our microbenchmarks. During the same period, overall promise performance also doubled.

Async performance improvements in V8 on Linux x64

Continued ES2015 improvements

V8 continues to make ES2015 language features faster so that developers use new features without incurring performance costs. The spread operator, destructuring and generators are now approximately as fast as their naive ES5 equivalents.

RegExp 15 % faster

Migrating RegExp functions from a self-hosted JavaScript implementation to one that hooks into TurboFan’s code generation architecture has yielded ~15 % faster overall RegExp performance. More details can be found in the dedicated blog post.

New library features

Several recent additions to the ECMAScript standard library are included in this release. Two String methods, padStart and padEnd, provide helpful string formatting features, while Intl.DateTimeFormat.prototype.formatToParts gives authors the ability to customize their date/time formatting in a locale-aware manner.

WebAssembly enabled

Chrome 57 (which includes V8 5.7) will be the first release to enable WebAssembly by default. For more details, see the getting started documents on webassembly.org and the API documentation on MDN

V8 API additions

Please check out our summary of API changes. This document is regularly updated a few weeks after each major release.
Developers with an active V8 checkout can use 'git checkout -b 5.7 -t branch-heads/5.7' to experiment with the new features in V8 5.7. Alternatively you can subscribe to Chrome's Beta channel and try the new features out yourself soon.

PromiseHook

This C++ API allows users to implement profiling code that traces through the lifecycle of promises. This enables Node’s upcoming AsyncHook API which lets you build async context propagation.

The PromiseHook API provides four lifecycle hooks - init, resolve, before and after -- init hook is run when a new promise is created, the resolve hook is run when a promise is resolved, the pre & post hooks are run right before and after a PromiseReactionJob. For more information please checkout the tracking issue and design document.

Posted by the V8 team

by Michael Hablich (noreply@blogger.com) at February 06, 2017 11:33 AM

Google Chrome Releases

Stable Channel Update for Desktop

The Chrome team is delighted to announce the promotion of Chrome 56 to the stable channel - 56.0.2924.76 for Windows, Mac and Linux. This will roll out over the coming days/weeks.


Chrome 56.0.2924.76 contains a number of fixes and improvements -- a list of changes is available in the log.  Watch out for upcoming Chrome and Chromium blog posts about new features and big efforts delivered in 56.

Security Fixes and Rewards

Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.


This update includes 51 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.


[$8837][671102] High CVE-2017-5007: Universal XSS in Blink. Credit to Mariusz Mlynski
[$8000][673170] High CVE-2017-5006: Universal XSS in Blink. Credit to Mariusz Mlynski
[$8000][668552] High CVE-2017-5008: Universal XSS in Blink. Credit to Mariusz Mlynski
[$7500][663476] High CVE-2017-5010: Universal XSS in Blink. Credit to Mariusz Mlynski
[$3000][662859] High CVE-2017-5011: Unauthorised file access in Devtools. Credit to Khalil Zhani
[$3000][667504] High CVE-2017-5009: Out of bounds memory access in WebRTC. Credit to Sean Stanek and Chip Bradford
[$5500][681843] High CVE-2017-5012: Heap overflow in V8. Credit to Gergely Nagy (Tresorit)
[$2000][677716] Medium CVE-2017-5013: Address spoofing in Omnibox. Credit to Haosheng Wang (@gnehsoah)
[$2000][675332] Medium CVE-2017-5014: Heap overflow in Skia. Credit to sweetchip
[$2000][673971] Medium CVE-2017-5015: Address spoofing in Omnibox. Credit to Armin Razmdjou
[$2000][666714] Medium CVE-2017-5019: Use after free in Renderer. Credit to Wadih Matar
[$1000][673163] Medium CVE-2017-5016: UI spoofing in Blink. Credit to Haosheng Wang (@gnehsoah)
[$500][676975] Medium CVE-2017-5017: Uninitialised memory access in webm video. Credit to Dan Berman
[$500][668665] Medium CVE-2017-5018: Universal XSS in chrome://apps. Credit to Rob Wu
[$TBD][668653] Medium CVE-2017-5020: Universal XSS in chrome://downloads. Credit to Rob Wu
[$N/A][663726] Low CVE-2017-5021: Use after free in Extensions. Credit to Rob Wu
[$N/A][663620] Low CVE-2017-5022: Bypass of Content Security Policy in Blink. Credit to evi1m0#ly.com
[$N/A][651443] Low CVE-2017-5023: Type confusion in metrics. Credit to the UK's National Cyber Security Centre (NCSC)
[$N/A][643951] Low CVE-2017-5024: Heap overflow in FFmpeg. Credit to Paul Mehta
[$N/A][643950] Low CVE-2017-5025: Heap overflow in FFmpeg. Credit to Paul Mehta
[$500][634108] Low CVE-2017-5026: UI spoofing. Credit to Ronni Skansing
[$N/A][661126] Low CVE-2017-5027: Bypass of Content Security Policy in Blink. Credit to 李普君 of 无声信息技术PKAV Team

We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.


As usual, our ongoing internal security work was responsible for a wide range of fixes:
  • [685349] Various fixes from internal audits, fuzzing and other initiatives


Many of our security bugs are detected using AddressSanitizer, MemorySanitizer, Control Flow Integrity, or libFuzzer.

Interested in switching release channels? Find out how.  If you find a new issue, please let us know by filing a bug.  The community help forum is also a great place to reach out for help or learn about common issues.


Richard Bustamante
Google Chrome

by Richard Bustamante (noreply@blogger.com) at February 06, 2017 11:13 AM

February 03, 2017

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 58.0.3000.4/5 for Windows and 58.0.3000.4 for Mac and Linux.


A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 03, 2017 01:09 PM

February 02, 2017

Google Chrome Releases

Beta Channel Update for Chrome OS

The Beta channel has been updated to 56.0.2924.87 (Platform version: 9000.82.0) for all Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements. A list of changes can be found here.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser).

Grace Kihumba
Google Chrome

by Grace Kihumba (noreply@blogger.com) at February 02, 2017 07:13 PM

Chrome Beta for Android Update

Ladies and gentlemen, behold!  Chrome Beta 57 (57.0.2987.19) for Android has been released and will be available in Google Play over the next few hours.  A partial list of the changes in this build is available in the Git log.  Details on new features are available on the Chromium blog, and developers should check out our updates related to the web platform here.

If you find a new issue, please let us know by filing a bug. More information about Chrome for Android is available on the Chrome site.

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at February 02, 2017 05:14 PM

Beta Channel Update for Desktop

The Chrome team is excited to announce the promotion of Chrome 57 to the beta channel for Windows, Mac and Linux. Chrome 57.0.2987.21 contains our usual under-the-hood performance and stability tweaks, but there are also some cool new features to explore - please head to the Chromium blog to learn more!


A full list of changes in this build is available in the log.  Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 02, 2017 12:56 PM

Chromium Blog

Chrome 57 Beta: CSS Grid Layout, Improved Add to Home screen, Media Session API

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



CSS Grid Layout

Sites are increasingly being accessed on screens of all sizes, from large LCD TVs to tiny watch faces. Historically, supporting all of these screen sizes required complex combinations of markup and CSS, making code hard to maintain. To give developers more granular control over how elements grow and shrink to fit the current screen size, CSS Grid Layout is now available.




CSS Grid supports a two-dimensional grid-based layout system, optimized for responsive user interface design. Elements within the grid can be specified to span multiple columns or rows. Elements positioned in a CSS grid can also be named, making layout code easier to understand.
Screenshot 2017-01-25 20.06.19.png
CSS Grid allows developers to arbitrarily place elements on a grid with full control over element flow, sizing behavior and responsiveness.

Improved Add to Home screen

Since early versions of Chrome for Android, users have been able to add sites to their Home screen for fast and convenient access. This feature adds the icons using Android shortcuts, which means that web apps don’t show up throughout Android in the same way as installed native apps.




In this release, when a user adds a Progressive Web App to their Home screen, Chrome will integrate it into Android in a much deeper way. For example, Progressive Web Apps will now appear in the app drawer section of the launcher and in Android Settings, and will be able to receive incoming intents from other apps. Long presses on their notifications will also reveal the normal Android notification management controls rather than the notification management controls for Chrome.

Media Session API

Media consumption is one of the most common uses for the mobile web. In Chrome for Android, developers can customize the lock screen UI and notifications with media content using the new Media Session API. By providing metadata to the browser about the content being played, developers can create rich lock screen messaging that includes information such as title, artist, album name, and artwork. Additionally , the site is now able to respond to user actions taken on the notification itself, such as seeking or skipping.


media-session-tldr-with-cc.png

Other features in this release

  • When a video enters fullscreen on an Android device, Chrome now automatically locks the screen orientation according to the aspect ratio of the video.
  • Sites using continuous setTimeout() will now be throttled when using loops to drive out-of-view frame animations, improving performance for users.
  • The Fetch API Response class now supports the .redirected attribute to help web developers avoid untrustworthy responses and reduce the risk of open redirectors.
  • The new padStart and padEnd formatting tools enable text padding, facilitating tasks like aligning console output or printing numbers with a fixed number of digits.
  • Service Worker Navigation Preload is now available as an Origin Trial, allowing developers to parallelize the network request for the main resource alongside service worker startup.
  • The Payment Request API can be made available inside an iframe by adding the allowpaymentrequest attribute.
  • PaymentMethodData now supports basic-card, so developers can refer to all card types with a single method identifier, rather than individual data types.
  • To simplify the migration from HTTP to HTTPS, stored credentials for HTTP forms are now transferred to the HTTPS version of the site, and the Credential Management API now supports filling credentials from matching subdomains.
  • The caret-color property enables developers to specify the color of the text input cursor.
  • To preserve consistency with other on<event> attributes, ongotpointercapture and onlostpointercapture are now part of the GlobalEventHandlers mixin.
  • Support is now available for text-decoration-skip: ink to make underlines skip descenders, the portion of letters that extend below the text's baseline.
  • New text-decoration properties are now available, allowing developers to specify visual effects such as line color and style.
  • The PresentationRequest constructor has been modified to accept multiple URLs via a sequence<DOMString>, in addition to the existing constructor that takes a single URL.
  • The new AudioContext.getOutputTimestamp() method enables developers to synchronize DOMHighResTimeStamp and AudioContext.currentTime values.
  • AudioBufferSourceNode, OscillatorNode, and ConstantSourceNode now inherit from AudioScheduledSourceNode, consolidating functionality.
  • The new cancelAndHoldAtTime function cancels future AudioParam events with times greater than or equal to cancelTime, allowing developers to preserve the value of the scheduled time in a direct way.
  • Developers can now construct WebAudio-specific events such as OfflineAudioCompletionEvent and AudioProcessEvent.
  • To increase user security, Chrome's XSS Auditor now blocks entire suspicious pages by default, rather than selectively filtering out the suspected reflected XSS on the page.

Deprecations and interoperability improvements

  • The <cursor> element has been removed, but but cursor icons can still be set via the cursor CSS property.
  • A legacy caller has been removed from HTMLEmbedElement and HTMLObjectElement, so the interfaces will now throw exceptions rather than having their instances called as functions.
  • The usemap attribute now requires case-sensitive matching.
  • All -webkit- prefixed IndexedDB global aliases have been removed, after their deprecation in M38.
  • Custom message events and events created by client.postMessage(message, transfer) in a service worker will now use MessageEvent instead of ServiceWorkerMessageEvent, following the HTML MessageEvent spec extension.
  • Support for webkitClearResourceTimings(), webkitSetResourceTimingBufferSize(), and onwebkitresourcetimingbufferfull has been removed from the Performance interface, in favor of clearResourceTimings(), setResourceTimingBufferSize(), and onresourcetimingbufferfull.
  • The following -internal CSS selectors are being deprecated: -internal-media-controls-cast-button, -internal-media-controls-overlay-cast-button, and all of the -internal-media-controls-text-track-list selectors.
  • Support for the obsolete API webkitCancelRequestAnimationFrame has been removed in favor of cancelAnimationFrame.
  • On Android, wordWrap: break-word and -webkit-line-break: after-white-space will no longer be set on contenteditable containers by default, to preserve consistency between browsers.
  • The webkit prefix has been removed from AudioContext and OfflineAudioContext.

Posted by Xi Han, Home Screen Heroine

by Chrome Blog (noreply@blogger.com) at February 02, 2017 12:41 PM

Integrating Progressive Web Apps deeply into Android

In 2015, we added a new feature to Chrome for Android that allows developers to prompt users to add their site to the Home screen for fast and convenient access. That feature uses an Android shortcut, which means that web apps don’t show up throughout Android in the same way as installed native apps. For example, many developers have asked for their web app to show up in the app drawer section of the launcher. These differences can be confusing for users and prevent the experience from feeling as cohesive as it could.



In the next few weeks we’ll be rolling out a new version of this experience in Chrome beta. With this new version, once a user adds a Progressive Web App to their Home screen, Chrome will integrate it into Android in a much deeper way than before. For example, Progressive Web Apps will now appear in the app drawer section of the launcher and in Android Settings, and will be able to receive incoming intents from other apps. Long presses on their notifications will also reveal the normal Android notification management controls rather than the notification management controls for Chrome.




This new Add to Home screen feature is one more step in our journey to empower developers to build the best possible experience for their users, and we are committed to ensuring the same mechanisms for installing Progressive Web Apps are available to all browsers on Android.


Posted by Yaron Friedman, Add to Home screen aficionado

by Chrome Blog (noreply@blogger.com) at February 02, 2017 12:07 PM