Planet Chromium

March 26, 2015

Google Chrome Releases

Beta Update for Chrome OS

The Beta channel has been updated to 42.0.2311.60 (Platform version: 6812.52.0) for all devices, except the Chromebook Pixel (2015). 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 horizontal bars in the upper right corner of the browser).

Matthew Yuan
Google Chrome

by matthewyuan@chromium.org (noreply@blogger.com) at March 26, 2015 02:18 PM

Chromium Blog

Fewer bugs, mo’ money

[Cross-posted on the Google Online Security Blog]

We work hard to keep you safe online. In Chrome, for instance, we warn users against malware and phishing and offer rewards for finding security bugs. Due in part to our collaboration with the research community, we’ve squashed more than 700 Chrome security bugs and have rewarded more than $1.25 million through our bug reward program. But as Chrome has become more secure, it’s gotten even harder to find and exploit security bugs.

This is a good problem to have! In recognition of the extra effort it takes to uncover vulnerabilities in Chrome, we’re increasing our reward levels. We’re also making some changes to be more transparent with researchers reporting a bug.

First, we’re increasing our usual reward pricing range to $500-$15,000 per bug, up from a previous published maximum of $5,000. This is accompanied with a clear breakdown of likely reward amounts by bug type. As always, we reserve the right to reward above these levels for particularly great reports. (For example, last month we awarded $30,000 for a very impressive report.)

Second, we’ll pay at the higher end of the range when researchers can provide an exploit to demonstrate a specific attack path against our users. Researchers now have an option to submit the vulnerability first and follow up with an exploit later. We believe that this a win-win situation for security and researchers: we get to patch bugs earlier and our contributors get to lay claim to the bugs sooner, lowering the chances of submitting a duplicate report.

Third, Chrome reward recipients will be listed in the Google Hall of Fame, so you’ve got something to print out and hang on the fridge.

As a special treat, we’re going to back-pay valid submissions from July 1, 2014 at the increased reward levels we’re announcing today. Good times.

We’ve also answered some new FAQs on our rules page, including questions about our new Trusted Researcher program and a bit about our philosophy and alternative markets for zero-day bugs.

Happy bug hunting!

Posted by Tim Willis, Hacker Philanthropist, Chrome Security Team

by Google Chrome Blog (noreply@blogger.com) at March 26, 2015 09:17 AM

Gradually Sunsetting SHA-1

The SHA-1 cryptographic hash algorithm has been known to be considerably weaker than it was designed to be since at least 2005 — 9 years ago. Collision attacks against SHA-1 are too affordable for us to consider it safe for the public web PKI. We can only expect that attacks will get cheaper.

That’s why Chrome will start the process of sunsetting SHA-1 (as used in certificate signatures for HTTPS) with Chrome 39 in November. HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.

SHA-1's use on the Internet has been deprecated since 2011, when the CA/Browser Forum, an industry group of leading web browsers and certificate authorities (CAs) working together to establish basic security requirements for SSL certificates, published their Baseline Requirements for SSL. These Requirements recommended that all CAs transition away from SHA-1 as soon as possible, and followed similar events in other industries and sectors, such as NIST deprecating SHA-1 for government use in 2010.

We have seen this type of weakness turn into a practical attack before, with the MD5 hash algorithm. We need to ensure that by the time an attack against SHA-1 is demonstrated publicly, the web has already moved away from it. Unfortunately, this can be quite challenging. For example, when Chrome disabled MD5, a number of enterprises, schools, and small businesses were affected when their proxy software — from leading vendors — continued to use the insecure algorithms, and were left scrambling for updates. Users who used personal firewall software were also affected.

We plan to surface, in the HTTPS security indicator in Chrome, the fact that SHA-1 does not meet its design guarantee. We are taking a measured approach, gradually ratcheting down the security indicator and gradually moving the timetable up (keep in mind that we release stable versions of Chrome about 6 – 8 weeks after their branch point):

Chrome 39 (Branch point 26 September 2014)

Sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

The current visual display for “secure, but with minor errors” is a lock with a yellow triangle, and is used to highlight other deprecated and insecure practices, such as passive mixed content.



Chrome 40 (Branch point 7 November 2014; Stable after holiday season)

Sites with end-entity certificates that expire between 1 June 2016 to 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “neutral, lacking security”.

The current visual display for “neutral, lacking security” is a blank page icon, and is used in other situations, such as HTTP.



Chrome 41 (Branch point in Q1 2015)

Sites with end-entity certificates that expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Subresources from such domain will be treated as “active mixed content”.

The current visual display for “affirmatively insecure” is a lock with a red X, and a red strike-through text treatment in the URL scheme.



Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

Posted by Chris Palmer, Secure Socket Lover and Ryan Sleevi, Transport Layer Securer

by Google Chrome Blog (noreply@blogger.com) at March 26, 2015 09:17 AM

Pwnium V: the never-ending* Pwnium



Tim Willis, Hacker Philanthropist, Chrome Security Team
Around this time each year we announce the rules, details and maximum cash amounts we’re putting up for our Pwnium competition. For the last few years we put a huge pile of cash on the table (last year it was e million) and gave researchers one day during CanSecWest to present their exploits. We’ve received some great entries over the years, but it’s time for something bigger.

Starting today, Pwnium will change its scope significantly, from a single-day competition held once a year at a security conference to a year round, worldwide opportunity for security researchers.

For those who are interested in what this means for the Pwnium rewards pool, we crunched the numbers and the results are in: it now goes all the way up to $∞ million*.

We’re making this change for a few reasons:

  • Removing barriers to entry: At Pwnium competitions, a security researcher would need to have a bug chain in March, pre-register, have a physical presence at the competition location and hopefully get a good timeslot. Under the new scheme, security researchers can submit their bugs year-round through the Chrome Vulnerability Reward Program (VRP) whenever they find them.
  • Removing the incentive for bug hoarding: If a security researcher was to discover a Pwnium-quality bug chain today, it’s highly likely that they would wait until the contest to report it to get a cash reward. This is a bad scenario for all parties. It’s bad for us because the bug doesn’t get fixed immediately and our users are left at risk. It’s bad for them as they run the real risk of a bug collision. By allowing security researchers to submit bugs all year-round, collisions are significantly less likely and security researchers aren’t duplicating their efforts on the same bugs.
  • Our researchers want this: On top of all of these reasons, we asked our handful of participants if they wanted an option to report all year. They did, so we’re delivering.

Logistically, we’ll be adding Pwnium-style bug chains on Chrome OS to the Chrome VRP. This will increase our top reward to $50,000, which will be on offer all year-round. Check out our FAQ for more information.

Happy hunting!

* Our lawyercats wouldn’t let me say “never-ending” or “infinity million” without adding that “this is an experimental and discretionary rewards program and Google may cancel or modify the program at any time.” Check out the reward eligibility requirements on the Chrome VRP page.

by Google Chrome Blog (noreply@blogger.com) at March 26, 2015 09:16 AM

March 25, 2015

Google Chrome Releases

Chrome Beta for Android Update

Chrome Beta for Android has been updated to 42.0.2311.61 and will be available in Google Play over the next few hours.  A partial list of changes in this build is available in the Git log. 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 March 25, 2015 05:29 PM

Beta Channel Update

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

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.

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at March 25, 2015 10:25 AM

March 24, 2015

Google Chrome Releases

Dev Channel Update

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

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.

Daniel Xie
Google Chrome

by Daniel xie (noreply@blogger.com) at March 24, 2015 11:48 AM

Beta Channel Update for Chrome OS

The Beta channel has been updated to 42.0.2311.50 (Platform version: 6812.42.0/44) for all devices, except Pixel, Acer Chromebox CXI, LG Chromebase, Asus Chromebox, Dell Chromebox, HP Chromebox, HP Chromebook 14, Toshiba Chromebook, Acer C720, Dell Chromebook 11 . 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 horizontal bars in the upper right corner of the browser).

