Planet Chromium

May 26, 2016

Igalia Chromium

Manuel Rego: CSS Grid Layout and positioned items

As part of the work done by Igalia in the CSS Grid Layout implementation on Chromium/Blink and Safari/WebKit, we’ve been implementing the support for positioned items. Yeah, absolute positioning inside a grid. 😅

Probably the first idea is that come to your mind is that you don’t want to use positioned grid items, but maybe in some use cases it can be needed. The idea of this post is to explain how they work inside a grid container as they have some particularities.

Actually there’s not such a big difference compared to regular grid items. When the grid container is the containing block of the positioned items (e.g. using position: relative; on the grid container) they’re placed almost the same than regular grid items. But, there’re a few differences:

  • Positioned items don't stretch by default.
  • They don't use the implicit grid. They don't create implicit tracks.
  • They don't occupy cells regarding auto-placement feature.
  • autohas a special meaning when referring lines.

Let’s explain with more detail each of these features.

Positioned items shrink to fit

We’re used to regular items that stretch by default to fill their area. However, that’s not the case for positioned items, similar to what a positioned regular block does, they shrink to fit.

This is pretty easy to get, but a simple example will make it crystal clear:

<div style="display: grid; position: relative;
            grid-template-columns: 300px 200px; grid-template-rows: 200px 100px;">
    <div style="grid-column: 1 / 3; grid-row: 1 / 3;"></div>
    <div style="position: absolute; grid-column: 1 / 3; grid-row: 1 / 3;"></div>
</div>

In this example we’ve a simple 2x2 grid. Both the regular item and the positioned one are placed with the same rules taking the whole grid. This defines the area for those items, which takes the 1st & 2nd rows and 1st & 2nd columns.

Positioned items shrink to fit Positioned items shrink to fit

The regular item stretches by default both horizontally and vertically, so it takes the whole size of the grid area. However, the positioned item shrink to fit and adapts its size to the contents.

For the examples in the next points I’m ignoring this difference, as I want to show the area that each positioned item takes. To get the same result than in the pictures, you’d need to set 100% width and height on the positioned items.

Positioned items and implicit grid

Positioned items don’t participate in the layout of the grid, neither they affect how items are placed.

You can place a regular item outside the explicit grid, and the grid will create the required tracks to accommodate the item. However, in the case of positioned items, you cannot even refer to lines in the implicit grid, they'll be treated as auto. Which means that you cannot place a positioned item in the implicit grid. they cannot create implicit tracks as they don't participate in the layout of the grid.

Let’s use an example to understand this better:

<div style="display: grid; position: relative;
            grid-template-columns: 200px 100px; grid-template-rows: 100px 100px;
            grid-auto-columns: 100px; grid-auto-rows: 100px;
            width: 300px; height: 200px;">
    <div style="position: absolute; grid-area: 4 / 4;"></div>
</div>

The example defines a 2x2 grid, but the positioned item is using grid-area: 4 / 4; so it tries to goes to the 4th row and 4th column. However the positioned items cannot create those implicit tracks. So it’s positioned like if it has auto, which in this case will take the whole explicit grid. auto has a special meaning in positioned items, it’ll be properly explained later.

Positioned items do not create implicit tracks Positioned items do not create implicit tracks

Imagine another example where regular items create implicit tracks:

<div style="display: grid; position: relative;
            grid-template-columns: 200px 100px; grid-template-rows: 100px 100px;
            grid-auto-columns: 100px; grid-auto-rows: 100px;
            width: 500px; height: 400px;">
    <div style="grid-area: 1 / 4;"></div>
    <div style="grid-area: 4 / 1;"></div>
    <div style="position: absolute; grid-area: 4 / 4;"></div>
</div>

In this case, the regular items will be creating the implicit tracks, making a 4x4 grid in total. Now the positioned item can be placed on the 4th row and 4th column, even if those columns are on the explicit grid.

Positioned items can be placed on the implicit grid Positioned items can be placed on the implicit grid

As you can see this part of the post has been modified, thanks to @fantasai for notifying me about the mistake.

Positioned items and placement algorithm

Again the positioned items do not affect the position of other items, as they don’t participate in the placement algorithm.

So, if you’ve a positioned item and you’re using auto-placement for some regular items, it’s expected that the positioned one overlaps the other. The positioned items are completely ignored during auto-placement.

Just showing a simple example to show this behavior:

<div style="display: grid; position: relative;
            grid-template-columns: 300px 300px; grid-template-rows: 200px 200px;">
    <div style="grid-column: auto; grid-row: auto;"></div>
    <div style="grid-column: auto; grid-row: auto;"></div>
    <div style="grid-column: auto; grid-row: auto;"></div>
    <div style="position: absolute;
                grid-column: 2 / 3; grid-row: 1 / 2;"></div>
</div>

Here we’ve again a 2x2 grid, with 3 auto-placed regular items, and 1 absolutely positioned item. As you can see the positioned item is placed on the 1st row and 2nd column, but there’s an auto-placed item in that cell too, which is below the positioned one. This shows that the grid container doesn’t care about positioned items and it just ignores them when it has to place regular items.

Positioned items and placement algorithm Positioned items and placement algorithm

If all the children were not positioned, the last one would be placed in the given position (1st row and 2nd column), and the rest of them (auto-placed) will take the other cells, without overlapping.

Positioned items and auto lines

This is probably the biggest difference compared to regular grid items. If you don’t specify a line, it’s considered that you’re using auto, but auto is not resolved as span 1 like in regular items. For positioned items auto is resolved to the padding edge.

The specification introduces the concepts of the lines 0 and -0, despite how weird it can sound, it actually makes sense. The auto lines would be referencing to those 0 and -0 lines, that represent the padding edges of the grid container.

Again let’s use a few examples to explain this:

<div style="display: grid; position: relative;
            grid-template-columns: 300px 200px; grid-template-rows: 200px 200px;
            padding: 50px 100px; width: 500px; height: 400px;">
    <div style="position: absolute;
                grid-column: 1 / auto; grid-row: 2 / auto;"></div>
</div>

Here we have a 2x2 grid container, which has some padding. The positioned item will be placed in the 2nd row and 1st column, but its area will take up to the padding edges (as the end line is auto in both axis).

Positioned items and auto lines Positioned items and auto lines

We could even place positioned grid items on the padding itself. For example using “grid-column: auto / 1;” the item would be on the left padding.

Positioned items using auto lines to be placed on the left padding Positioned items using auto lines to be placed on the left padding

Of course if the grid is wider and we’ve some free space on the content box, the items will take that space too. For example:

<div style="display: grid; position: relative;
            grid-template-columns: 300px 200px; grid-template-rows: 200px 200px;
            padding: 50px 100px; width: 600px; height: 400px;">
    <div style="position: absolute;
                grid-column: 3 / auto; grid-row: 2 / 3;"></div>
</div>

Here the grid columns are 500px, but the grid container has 600px width. This means that we’ve 100px of free space in the grid content box. As you can see in the example, that space will be also used when the positioned items extend up to the padding edges.

Positioned items taking free space and right padding Positioned items taking free space and right padding

Offsets

Of course you can use offsets to place your positioned items (left, right, top and bottom properties).

These offsets will apply inside the grid area defined for the positioned items, following the rules explained above.

Let’s use another example:

<div style="display: grid; position: relative;
            grid-template-columns: 300px 200px; grid-template-rows: 200px 200px;
            padding: 50px 100px; width: 500px; height: 400px;">
    <div style="position: absolute;
                grid-column: 1 / auto; grid-row: 2 / auto;
                left: 90px; right: 70px; top: 80px; bottom: 60px;"></div>
</div>

Again a 2x2 grid container with some padding. The positioned item have some offsets which are applied inside its grid area.

Positioned items and offets Positioned items and offets

Wrap-up

I’m not completely sure about how important is the support of positioned elements for web authors using Grid Layout. You’ll be the ones that have to tell if you really find use cases that need this. I hope this post helps to understand it better and make your minds about real-life scenarios where this might be useful.

The good news is that you can test this already in the most recent versions of some major browsers: Chrome Canary, Safari Technology Preview and Firefox. We hope that the 3 implementations are interoperable, but please let us know if you find any issue.

There’s one last thing missing: alignment support for positioned items. This hasn’t been implemented yet in any of the browsers, but the behavior will be pretty similar to the one you can already use with regular grid items. Hopefully, we’ll have time to add support for this in the coming months.

Igalia and Bloomberg working together to build a better web Igalia and Bloomberg working together to build a better web

Last but least, thanks to Bloomberg for supporting Igalia in the CSS Grid Layout implementation on Blink and WebKit.

May 26, 2016 10:00 PM

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 52.0.2743.0 (Platform version: 8350.1.0, 8350.2.0, 8350.3.0) for all Chrome OS devices except for x86-mario, x86-zgb and expresso . 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 May 26, 2016 05:46 PM

Dev Channel Update

The dev channel has been updated to 52.0.2743.10 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.

Anantha Keesara
Google Chrome

by ananthak (noreply@blogger.com) at May 26, 2016 11:57 AM

May 25, 2016

Google Chrome Releases

Stable Channel Update



The Chrome team is delighted to announce the promotion of Chrome 51 to the stable channel for Windows, Mac and Linux.



Chrome 51.0.2704.63 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 51.


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 42 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chromium security page for more information.


[$7500][590118] High CVE-2016-1672: Cross-origin bypass in extension bindings. Credit to Mariusz Mlynski.
[$7500][597532] High CVE-2016-1673: Cross-origin bypass in Blink. Credit to Mariusz Mlynski.
[$7500][598165] High CVE-2016-1674: Cross-origin bypass in extensions. Credit to Mariusz Mlynski.
[$7500][600182] High CVE-2016-1675: Cross-origin bypass in Blink. Credit to Mariusz Mlynski.
[$7500][604901] High CVE-2016-1676: Cross-origin bypass in extension bindings. Credit to Rob Wu.
[$4000][602970] Medium CVE-2016-1677: Type confusion in V8. Credit to Guang Gong of Qihoo 360.
[$3500][595259] High CVE-2016-1678: Heap overflow in V8. Credit to Christian Holler.
[$3500][606390] High CVE-2016-1679: Heap use-after-free in V8 bindings. Credit to Rob Wu.
[$3000][589848] High CVE-2016-1680: Heap use-after-free in Skia. Credit to Atte Kettunen of OUSPG.
[$3000][613160] High CVE-2016-1681: Heap overflow in PDFium. Credit to Aleksandar Nikolic of Cisco Talos.
[$1000][579801] Medium CVE-2016-1682: CSP bypass for ServiceWorker. Credit to KingstonTime.
[$1000][583156] Medium CVE-2016-1683: Out-of-bounds access in libxslt. Credit to Nicolas Gregoire.
[$1000][583171] Medium CVE-2016-1684: Integer overflow in libxslt. Credit to Nicolas Gregoire.
[$1000][601362] Medium CVE-2016-1685: Out-of-bounds read in PDFium. Credit to Ke Liu of Tencent's Xuanwu LAB.
[$1000][603518] Medium CVE-2016-1686: Out-of-bounds read in PDFium. Credit to Ke Liu of Tencent's Xuanwu LAB.
[$1000][603748] Medium CVE-2016-1687: Information leak in extensions. Credit to Rob Wu.
[$1000][604897] Medium CVE-2016-1688: Out-of-bounds read in V8. Credit to Max Korenko.
[$1000][606185] Medium CVE-2016-1689: Heap buffer overflow in media. Credit to Atte Kettunen of OUSPG.
[$1000][608100] Medium CVE-2016-1690: Heap use-after-free in Autofill. Credit to Rob Wu.
[$500][597926] Low CVE-2016-1691: Heap buffer-overflow in Skia. Credit to Atte Kettunen of OUSPG.
[$500][598077] Low CVE-2016-1692: Limited cross-origin bypass in ServiceWorker. Credit to Til Jasper Ullrich.
[$500][598752] Low CVE-2016-1693: HTTP Download of Software Removal Tool. Credit to Khalil Zhani.
[$500][603682] Low CVE-2016-1694: HPKP pins removed on cache clearance. Credit to Ryan Lester and Bryant Zadegan.


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:
  • [614767] CVE-2016-1695: 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.



Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at May 25, 2016 09:45 PM