Matthew Yuan
Google Chrome

by matthewyuan@chromium.org (noreply@blogger.com) at March 24, 2015 09:33 AM

Stable Channel Update for Chrome OS

The Stable channel has been updated to 41.0.2272.102 (Platform version: 6680.78.0). Systems will be automatically updated over the next few days. This build contains flash update and number of stability fixes.

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).

Dharani Govindan
Google Chrome

by Dharani (noreply@blogger.com) at March 24, 2015 09:33 AM

March 19, 2015

Google Chrome Releases

Stable Channel Update

The stable channel has been updated to 41.0.2272.101 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.


Penny MacNeil
Google Chrome

by Penny MacNeil (noreply@blogger.com) at March 19, 2015 05:03 PM

March 18, 2015

Google Chrome Releases

Beta Channel Update

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

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.

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at March 18, 2015 06:46 PM

Dev Channel Update for Chrome OS

The Dev channel has been updated to 43.0.2334.0 (Platform version: 6885.0.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 horizontal bars in the upper right corner of the browser).

Josafat Garcia
Google Chrome

by Josafat (noreply@blogger.com) at March 18, 2015 05:14 PM

Chromium Blog

New JavaScript techniques for rapid page loads

Posted by Marja Hölttä and Daniel Vogelheim, Resident Loader Coders

Speed has always been one of Chrome's primary missions, ever since it was included as one of the founding principles in 2008. But speed is about more than just traditional Javascript benchmarks. Ideally every part of a user's interaction with a browser is fast, starting with loading web pages. Chrome is introducing two techniques called script streaming and code caching designed to reduce that painful waiting time spent staring at a white screen, especially on mobile devices.

Script streaming optimizes the parsing of JavaScript files. Previous versions of Chrome would download a script in full before beginning to parse it, which is a straightforward approach but doesn't fully utilize the CPU while waiting for the download to complete. Starting in version 41, Chrome parses async and deferred scripts on a separate thread as soon as the download has begun. This means that parsing can complete just milliseconds after the download has finished, and results in pages loading as much as 10% faster. It's particularly effective on large scripts and slow network connections.
streaming.png
Code caching is another new technique that helps speed up page loading, specifically on repeated visits to the same page. Normally, the V8 engine compiles the page’s JavaScript on every visit, turning it into instructions that a processor understands. This compiled code is then discarded once a user navigates away from the page as compiled code is highly dependent on the state and context of the machine at compilation time. Chrome 42 introduces an advanced technique of storing a local copy of the compiled code, so that when the user returns to the page the downloading, parsing, and compiling steps can all be skipped. Across all page loads, this allows Chrome to avoid about 40% of compile time and saves precious battery on mobile devices.

These are two examples of ways Chrome is improving page load time, but page load time is just one way to think about the performance of the browser. Stay tuned for more ways the Chromium project is pushing forward all aspects of performance on the web.

by Google Chrome Blog (noreply@blogger.com) at March 18, 2015 11:03 AM

March 17, 2015

Google Chrome Releases

Dev Channel Update

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

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.

Daniel Xie
Google Chrome

by Daniel xie (noreply@blogger.com) at March 17, 2015 07:29 PM

Beta Channel Update for Chrome OS

The Beta channel has been updated to 42.0.2311.41 (Platform version: 6812.34.0) for all Chrome OS devices except Pixel, Acer Chromebox CXI, LG Chromebase, Asus Chromebox, Dell Chromebox, HP Chromebox, HP Chromebook 14, Toshiba Chromebook, Acer C720, Dell Chromebook 11. 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:
  • The ability to pin your favorite apps to their shelf
  • Files app has implemented Material Design
  • Support for password-protected zip files
  • Updated calculator app

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).


Matthew Yuan
Google Chrome

by matthewyuan@chromium.org (noreply@blogger.com) at March 17, 2015 12:32 PM

March 13, 2015

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 42.0.2311.41 (Platform version: 6812.34.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 horizontal bars in the upper right corner of the browser).

Matthew Yuan
Google Chrome

by matthewyuan@chromium.org (noreply@blogger.com) at March 13, 2015 07:44 PM

March 12, 2015

Chromium Blog

Chrome 42 Beta: Push Notifications, Promoting Add to Home Screen and ES6 Classes


The newest Chrome Beta channel release includes support for ES6 Classes and several new features that allow developers to create more immersive web applications. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux and Chrome OS.

Push Notifications

This release includes two new APIs that together allow sites to push native notifications to their users even after the page is closed—provided the user has granted explicit permission. After the user has granted permission, a developer can use the new Push API to remotely wake up their service worker using Google Cloud Messaging. Once awake, the service worker may run JavaScript for a short period but in this release it is required at minimum to show a user-visible notification. Each notification includes a ‘Site Settings’ button, allowing users to easily disable notifications for a site.


Screen Shot 2015-03-04 at 2.35.05 PM copy.png

Promoting Add to Home Screen

Chrome 32 introduced the ability for Android users to add home screen shortcuts to their favorite websites via a menu item. In this release, users who frequently visit a high-quality web app will see a banner that allows them to add the site to their home screen in one tap.




Sites that wish to take advantage of this new feature must meet eligibility criteria that ensure that users have a good experience when launching sites from the home screen, even when offline. The criteria will evolve over time based on feedback from users and developers, but today they require sites to provide a Web App Manifest, serve all content using HTTPS, and at least partially work offline using a service worker.

ES6 Classes

Developers often find it hard to adapt to JavaScript’s prototype-based inheritance and although many libraries have introduced their own patterns for emulating classes, the language hasn't yet provided a single, uniform way of describing them.


ES6 classes solve this by providing JavaScript a clean, standardized syntax for classes. This new syntax is available in Chrome 42 for JavaScript written in strict mode.
'use strict';


class Polygon {
   constructor(height, width) {
       this.name = 'Polygon';
       this.height = height;
       this.width = width;
   }


   sayName() {
       log('Hi, I am a ', this.name + '.');
   }
}


let p = new Polygon(300, 400);

Other updates in this release

  • DevTools now allows developers to visually edit cubic beziers directly from the styles pane, making it easier to understand and modify animations.
  • The Fetch API is now available in the window context, shared workers, and dedicated workers, providing a new promise-based standard for AJAX requests.
  • The startRendering method of an OfflineAudioContext instance now returns a promise that resolves when the audio has finished rendering, making it easier to design web apps that work with the Web Audio API.
  • AudioBufferSourceNode.buffer can no longer be set more than once, protecting developers from the lack of control over when the new source starts.
  • Chrome OS now supports screen.orientation and fires the DeviceOrientationEvent when the device’s orientation changes significantly, allowing orientation-aware websites to operate correctly on Chrome OS devices.
  • This release includes an updated and unprefixed implementation of Encrypted Media Extensions, which allows media sites to discover and interact with digital rights management systems..
  • A new content setting allows users to automatically pause non-primary plugin content to save power. Developers can turn it on to test how it interacts with their content.

As always, visit chromestatus.com/features for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates.

by Google Chrome Blog (noreply@blogger.com) at March 12, 2015 11:04 AM

March 11, 2015

Google Chrome Releases

Admin Console Update

The Admin console has been updated with a new Network section under Device Management.
  • The new interface allows admins to define and push networks to Mobile, Chrome, and Chromebox for Meetings devices through a unified interface. 
  • The Device Management page displays the number of devices associated with each platform. Click on these icons to navigate to the device list. Settings for each enabled service are located on the left.
  • Only platforms that support the network configuration will be available in the option "Restrict access to this Wi-Fi network by platform".

Known issues are available here. Enterprise customers can report an issue by contacting support.

Lawrence Lui
Google Chrome