Beta Channel Update

The beta channel has been updated to 51.0.2704.63 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 May 25, 2016 01:42 PM

May 24, 2016

Google Chrome Releases

Dev Channel Update

The dev channel has been updated to 52.0.2743.6 for Windows, Linux and Mac.



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.



Di Mu
Google Chrome

by Di Mu (noreply@blogger.com) at May 24, 2016 05:07 PM

May 23, 2016

Igalia Chromium

Igalia Compilers Team: Awaiting the future of JavaScript in V8

On the evening of Monday, May 16th, 2016, we have made history. We’ve landed the initial implementation of “Async Functions” in V8, the JavaScript runtime in use by the Google Chrome and Node.js. We do these things not because they are easy, but because they are hard. Because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one we are willing to accept. It is very exciting to see this, roughly 2 months of implementation, codereview and standards finangling/discussion to land. It is truly an honour.

 

To introduce you to Async Functions, it’s first necessary to understand two things: the status quo of async programming in JavaScript, as well as Generators (previously implemented by fellow Igalian Andy).

 

Async programming in JavaScript has historically been implemented by callbacks. `window.setTimeout(function toExecuteLaterOnceTimeHasPassed() {}, …)` being the common example. Callbacks on their own are not scalable: when numerous nested asynchronous operations are needed, code becomes extremely difficult to read and reason about. Abstraction libraries have been tacked on to improve this, including caolan’s async package, or Promise libraries such as Q. These abstractions simplify control flow management and data flow management, and are a massive improvement over plain Callbacks. But we can do better! For a more detailed look at Promises, have a look at the fantastic MDN article. Some great resources on why and how callbacks can lead to utter non-scalable disaster exist too, check out http://callbackhell.com!

 

The second concept, Generators, allow a runtime to return from a function at an arbitrary line, and later re-enter that function at the following instruction, in order to continue execution. So right away you can imagine where this is going — we can continue execution of the same function, rather than writing a closure to continue execution in a new function. Async Functions rely on this same mechanism (and in fact, on the underlying Generators implementation), to achieve their goal, immensely simplifying non-trivial coordination of asynchronous operations.

 

As a simple example, lets compare the following two approaches:
function deployApplication() {
  return cleanDirectory(__DEPLOYMENT_DIR__).
    then(fetchNpmDependencies).
    then(
      deps => Promise.all(
        deps.map(
          dep => moveToDeploymentSite(
            dep.files,
            `${__DEPLOYMENT_DIR__}/deps/${dep.name}`
        ))).
    then(() => compileSources(__SRC_DIR__,
                              __DEPLOYMENT_DIR__)).
    then(uploadToServer);
}

The Promise boiler plate makes this preit harder to read and follow than it could be. And what happens if an error occurs? Do we want to add catch handlers to each link in the Promise chain? That will only make it even more difficult to follow, with error handling interleaved in difficult to read ways.

Lets refactor this using async functions:

async function deployApplication() {
    await cleanDIrectory(__DEPLOYMENT_DIR__);
    let dependencies = await fetchNpmDependencies();

    // *see below*
    for (let dep of dependencies) {
        await moveToDeploymentSite(
            dep.files,
            `${__DEPLOYMENT_DIR__}/deps/${dep.name}`);
    }

    await compileSources(__SRC_DIR__,
                         __DEPLOYMENT_DIR__);
    return uploadToServer();
}

 

You’ll notice that the “moveToDeploymentSite” step is slightly different in the async function version, in that it completes each operation in a serial pipeline, rather than completing each operation in parallel, and continuing once finished. This is an unfortunate limitation of the async function specification, which will hopefully be improved on in the future.

 

In the meantime, it’s still possible to use the Promise API in async functions, as you can `await` any Promise, and continue execution after it is resolved. This grants compatibility with  numerous existing Web Platform APIs (such as `fetch()`), which is ultimately a good thing! Here’s an alternative implementation of this step, which performs the `moveToDeploymentSite()` bits in parallel, rather than serially:

 


await Promise.all(dependencies.map(
  dep => moveToDeploymentSite(
    dep.files,
    `${__DEPLOYMENT_DIR__}/deps/${dep.name}`
)));

 

Now, it’s clear from the let dependencies = await fetchNpmDependencies(); line that Promises are unwrapped automatically. What happens if the promise is rejected with an error, rather than resolved with a value? With try-catch blocks, we can catch rejected promise errors inside async functions! And if they are not caught, they will automatically return a rejected Promise from the async function.

function throwsError() { throw new Error("oops"); }

async function foo() { throwsError(); }

// will print the Error thrown in `throwsError`.
foo().catch(console.error)

async function bar() {
  try {
    var value = await foo();
  } catch (error) {
    // Rejected Promise is unwrapped automatically, and
    // execution continues here, allowing us to recover
    // from the error! `error` is `new Error("oops!")`
  }
}

 

There are also lots of convenient forms of async function declarations, which hopefully serve lots of interesting use-cases! You can concisely declare methods as asynchronous in Object literals and ES6 classes, by preceding the method name with the `async` keyword (without a preceding line terminator!)

 


class C {
  async doAsyncOperation() {
    // ...
  }
};

var obj = {
  async getFacebookProfileAsynchronously() {
    /* ... */
  }
};

 

These features allow us to write more idiomatic, easier to understand asynchronous control flow in our applications, and future extensions to the ECMAScript specification will enable even more idiomatic forms for writing complex algorithms, in a maintainable and readable fashion. We are very excited about this! There are numerous other resources on the web detailing async functions, their benefits, and perhaps ways they might be improved in the future. Some good ones include [this piece from Google’s Jake Archibald](https://jakearchibald.com/2014/es7-async-functions/), so give that a read for more details. It’s a few years old, but it holds up nicely!

 

So, now that you’ve seen the overview of the feature, you might be wondering how you can try it out, and when it will be available for use. For the next few weeks, it’s still too experimental even for the “Experimental Javascript” flag.  But if you are adventurous, you can try it already!  Fetch the latest Chrome Canary build, and start Chrome with the command-line-flag `–js-flags=”–harmony-async-await”`. We can’t make promises about the shipping timeline, but it could ship as early as Chrome 53 or Chrome 54, which will become stable in September or October.

 

We owe a shout out to Bloomberg, who have provided us with resources to improve the web platform that we love. Hopefully, we are providing their engineers with ways to write more maintainable, more performant, and more beautiful code. We hope to continue this working relationship in the future!

 

As well, shoutouts are owed to the Chromium team, who have assisted in reviewing the feature, verifying its stability, getting devtools integration working, and ultimately getting the code upstream. Terriffic! In addition, the WebKit team has also been very helpful, and hopefully we will see the feature land in JavaScriptCore in the not too distant future.

by compilers at May 23, 2016 02:08 PM

May 20, 2016

Google Chrome Releases

Beta Channel Update for Chrome OS

The Beta channel has been updated to 51.0.2704.55 (Platform version: 8172.39.0) for all Chrome OS devices except the Acer Chromebook R11 and the AOpen Chromebox Commercial. This build contains a number of bug fixes, security updates, and feature enhancements.


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) or by pressing Alt+Shift+I.

Bernie Thompson
Google Chrome

by Bernie Thompson (noreply@blogger.com) at May 20, 2016 02:48 PM

Chromium Blog

The Mobile Web Is Open for Business


Posted by Rahul Roy-chowdhury, VP Product Management, Chrome

One of the virtues of the web is its immense reach, providing access to information for all internet users regardless of device or platform. With the explosion of mobile devices, the web has had to evolve to deliver great experiences on the small screen. This journey began a few years ago, and I am excited to be able to say that the mobile web is open for business. Hear the recording from Google I/O where I discussed the state of the union and how to take advantage of new experiences like AMP and Progressive Web Apps (PWAs) to deliver a best-in-class mobile experience.


If you don’t have time to watch, here’s a quick recap of the four aspects to focus on while building a great mobile web experience:

Accelerate
Expressiveness has always been a strength of the web, but sometimes that expressiveness can come at the cost of loading time or smooth scrolling. For example, event listeners allow developers to create custom scrolling effects for their website, but they can introduce jank when Chrome needs to wait for any touch handler to finish before scrolling a page. With the new passive event listener API, we've given control back to the developer, who can indicate whether they plan to handle the scroll or if Chrome can begin scrolling immediately.


Speed also goes beyond user experience gains. Studies have shown that 40% of users will leave a retail site if it takes longer than 3 seconds to load. To get a blazing fast web page in front of users immediately, we've introduced Accelerated Mobile Pages (AMP). With AMP, we have seen pages load 4x faster and use up to 10x less data. AMP is already seeing great adoption by developers, with more than 640,000 domains serving AMP pages.


Engage
Progressive Web Apps (PWAs) let developers take advantage of new technologies to provide users with an engaging experience from the very first moment. Thanks to a new API called service worker, all the important parts of a web app can be cached so that it loads instantly the next time a user opens it. This caching also allows developers to continue to provide a fast and meaningful experience even when the user is offline or on an unreliable network. PWAs provide elements of polish too: an icon users can add to their home screen, a splash screen when they open it, and a full-screen experience with no address bar.

image 9.gif

JalanTikus Progressive Web App


Convert
Logging in is a ubiquitous pattern on the web, but 92% of users abandon a task if they've forgotten their password. To alleviate this pain, Chrome's password manager enables more than 8-billion sign-ins per month, and we're expanding support with the Credential Management API. Using this API allows web apps to more closely integrate with the password manager and streamline the sign-in process.


Even once logged in, checkout can be a complicated process to complete. That's why we're also investing in capabilities such as the Web Payment API and enhanced autofill, assisting users by accurately filling in forms for them. We've found that forms are completed 25% more when autofill is available, increasing odds for conversion.


Retain
Once the first interaction with a user is complete, re-engaging on the web can be tricky. Push notifications address this challenge on native apps, and now the push API is available on the web as well. This allows developers to reconnect with their users even if the browser isn't running. Over 10 billion push notifications are sent every day in Chrome, and it’s growing quickly. Jumia found that users who enabled push notifications opened those notifications 38% of the time and recovered carts 9x more often than other users.

    
Jumia Mobile Web Push Notifications


Success Stories
As developers begin embracing these new technologies, we're seeing success stories from around the world. AliExpress, one of the world's largest e-commerce sites, built a PWA and saw conversion rates for new users increase by 104%. They've also found that users love the experience, spending 74% more time on their site per session.


Another great example is BaBe, an Indonesian news aggregator service that was app-only until they developed a PWA with feature parity to their native app. Since launching they have found it to perform even faster than their native app, and have seen comparable time spent per session: 3 minutes on average on both their mobile website and their native app.


Even developers who have only begun implementing certain PWA technologies have seen success. United eXtra, a leading retailer in Saudi Arabia, implemented push notifications and saw users who opted-in returned 4x more often. These returning users also spent 100% more than users returning from other channels.


These are just a handful of businesses that have begun reaping the benefits of investing in Progressive Web Apps. Learn more about our how partners are using PWA technologies to enhance their mobile web experience.

Screen Shot 2016-05-17 at 6.06.16 PM.png

Subscribe to our YouTube channel to stay up to date with all the mobile web sessions from Google I/O, which we will continue to upload as they’re ready. Thanks for coming, thanks for watching, and most of all, thank you for developing for the web!




by Chrome Blog (noreply@blogger.com) at May 20, 2016 10:11 AM

May 19, 2016

Google Chrome Blog

The Google Play store, coming to a Chromebook near you

We launched Chromebooks for people who wanted a fast, simple and secure computing experience. Chromebooks just work -- open the lid, and within seconds, you’re on your favorite sites and apps, getting stuff done. Virus protection and automatic updates are built-in, so you don't have to manage your computer. And that’s worked great for our users. Schools in the US are now buying more Chromebooks than all other devices combined -- and in Q1 of this year, Chromebooks topped Macs in overall shipments to become the #2 most popular PC operating system in the US*.

We’ve been encouraged by this growth, but our users have often told us that they would like to do even more with their Chromebooks -- run more apps, use Office files more easily, connect with a variety of apps, and do more when they’re offline.

So, we're bringing Google Play (the most popular app store in the world) to Chromebooks. This means you’ll be able to download and use Android apps, so you can make a Skype call, work with Office files and be productive offline -- or take a break with games like Minecraft, Hearthstone or Clash of Clans. The same apps that run on phones and tablets can now run on Chromebooks without compromising their speed, simplicity or security. This is good for users and great for developers - in addition to phones and tablets, they will be able to easily bring their apps to laptops. And all this is built on top of Chrome OS, so users will continue to have everything they love in their Chromebooks.



Google Play will start rolling out in the developer channel with M53 on the ASUS Chromebook Flip, the Acer Chromebook R 11 and the latest Chromebook Pixel. Over time, this will roll out to other Chromebooks in the market too. And, we've also been working with our partners to launch some great new devices specially designed for Play. Stay tuned for more details to come over the next few months.

We’ll keep a list of supported Chromebooks here, and will share news about new models on the Chrome channel on Google Plus and Twitter.

Chromebooks have always been about making computing more accessible for everyone, and by bringing together the best of Android and Chrome OS, we are taking a big leap forward. Not only are we addressing many of the existing needs and use cases that people have for their Chromebooks, we are also betting on the millions of developers who are innovating every day to build the next great experience that wasn’t even possible on PC platforms before. This is just the beginning, and we’re excited to see what the future holds for everyone!

Posted by Dylan Reid and Elijah Taylor, Chrome OS Software Engineers and Raiders of the Lost Arc.

* Source: IDC's Worldwide Quarterly PC Tracker, May 2016

by Chrome Blog (noreply@blogger.com) at May 19, 2016 11:59 AM

May 18, 2016

Igalia Chromium

Antonio Gomes: [Chromium] content_shell running on Wayland desktop (Weston Compositor)

During my first weeks at Igalia, I got an interesting and promising task of Understand the status of Wayland support in Chromium upstream.

At first I could see clear signs that Wayland is being actively considered by the Chromium community:

  1. Ozone/Wayland project by Intel – which was my starting point as described later on.
  2. The meta bug “upstream wayland backend for ozone (20% project)“, which has some recent activity by the Chromium community.
  3. This comment in the chromium-dev mailing list (by a Googler):
  4. “(..) I ‘d recommend using ToT. Wayland support is a work-in-progress and newer trees will probably be better.”.

    Chromium’s DEPS file has “wayland” as one its core dependency (search for “wayland”).

Next step, naturally, was get my hands dirty, compiling and experimenting with it. I decided to start with content_shell.


Environment:

Ubuntu 16.04 LTS, regular Gnome session (with X) and Weston Wayland compositor running (no ‘xwayland’ installed) to run Wayland apps.

GYP_DEFINES

component=static_library use_ash=1 use_aura=1 chromeos=0 use_ozone=1 ozone_platform_wayland=1 use_wayland_egl=1 ozone_auto_platforms=0 use_xkbcommon=1 clang=0 use_sysroot=0 linux_use_bundled_gold=0

(note: GYP was used for personal familiarity with it, but GN applies fine here).

Chromium version

Base SHA 5da650481 (as of 2016/May/17)

Initial results

As is, content_shell built fine, but hung at runtime upon launch, hitting a CHECK at desktop_factory_ozone.cc(21).

Analysis and Action

After understanding current Ozone/Wayland upstream support, compare designs/code against 01.org, I could start connecting some of the missing dots.

The following files were “ported” from 01.org:

  • ui/views/widget/desktop_aura/desktop_drag_drop_client_wayland.cc / h
  • ui/views/widget/desktop_aura/desktop_screen_ozone_wayland.cc / h
  • ui/views/widget/desktop_aura/desktop_window_tree_host_ozone_wayland.cc / h

And then, I implemented DesktopFactoryOzoneWayland class (ui/views/widget/desktop_factory_ozone_wayland.cc/h) – it inherits from DesktopFactoryOzone, and implements the following pure virtual methods ::CreateWindowTreeHost and ::CreateDesktopScreen.

Initial result

After that, I could build and run content_shell with Weston Wayland Compositor (with no ‘xwayland’ installed). See a quick preview below.

Remarks

As is, the UI process owns the the Wayland connection, and GPU process runs without GL support.

UI processes initializes Ozone by calling:

#0 ui::WaylandSurfaceFactory::WaylandSurfaceFactory
#1 ui::OzonePlatformWayland::InitializeUI
#2 ui::OzonePlatform::InitializeForUI();
#3 aura::Env::Init()
#4 aura::Env::CreateInstance()
#5 content::BrowserMainLoop::InitializeToolkit()
(…)
#X content::ContentMain()
<UI PROCESS LAUNCH>
On the other side, GPU process gets initialized by calling:
#0 ui::WaylandSurfaceFactory::WaylandSurfaceFactory
#1 ui::OzonePlatformWayland::InitializeGPU
#2 ui::OzonePlatform::InitializeForGPU();
#3 gfx::InitializeStaticGLBindings()
#4 gfx::GLSurface::InitializeOneOffImplementation()
#5 gfx::GLSurface::InitializeOneOff()
#6 content::GpuMain()
<GPU PROCESS LAUNCH>

Differently from UI process, the GPU process call does not initialize OzonePlatformWayland::display_ and instead passes ‘nullptr’ to WaylandSurfaceFactory ctor.

Down the road on the GPU processes initialization WaylandSurfaceFactory::LoadEGLGLES2Bindings is called but bails out earlier explicitly because display_ is NIL.
Then, UI process falls back to software rendering (see call to WaylandSurfaceFactory::CreateCanvasForWidget).

Next step

  • So far I have experimented Ozone/Wayland support using “linux” as the target OS. As far as I can tell, most of the Ozone work upstream though has been focusing on “chromeos” builds instead (e.g. ozone/x11).
  • Hence the idea is to clean up the code and agree with Googlers / 01.org (Intel) people about how to best make use of this code.
  • It is being also discussed with some Googlers what the best way to tackle this lack of GL support is. Some real nice stuff are on the pipe here.

 

by agomes at May 18, 2016 08:21 PM

Google Chrome Releases

Dev Channel Update

The dev channel has been updated to 52.0.2739.0 for Windows, Linux and 52.0.2739.2 for Mac.



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.



Di Mu
Google Chrome

by Di Mu (noreply@blogger.com) at May 18, 2016 12:02 PM

Beta Channel Update

The beta channel has been updated to 51.0.2704.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 May 18, 2016 11:56 AM

May 17, 2016

Google Chrome Releases

Beta Channel Update

The beta channel has been updated to 51.0.2704.29 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.



Richard Bustamante and Pamela Laree-Ordonez
Google Chrome

by Richard Bustamante (noreply@blogger.com) at May 17, 2016 04:33 PM

May 16, 2016

Google Chrome Releases

Stable Channel Update for Chrome OS

The Stable channel has been updated to 50.0.2661.103, 50.0.2661.104 (Platform version: 7879.74.0, 7978.76.0) for all Chrome OS devices except Pinky 11.6" Chromebooks and Asus Chromebit. 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:
  • Bluetooth names clearer and consistent
  • Chrome browser updated to use material design


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) or by pressing Alt+Shift+I.