by Lawrence L (noreply@blogger.com) at March 11, 2015 04:31 PM

Google Chrome Blog

For What’s Next: the new Chromebook Pixel and USB Type-C

Today we’re introducing an updated, more powerful Chromebook Pixel. While the new Pixel has many improvements, one feature that is especially exciting is universal charging, data, and display in the form of USB Type-C. We joined forces with the USB Implementers Forum and leaders across the industry to create the new standard over the past few years, and are now starting to see its debut in devices.


The case for a new connector

Mobile devices charge from a USB port, which has worked pretty well, even though USB wasn’t designed for that purpose. Micro-USB can deliver up to 10 Watts, which charges small mobile devices reasonably quickly. However, as phones get bigger and batteries charge faster, there’s a distinct need for something that can supply more power than micro-USB.

Laptops, on the other hand, have no common charge standard. Each one tends to have its own proprietary connector and power supply to deliver just the right combination of voltage and current to charge that laptop at its most efficient point. Laptops also need a lot more than 10 Watts of power.

More power and speed

USB Type-C combines these varying needs in a durable, high power, high data-rate connector powerful enough for laptops yet small enough for mobile phones. It also does so in a symmetrical design to eliminate the guesswork when plugging in.

USB Type-C can deliver up to 100W of power, which is more than even the largest laptops typically need. When a USB Type-C enabled device is plugged in, the charger negotiates the right power for that device.  That way, phones, laptops and tablets can all be powered from the same charger.

Not only does Type-C enable universal charging, but it also allows high-speed data and high resolution display. Type-C was designed to transfer data at speeds up to 20Gbs. Since current USB devices max out at 5Gbs, there’s room to grow.

From the same port, Type-C also enables high resolution display output to a monitor or TV through DisplayPort and HDMI accessories.

New possibilities

USB Type-C on the new Pixel means that one day soon you’ll be able to charge your phone, laptop, and tablet all from the same power charger.

There’s a Type-C port on both sides of the Pixel, so you can output display and charge at the same time. It also means you can charge from either side of your laptop, something that’s really convenient on a crowded desk.

Forgot your power adapter? Plug in the optional Type-C to USB A cable, and top up from any traditional USB port, your phone charger, or a USB power bank. It won’t charge as fast as the included 60W supply, but it’s handy in a pinch.  For the truly adventurous, you could even charge your Pixel from another Pixel!**

As more devices use Type-C, you can imagine a world where chargers become ubiquitous to the point where device makers won’t need to ship them with a new phone or laptop. We’ve even open sourced our work on Type-C adapters so that you’ll have more choice of accessories. That’s good for your wallet and the environment.

We’re really excited about the new Chromebook Pixel and USB Type-C. To learn more, head over to the Google Store, the new home for the latest devices made with Google, or the Pixel site.

Posted by Adam Rodriguez, Product Manager at Google

*Battery life tested using Chromium standard PowerLoadTest at default brightness. The PowerLoadTest was created to emulate average user behavior and measure the resultant battery life. Charge time testing is measured by battery capacity increase with lid closed divided by average energy usage during PowerLoadtest. Battery life and charge time may vary depending on usage and other conditions.
**Pixel to Pixel charging is possible, but it won’t charge all that fast. You could theoretically connect your Pixel to itself, but we recommend against experimenting with perpetual energy machines.

by Google Chrome Blog (noreply@blogger.com) at March 11, 2015 12:01 PM

Google Chrome Releases

Android WebView Update

The Chrome and Android teams are super excited to announce that WebView has been updated to M40. Android WebView 40.0.0.0 will be available in Google Play over the next few days for devices on Android 5.0 and higher.

This release brings new JavaScript APIs like Service Workers, and Battery Status as well as bug fixes and performance improvements.

If you find an issue let us know by filing a bug or join the WebView G+ Community from where you will also be able to access future Beta releases.

Miguel Garcia Arribas
Google Chrome and WebView Teams

by Jason Kersey (noreply@blogger.com) at March 11, 2015 11:49 AM