Ketaki Deshpande
Google Chrome

by Ketaki Deshpande (noreply@blogger.com) at May 16, 2016 05:43 PM

May 15, 2016

Chromium Blog

Transitioning from SPDY to HTTP/2

Last year we announced our intent to end support for the experimental protocol SPDY in favor of the standardized version, HTTP/2. HTTP/2 is the next-generation protocol for transferring information on the web, improving upon HTTP/1.1 with more features leading to better performance. Since then we've seen huge adoption of HTTP/2 from both web servers and browsers, with most now supporting HTTP/2. Over 25% of resources in Chrome are currently served over HTTP/2, compared to less than 5% over SPDY. Based on such strong adoption, starting on May 15th — the anniversary of the HTTP/2 RFC — Chrome will no longer support SPDY. Servers that do not support HTTP/2 by that time will serve Chrome requests over HTTP/1.1, providing the exact same features to users without the enhanced performance of HTTP/2.

At the same time, Chrome will stop supporting the TLS protocol extension NPN, which allows servers to negotiate SPDY and HTTP/2 connections with clients. NPN has been superseded by the TLS extension ALPN, published by the IETF in 2014. ALPN is already used 99% of the time to negotiate HTTP/2 with Chrome, and the remaining servers can gain ALPN support by upgrading their SSL library.