Beta Channel Update

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

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.

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at March 11, 2015 10:14 AM

Chrome Beta for Android Update

The Chrome Team is delighted to announce the release of Chrome 42 Beta for Android. Chrome 42.0.2311.38 will be available in Google Play over the next few hours. New features in this release include:
  • Get the latest updates from sites with notifications.
  • Adding your favorite sites to your homescreen is now even easier.
  • Bug fixes and speedy performance improvements.
A partial list of other changes in this build are available in the Git log. 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.

Jason Kersey
Google Chrome

by Jason Kersey (noreply@blogger.com) at March 11, 2015 09:50 AM

Chrome for Android Update

The Chrome Team is exhilarated to announce the release of Chrome 41 for Android. Chrome 41.0.2272.92 will be available in Google Play over the next few days. This release contains the ability to pull to reload at the top of most pages, along with a number of bug fixes and performance improvements! A partial list of changes in this build are available in the Git log. 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.

Jason Kersey
Google Chrome

by Jason Kersey (noreply@blogger.com) at March 11, 2015 09:49 AM

Dev Channel Update for Chrome OS

The Dev channel has been updated to 42.0.2311.38 (Platform version: 6812.29.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 horizontal bars in the upper right corner of the browser).

Matthew Yuan
Google Chrome

by matthewyuan@chromium.org (noreply@blogger.com) at March 11, 2015 09:26 AM

March 10, 2015

Google Chrome Releases

Dev Channel Update

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

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.

Daniel Xie
Google Chrome

by Daniel xie (noreply@blogger.com) at March 10, 2015 03:27 PM

Stable Channel Update for Chrome OS

The Stable channel has been updated to 41.0.2272.89 (Platform version: 6680.64.0). Systems will be automatically updated over the next few days. This build contains number of stability fixes.

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).

Dharani Govindan
Google Chrome

by Dharani (noreply@blogger.com) at March 10, 2015 12:47 PM

Stable Channel Update

The stable channel has been updated to 41.0.2272.89 for Windows, Mac and Linux. A full 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.


Penny MacNeil
Google Chrome

by Penny MacNeil (noreply@blogger.com) at March 10, 2015 12:32 PM

March 09, 2015

Igalia Chromium

Javier Fernández: Content Distribution in CSS Grid Layout

It’s been a while since Igalia and Bloomberg started to implement the Box Alignment specification for the CSS Grid Layout model. Some weeks ago we accomplished an important milestone of our roadmap landing in Blink trunk the last patches implementing the Content Distribution properties: align-content and justify-content.

Quoting the CSS Box Alignment document, the content distribution properties are defined as follows:

Aligns the contents of the box as a whole along the box’s inline/row/main axis.
The alignment container is the grid container’s content box. The alignment subjects are the grid tracks.

The CSS syntax of these recently added properties gives an idea of how powerful and flexible they are for grid layout definitions, allowing every possible alignment values combination:

auto | <baseline-position> | <content-distribution> || [ <overflow-position>? && <content-position> ]

It’s worth mentioning that Baseline Alignment is still not implemented, as well as the <content-distribution> values for Distribution Alignment. However, in the latter case I’ve got already a quite promising draft implementation which, eventually, has been very useful to activate a discussion inside the W3C community to allow these alignment values for grid. In previous versions of the specification it was stated that all <content-distribution> values should use their <content-position> fallback values for grid containers. I’m glad that such decision was finally made, because I think that <content-distribution> values are really useful for defining fancier grid layouts. I’ll talk about this soon in a new post, as I consider it deserves a detailed description with the proper examples.

Last, but not least, as it happens with Self Alignment it allows using overflow keywords to define how we want to handle grid’s content overflow. It works in the same way for Content Distribution as we’ll see later with some examples.

Aligning the grid