We are looking forward to HTTP/2 continuing to gain adoption, bringing us an even faster web.

Update: To better align with Chrome's release cycle, SPDY and NPN support will be removed with the release of Chrome 51.

Posted by Bence Béky, Network Protocol Engineer and HTTP/2 Enthusiast

by Chrome Blog (noreply@blogger.com) at May 15, 2016 06:47 PM

May 13, 2016

Google Chrome Releases

Beta Channel Update

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



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.


Richard Bustamante and Pamela Laree-Ordonez
Google Chrome

by Pamela Laree-Ordonez (noreply@blogger.com) at May 13, 2016 03:53 PM

Beta Channel Update

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



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.


Pamela Laree-Ordonez
Google Chrome

by Pamela Laree-Ordonez (noreply@blogger.com) at May 13, 2016 11:21 AM

Dev Channel Update

The dev channel has been updated to 52.0.2729.3 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 May 13, 2016 10:32 AM

May 12, 2016

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 52.0.2727.0 (Platform version: 8302.0.0) for all Chrome OS devices except for gandof, veyron-jerry and veyron-mighty . 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 May 12, 2016 05:05 PM

Beta Channel Update for Chrome OS

The Beta channel has been updated to 51.0.2704.42 (Platform version: 8172.28.0) for all Chrome OS devices except Acer C740, R11, and 14 Chromebooks and HP Chromebook 11 and 14. This build contains a number of bug fixes, security updates and feature enhancements.

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 horizontal bars in the upper right corner of the browser).

Bernie Thompson 
Google Chrome

by Bernie Thompson (noreply@blogger.com) at May 12, 2016 02:24 PM

Chromium Blog

Chrome 51 Beta: Credential Management API and reducing the overhead of offscreen rendering

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

Credential Management API

Many sites allow their users to sign in to receive personalized content. Today that requires remembering and typing credentials, which lowers account security when users reuse passwords across multiple sites. Modern browsers have credential managers that remember and autofill saved passwords, but these managers cannot account for custom login flows or remember federated identity preferences.


The latest version of Chrome now supports the Credential Management API, allowing sites to interact with the browser’s credential manager to improve the login experience for users. The API enables users to sign in with one tap and lets them automatically sign back in when returning to the site.

Screen Shot 2016-04-28 at 13.56.55.png
Signing in with one tap using the Credential Management API


Reducing the overhead of offscreen rendering
Modern websites commonly embed cross-origin content like videos, social widgets, and ads. Embedding these resources allows sites to offer compelling content experiences, but it also creates a lot of overhead that can jank the page in ways the embedding site can’t control. The latest version of Chrome no longer runs the rendering pipeline or requestAnimationFrame() callbacks for cross-origin frames that are offscreen. This eliminates unnecessary work and reduces power consumption by up to 30% on several popular mobile sites without affecting the user experience.