When there is available space in the grid container block, it’s always useful to have a way to control how we want to use such space and how we want our grid to behave on it. It might happen that container’s size changes (fullscreen mode) or we could have to deal with a content sized grid modifying its content’s size. There are quite many possibilities, so I’ll leave this issue for user/designer’s imagination and I’ll focus on very simple examples to illustrate the concept.

For now, let’s consider this case to understand what you can do with the different <content-alignment> values in a grid layout.

.grid {
    grid: 50px 50px / 100px 100px;
    position: relative;
    width: 200px;
    height: 300px;
}
.fixedSize {
    width: 20px;
    height: 40px;
}
<div class="grid">
   <div class="fixedSize" style="grid-column: 1; grid-row: 1; background: violet;"></div>
   <div style="grid-column: 1; grid-row: 2; background: yellow;"></div>
   <div style="grid-column: 2; grid-row: 1; background: green;"></div>
   <div class="fixedSize" style="grid-column: 2; grid-row: 2; background: red;"></div>
</div>

We are defining a 2×2 grid with 50×100 pixels cells where we are going to place 4 items, one in each cell. Notice that items at (1,1) and (2,2) have a fixed size of 20×40 pixels, while the other 2 are auto-sized so they will be stretched to fill their corresponding grid cell (if you don’t know why, a reading of previous post might help). Also, bear in mind that both align-content and justify-content properties have start as the initial value for grids.

ContentAlignment

Controlling the grid overflow

When grid content’s size exceeds its container dimensions there is the risk of data loss. Some examples of this scenario are center or end alignment from the viewport’s edges; all the content overflowing the viewport’s area can’t be reached, hence we lose such data. In order to prevent this issue Box Alignment specification defines the safe overflow mode, which basically forces a start alignment value for the property handling the dimension where the overflow is detected.

Using the same CSS and HTML code in the example above, we can easily define cases where this data loss issue (red colored arrows) is clearly noticeable just modifying the height or width to cause top or left overflow respectively.

Content-Alignment-Overflow1

There are other situations where Content Alignment and Overflow interact in a different way, using margins, padding or/and borders and even combining different writing-modes and flow directions. The effect of the alignment values varies considerably depending on those factors but I think you have now a clear idea of how to use these new properties in a grid layout.

Current status and next steps

With the grid support for the align-content and justify-content CSS properties in Blink we’ve got most of the Box Alignment specification covered. As it was commented before, just Base Alignment is still pending to be implemented in Chromium browsers. I have to admit that there are also some bugs and wrong behavior using certain CSS combinations, specially regarding orthogonal flows, but we are working on it right now and I hope to integrate the patches soon in trunk.

For the time being, let’s consider the following table as the current implementation status of the Box Alignment specification for the Grid Layout model in WebKit (Safari/Epiphany) and Blink (Chrome/Chromium/Opera) based browsers:

align-grid-support-1

The lack of progress in the implementation of the Box Alignment specification in the WebKit web engine is disappointing. I’ve been stuck for quite a lot of time trying to upgrade the CSS properties to the last version of the spec, mainly due design and performance issues. I’ll discuss with the WebKit hackers the best approach to solve this issue so I can put the Grid Layout implementation at the same level than in Blink web engine.

Igalia and Bloomberg will continue working on the implementation of the CSS Grid Layout specification and among my short/mid term challenges are completing the Box Alignment support. These goals include the following tasks:

  • Fixing bugs and completing the orthogonal flows support.
  • Implementing the Base Alignment features
  • Completing the Content Distribution Alignment with the <content-distribution> values
  • Implementing the Box Alignment spec in WebKit
Igalia & Bloomberg logos

Igalia and Bloomberg working to build a better web platform

by jfernandez at March 09, 2015 01:58 PM

Google Chrome Releases

Beta Channel Update

The Chrome engineering team is excited to announce the promotion of Chrome 42 to the beta channel for Windows, Mac and Linux. Chrome 42.0.2311.22 contains many improvements including:


A full list of changes in this build is available in the log.  Find out more at the Chrome and Chromium blogs.  Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at March 09, 2015 11:36 AM