Additional features in this release

    Other changes

    • The ability to customize the message shown in the onbeforeunload dialog has been removed to protect users from malicious websites and align with other browsers.
    • Chrome on Android now uses the same media pipeline as desktop Chrome, improving  WebAudio support and allowing sites to interact with the playback rate on <audio> and <video> tags.
    • The latest version of Chrome improves web animations interoperability by supporting lists of values and removing dashed-names in keyframes.
    • Chrome now requires a border style to paint border images, improving spec compliance and interoperability.
    • Percentages can now be used for the sizes of flex item children.
    • DHE-based ciphers have been deprecated and will be removed in Chrome 52 in favor of ECDHE ciphers to improve TLS security.

    Posted by Sabine Borsay and Mike West, Authenticator's Apprentices


    by Chrome Blog (noreply@blogger.com) at May 12, 2016 11:54 AM

    Saving data with Google’s PageSpeed Modules

    The web is a rich and diverse ecosystem, but sometimes that diversity comes at a price. Authoring a website that works quickly and correctly for all browsers, devices, and connections can be a time-consuming task. Google’s PageSpeed Modules, launched in 2010, enable web servers to automatically speed up sites as content is served. Two new features are available in the latest stable release of PageSpeed to accommodate the diversity of screen sizes and data connections.


    Screen resolutions are a common difference among devices. Users with high-resolution screens on fast connections will love crisp, detailed images. Sending those same images to users with small screens on  slow connections will unnecessarily delay the page load and waste their potentially expensive bandwidth. The HTML srcset attribute attribute allows developers to specify alternative versions of an image for the browser to use depending on screen size, but they must manually add this to every image on the page, and also encode the images in several sizes. Fortunately, the latest release of PageSpeed Modules can automate this process.  For example, imagine a page containing the following image element:

    <img width="500" height="500" src="Beach.jpg">


    When PageSpeed's responsive_images filter encounters this, it will automatically create resized versions of the images, then rewrite the element as :

    <img width="500" height="500" src="500x500xBeach.jpg..."
       srcset="750x750xBeach.jpg... 1.5x,
               1000x1000xBeach.jpg... 2x,
               1500x1500xBeach.jpg... 3x,
               xBeach.jpg... 3.4x">


    PageSpeed inserts 1.5x, 2x and 3x variants which provides coverage for the most common devices. It also includes the original full-size image and calculates its effective multiple 3.4x, in the above example. The original will be used by high-density displays or when zoomed in.


    For users that want to save as much data as possible, PageSpeed Modules can take this one step further. Chromium-based browsers send the “Save-Data” header when the user has indicated a desire to conserve bandwidth. Supporting this typically requires site developers to re-encode low bandwidth versions of all images and serve these just to the clients that send this header. The latest release of PageSpeed understands the Save-Data header and will automatically compress images more aggressively for these data-sensitive users.

     combined.png
    Mock storefront without PageSpeed (left), and with PageSpeed and the Save-Data header (right).
    Even though there are no apparent visual differences, without PageSpeed the page is 350KB and takes over a minute to load on our simulated 2G connection. With PageSpeed and the Save-Data header the page is 120KB and loads in less than 30 seconds.


    These new features, along with many others to make sites smaller and load faster, are available in the latest release of PageSpeed Modules. Developers interested in trying it out can download the modules from the Google Developers site.



    Posted by Steve Hill, PageSpeed Engineer and Reducer of Bytes

    by Chrome Blog (noreply@blogger.com) at May 12, 2016 11:26 AM

    May 11, 2016

    Google Chrome Releases

    Stable Channel Update

    The stable channel has been updated to 50.0.2661.102 for Windows, Mac, and Linux.


    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 5 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chromium security page for more information.

    [$8000][605766] High CVE-2016-1667: Same origin bypass in DOM. Credit to Mariusz Mlynski.
    [$7500][605910] High CVE-2016-1668: Same origin bypass in Blink V8 bindings. Credit to Mariusz Mlynski.
    [$3000][606115] High CVE-2016-1669: Buffer overflow in V8. Credit to Choongwoo Han.
    [$1337][578882] Medium CVE-2016-1670: Race condition in loader. Credit to anonymous.
    [$500][586657] Medium CVE-2016-1671: Directory traversal using the file scheme on Android. Credit to Jann Horn.

    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.

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


    A 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 May 11, 2016 12:21 PM

    May 10, 2016

    Igalia Chromium

    Sergio Villar: Automatizing the Grid

    My Igalia colleagues and me have extensively reviewed how to create grids and how to position items inside the grid using different CSS properties. So far everything was more or less static. We declare the sizes of our columns/rows or define a set of grid areas and that’s it. Well, actually there is room for automatic stuff,  you can dynamically create new tracks just by adding items to positions outside the explicit grid. Furthermore the grid is able to auto-position items for you if you don’t really care much about the final destination.

    Use Cases

    But imagine the following use case. Let’s assume that you are designing the product catalog of your pretty nice web store. CSS Grid Layout is the obvious choice for such layout. Just set some columns and some rows and that’s mostly it. Thing is that your catalog is likely not static, but automatically generated from a query to some database where you store all that data. You cannot know a priori how many items you’re going to show (users normally can also filter results).

    Grid already supports that use case. You can already define the number of columns (rows) and let the grid create as many rows (columns) as needed. Something like this:

        grid-template-columns: repeat(3, 100px);
        grid-auto-rows: 100px;
        grid-auto-flow: row;

    Picture showing auto row creation

     

    The Multicol Example

    But you need more flexibility. You’re happy with the grid creating new tracks on demand in one axis, but you also want to have as many tracks as possible (depending on the available size) in the other axis. You’ve already designed web sites using CSS Multicol and you want your grid to behave like columns: 100px;

    Note that in the case of multicol the specified column width is an “optimal” size, meaning that it could be enlarged/narrowed to fill the container once the number of columns is calculated.

    So is it possible to tell grid to add as many tracks as needed to fill some available space? It was not but now we have…

    Repeat to fill: auto-fill and auto-fit

    The grid way to implement it is by using the recently added auto repeat syntax. The already known repeat() function accepts as a first argument two new keywords, auto-fill and auto-fit. Both of them will generate as many repetitions as needed to fill the available space with the specified tracks without overflowing. The only difference between them is that, auto-fit will additionally drop any empty track (meaning no items spanning through it) generated by repeat() after positioning grid items.

    The use of these two new keywords has some limitations:

    • Tracks with intrinsic or flexible sizes cannot be combined with auto repetitions
    • There can be just one auto-repeat per axis at the most
    • repeat(auto-fill|fit,) accepts only one track size as second argument (all auto repeat tracks will have the same size)

    Some examples of valid declarations:

    grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)) [last];
    grid-template-rows: 100px repeat(auto-fit, 2em) repeat(10, minmax(15%, 1fr));
    grid-template-columns: repeat(auto-fill, minmax(max-content, 300px));
    

    And some examples of invalid ones:

    grid-template-columns: min-content repeat(auto-fill, 25px) 10px;
    grid-template-rows: repeat(auto-fit, 15px) repeat(auto-fill, minmax(10px, 100px);
    grid-template-columns: repeat(auto-fill, min-content);
    

    The Details

    I mentioned that we cannot mix flexible and/or intrinsic tracks with auto repetitions, so why repeat(auto-fill, minmax(200px, 1fr)) is a valid declaration? Well, according to the grammar, the auto repeat syntax require something called a <fixed-size> track, which is basically a track which has a length (like 10px) or a percentage in either its min or max function. The following are all <fixed-size> tracks:

    15%
    minmax(min-content, 200px)
    minmax(5%, 1fr)
    

    That length/percentage is the one used by the grid to compute the number of repetitions. You should also be aware of how the number of auto repeat tracks is computed. First of all you need a definite size on the axis where you want to use auto-repeat. If that is not the case then the number of repetitions will be 1.

    The nice thing is that the definite size could be either the “normal” size (width: 250px), the max size (max-height: 15em) or even the min size (min-width: 200px). But there is an important difference, if either the size or max-size is definite, then the number of repetitions is the largest possible positive integer that does not cause the grid to overflow its grid container. Otherwise, if the min-size is definite, then the number of repetitions is the smallest possible positive integer that fulfills that minimum requirement.

    For example, the following declaration will generate 4 rows:

    height: 600px;
    grid-template-rows: repeat(auto-fill, 140px);
    

    But this one will generate 5:

    min-height: 600px;
    grid-template-rows: repeat(auto-fill, 140px);
    

    I want to use it now!

    Sure, no problem. I’ve just landed the support for auto-fill in both Blink and WebKit meaning that you’ll be able to test it (unprefixed) really soon in Chrome Canary and Safari Technology Preview (Firefox Nightly builds already support both auto-fill and auto-fit). Many thanks to our friends at Bloomberg for sponsoring this work. Enjoy!

    by svillar at May 10, 2016 07:25 PM

    Google Chrome Releases

    Stable Channel Update for Chrome OS

    The Stable channel has been updated to 50.0.2661.91, 50.0.2661.94 (Platform version: 7879.66.0, 7978.69.0) for all Chrome OS devices except Pinky 11.6" Chromebooks and Asus Chromebit. 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:
    • Bluetooth names clearer and consistent
    • Chrome browser updated to use material design


    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) or by pressing Alt+Shift+I.


    Ketaki Deshpande
    Google Chrome

    by Ketaki Deshpande (noreply@blogger.com) at May 10, 2016 03:54 PM

    May 06, 2016

    Google Chrome Releases

    Beta Channel Update for Chrome OS

    The Beta channel has been updated to 51.0.2704.37 (Platform version: 8172.25.0) for all Chrome OS devices except Pinky 11.6" Chromebooks, Asus Chromebook flip, Chromebit, and C201. This build contains a number of bug fixes, security updates and feature enhancements.

    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 horizontal bars in the upper right corner of the browser).

    Bernie Thompson 
    Google Chrome

    by Bernie Thompson (noreply@blogger.com) at May 06, 2016 11:07 AM