Planet Chromium

September 17, 2014

Google Chrome Releases

Beta Channel Update

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

A full list of changes is available in the Git log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.


Matthew Yuan
Google Chrome

by matthewyuan@chromium.org (noreply@blogger.com) at September 17, 2014 02:49 PM

Google Chrome Blog

Now casting: WATCH Disney Channel, Twitch, iHeart Radio and DramaFever for Chromecast

Chromecast has a little something for everyone in the family to enjoy, and today we’re adding even more options for kids, music lovers and gamers.

For kids of all ages, we're introducing the WATCH Disney, WATCH Disney Junior and WATCH Disney XD apps. So now you'll be able to watch Girl Meets World, Doc McStuffins, and Star Wars Rebels on demand from the Disney Android and iOS apps. (To watch live stream of the network or recent episodes, you’ll need to sign in with a participating TV provider account.)

Music aficionados can now cast and blast music from the best speakers in the house with iHeartRadio. The app lets you listen to more than 1,500 live radio stations from all over the U.S. or customize your own.

You can also join 60 million gamers on Twitch to watch and talk about video games. Get insights from both casual gamers and some of the biggest professional players competing in sold out stadiums. Cast Twitch content from the web, Android and iOS apps.

If international dramas are your favorite, look no further than DramaFever to find more than 15,000 TV episodes. Finally, in case you missed it, last month we also added WATCH ABC and NPR One to the Chromecast family. So make sure to update your apps and check out the latest on chromecast.com/apps.

Posted by Jennifer Wasson, Chromecast partnerships

by Google Chrome Blog (noreply@blogger.com) at September 17, 2014 01:56 PM

September 16, 2014

Google Chrome Releases

Stable Channel Update for Chrome OS

The Stable channel has been updated to 37.0.2062.120 (Platform version:  5978.98.0) for all Chrome OS devices except Acer C7 Chromebook, Samsung Chromebook Series 5, HP Pavilion Chromebook, Asus Chromebox and Samsung Chromebox. This build contains an update for Adobe Flash as well as a number of bug fixes and security updates. Systems will be receiving updates over the next several days. Here is a list of Chromium changes. 

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 September 16, 2014 04:20 PM

Dev Channel Update

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

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at September 16, 2014 12:09 PM

September 12, 2014

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 39.0.2151.4 (Platform version: 6253.0.0) for all Chrome OS devices except the C-48 and the Samsung Chromebook 2 (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).

Ben Henry
Google Chrome

by Ben Henry (noreply@blogger.com) at September 12, 2014 11:08 AM

Beta Channel Update for Chrome OS

The Beta channel has been updated to 38.0.2125.58 (Platform version: 6158.27.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).

Dharani Govindan
Google Chrome

by Dharani (noreply@blogger.com) at September 12, 2014 09:37 AM

September 11, 2014

Google Chrome Blog

First set of Android apps coming to a Chromebook near you

Chromebooks were designed to keep up with you on the go—they’re thin and light, have long battery lives, resume instantly, and are easy to use. Today, we're making Chromebooks even more mobile by bringing the first set of Android apps to Chrome OS:
  • Duolingo - a fun and free way to learn a new language before your next trip
  • Evernote - write, collect and find what matters to you, with a full-size keyboard and touchscreen
  • Sight Words - a delightful way for you to help improve your child's reading skills
  • Vine - create short, beautiful, looping videos in a simple and fun way 
These first apps are the result of a project called the App Runtime for Chrome (Beta), which we announced earlier this summer at Google I/O. Over the coming months, we’ll be working with a select group of Android developers to add more of your favorite apps so you’ll have a more seamless experience across your Android phone and Chromebook.

In the meantime, please tell us which of your favorite Android apps you’d like to see on your Chromebook.

Posted by Ken Mixter, Software Engineer & Josh Woodward, Product Manager (Android Dreamers)

by Google Chrome Blog (noreply@blogger.com) at September 11, 2014 11:00 AM

September 10, 2014

Google Chrome Releases

Beta Channel Update

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

With this release Chrome Mac is 32-bit and will continue to be 32-bit when Chrome 38 goes to stable. With the release of Chrome 39, we will be moving Mac to 64-bit and will no longer support 32-bit NPAPI plugins.

A full list of changes is available in the Git log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.


Matthew Yuan
Google Chrome

by matthewyuan@chromium.org (noreply@blogger.com) at September 10, 2014 08:46 PM

Chrome Beta for Android

The Chrome Team is excited to announce the beta release of Chrome 38 for Android. Chrome 38.0.2125.57 will be available in Google Play over the next few hours. This release contains a number of new features including:
  • Support for Battery Status and Screen orientation APIs
  • Additional Material Design updates
  • Lots 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 September 10, 2014 05:55 PM

Dev Channel Update

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

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at September 10, 2014 02:33 PM

September 09, 2014

Google Chrome Releases

Admin Console Update

The Admin console has been updated with the following changes to user and device settings:

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 September 09, 2014 02:51 PM

Stable Channel Update

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

This release contains an update for Adobe Flash as well as a number of other fixes.  A full list of changes is available in the log.

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

[$2000][401362] High CVE-2014-3178: Use-after-free in rendering. Credit to miaubiz.

As usual, our ongoing internal security work responsible for a wide range of fixes:
[411014] CVE-2014-3179: Various fixes from internal audits, fuzzing and other initiatives.

Many of the above bugs were detected using AddressSanitizer.

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 September 09, 2014 11:53 AM

Beta Channel Update for Chrome OS

The Beta channel has been updated to 38.0.2125.49 (Platform version: 6158.21.0) for all Chrome OS devices except Lenovo ThinkPad 11e Chromebook, Education Chromebook, HP Chromebook 14, HP Pavilion Chromebook, Toshiba Chromebook,  Acer C7 Chromebook,  and Samsung Chromebook Series 5 550. 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).

Dharani Govindan
Google Chrome

by Dharani (noreply@blogger.com) at September 09, 2014 11:33 AM

Chromium Blog

Responsive Web Design with DevTools' Device Mode

We all develop websites on our desktop and laptop machines, so we tend to initially develop for the desktop experience. But that's increasingly out of sync with our users who, more and more, consume the web on mobile. To deliver a great experience for the web, we need to accurately experience it on mobile. Chrome DevTools has had mobile emulation features for awhile, but it's still too disconnected from real device conditions and requires too much trial and error. Chrome 38 Beta includes a new Device Mode that puts you one click away from emulating mobile devices, inspecting media queries, and emulating flaky network conditions.



Now, you can turn on Device Mode right next to the "inspect element" icon. Once enabled, it automatically emulates a mobile viewport, along with complete emulation of touch events. You can test various viewport sizes easily with the large drag handles instead of resizing the whole browser window. You can select from popular device presets to automatically set viewport, touch, user agent and screen density settings in one fell swoop.

2014-09-06 20_47_44.gif

Every media query gets represented visually, so you can correlate your breakpoints with the viewport. Clicking one resizes the viewport, making it easier to iterate on your associated styles. If you want to edit the media queries themselves, right-click and jump to the line of CSS where it's defined.

Lastly, device emulation needs to accurately represent the connectivity of your mobile users. For example, a 3G connection significantly limits the experience of your website compared to your speedy office WiFi. The DevTools can now help you emulate the network conditions (both throughput and latency) of connectivity like EDGE, 3G, 4G – and even go offline.
 
Screen Shot 2014-08-22 at 3.44.13 PM.png
While typical system-wide network conditioning throttles everything, DevTools will only throttle the current tab. This enables you to take your app offline and try out AppCache and Service Worker scenarios, and meanwhile browse documentation in another tab.

Please try out Device Mode your development workflow and let us know what you think. And if you're hungry for more DevTools goodness, check out my Google I/O 2014 talk: Developing Across Devices.

Posted by Paul Bakaus, Developer Advocate and Device Diviner

by Google Chrome Blog (noreply@blogger.com) at September 09, 2014 12:06 AM

September 08, 2014

Igalia Chromium

Javier Fernández: Box Alignment and Grid Layout

As some of my readers already know, Igalia and Bloomberg are collaborating in the implementation of the Grid Layout specification for the Blink/Chromium and WebKit web engines. As part of this assignment, I had the opportunity to review and contirbute to the implementaiton of another feature I consider quite useful for the web: CSS Box Alignment Module (level 3).

The Box Alignment specification was designed to generalize the behavior of boxes alignment within their containers, which is nowadays defined across multiple specifications. Several layout models are affected by this new specification: block, table, flex and grid. This post is about how it affects to the Grid Layout implementation.

I think is a good idea to begin my exposition with a brief introduction of some concepts related to alignment and CSS Writing Modes, which I consider quite relevant to understand the implications of this specification for the Grid Layout implementation and, more important, to realize about its potential.

Examples are mandatory when analyzing W3C specifications; personally, I can’t see all the angles and implications of a feature described in a specification without the proper examples, both visual and source code.

Finally, I’d like to conclude my article with a development angle describing some interesting implementation details and technical challenges I faced while working on both Blink and WebKit web engines. Also, which perhaps is more interesting, the ones I couldn’t solve yet and I’m still working on. As always comments and feedback are really welcome.

Introduction to Box Alignment and Writing-Modes

From the CSS Box Alignment specification:

features of CSS relating to the alignment of boxes within their containers in the various CSS box layout models: block layout, table layout, flex layout, and grid layout.

From the CSS Writing Modes specification:

CSS features to support for various international writing modes, such as left-to-right (e.g. Latin or Indic), right-to-left (e.g. Hebrew or Arabic), bidirectional (e.g. mixed Latin and Arabic) and vertical (e.g. Asian scripts).

In order to get a better understanding of alignment some abstract dimensional and directional terms should be explained and taken into account. I’m going to briefly describe some of them, the ones I consider more relevant for my exposition; a more detailed definition can be obtained from the Abstract Box Terminology section of the specification.

There are three sets of directional terms in CSS:

  • physical – Interpreted relative to the page, independent of writing mode. The physical directions are left, right, top, and bottom
  • flow-relative -  Interpreted relative to the flow of content. The flow-relative directions are start and end, or block-start, block-end, inline-start, and inline-end if the dimension is also ambiguous.
  • line-relative – Interpreted relative to the orientation of the line box. The line-relative directions are line-left, line-right, line-over, and line-under.

The abstract dimensions are defined below:

  • block dimension – The dimension perpendicular to the flow of text within a line, i.e. the vertical dimension in horizontal writing modes, and the horizontal dimension in vertical writing modes.
  • inline dimension – The dimension parallel to the flow of text within a line, i.e. the horizontal dimension in horizontal writing modes, and the vertical dimension in vertical writing modes.
  • block axis – The axis in the block dimension, i.e. the vertical axis in horizontal writing modes and the horizontal axis in vertical writing modes.
  • inline axis - The axis in the inline dimension, i.e. the horizontal axis in horizontal writing modes and the vertical axis in vertical writing modes.
  • extent or logical height - A measurement in the block dimension: refers to the physical height (vertical dimension) in horizontal writing modes, and to the physical width (horizontal dimension) in vertical writing modes.
  • measure or logical width - A measurement in the inline dimension: refers to the physical width (horizontal dimension) in horizontal writing modes, and to the physical height (vertical dimension) in vertical writing modes. (The term measure derives from its use in typography.)

Then, there are flow-relative and line-relative directions. For the time being, I’ll consider only flow-relative directions terms since they are more relevant for discussing alignment issues.

  • block-start - The side that comes earlier in the block progression, as determined by the writing-mode property: the physical top in horizontal-tb mode, the right in vertical-rl, and the left in vertical-lr.
  • block-end - The side opposite block-start.
  • inline-start - The side from which text of the inline base direction would start. For boxes with a used direction value of ltr, this means the line-left side. For boxes with a used direction value of rtl, this means the line-right side.
  • inline-end - The side opposite start.

writing-modes

So now that we have defined the box edges and flow direction concepts we can review how they are used when defining the alignment

properties and values inside a Grid Layout, which can be defined along two axes:

  • which dimension they apply to (inline vs. stacking)
  • whether they control the position of the box within its parent, or the box’s content within itself.

alignment-properties

Regarding the alignment values, there are two concepts that are important to understand:

  • alignment subject - The alignment subject is the thing or things being aligned by the property. For justify-self and align-self, the alignment subject is the margin box of the box the property is set on. For justify-content and align-content, the alignment subject is defined by the layout mode.
  • alignment container - The alignment container is the rectangle that the alignment subject is aligned within. This is defined by the layout mode, but is usually the alignment subject’s containing block.

Also, there are several kind of alignment behaviors:

  • Positional Alignment - specify a position for an alignment subject with respect to its alignment container.
  • Baseline Alignment - form of positional alignment that aligns multiple alignment subjects within a shared alignment context (such as cells within a row or column) by matching up their alignment baselines.
  • Distributed Alignment - used by justify-content and align-content to distribute the items in the alignment subject evenly between the start and end edges of the alignment container.
  • Overflow Alignment - when the alignment subject is larger than the alignment container, it will overflow. To help combat this problem, an overflow alignment mode can be explicitly specified.

At the time of this writing, only Positional Alignment is implemented so I’ll focus on those values in the rest of the article. I’m still working on implementing the specification, though, so there will be time to talk about the other values in future posts.

  • center - Centers the alignment subject within its alignment container.
  • start - Aligns the alignment subject to be flush with the alignment container’s start edge.
  • end - Aligns the alignment subject to be flush with the alignment container’s end edge.
  • self-start - Aligns the alignment subject to be flush with the edge of the alignment container corresponding to the alignment subject’s start side. If the writing modes of the alignment subject and the alignment container are orthogonal, this value computes to start.
  • self-end - Aligns the alignment subject to be flush with the edge of the alignment container corresponding to the alignment subject’s end side. If the writing modes of the alignment subject and the alignment container are orthogonal, this value computes to end.
  • left - Aligns the alignment subject to be flush with the alignment container’s line-left edge. If the property’s axis is not parallel with the inline axis, this value computes to start.
  • right - Aligns the alignment subject to be flush with the alignment container’s line-right edge. If the property’s axis is not parallel with the inline axis, this value computes to start.

So, after this introduction and with all these concepts in mind, it’s now time to get hands on the Grid Layout implementation of the Box Alignment specification. As it was commented before, I’ll try to use as many examples as possible.

Aligning items inside a Grid Layout

Before entering in details with source code and examples, I’d like to summarize most of the concepts described below with some pretty simple diagrams:

2×2 Grid Layout (LTR)

grid-alignment-ltr

2×2 Grid Layout (RTL)

grid-alignment-rtl

The diagram below illustrates how items are placed inside the grid using different writing modes:

grid-writing-modes

At this point, some real examples would help to understand how the CSS alignment properties work on Grid Layout and why they are so important to get all the potential behind this new layout model.

Let’s consider this basic stylesheet which will be used in the examples from now on:

<style>
  .grid {
      grid-auto-columns: 100px;
      grid-auto-rows: 200px;
      width: -webkit-fit-content;
      margin-bottom: 20px;
  }
   .item {
      width: 20px;
      height: 40px;
  }
   .content {
      width: 10px;
      height: 20px;
      background: white;
  }
   .verticalRL {
      -webkit-writing-mode: vertical-rl;
  }
   .verticalLR {
      -webkit-writing-mode: vertical-lr;
  }
   .horizontalBT {
      -webkit-writing-mode: horizontal-bt;
  }
   .directionRTL {
      direction: rtl;
  }
</style>

The item style will be used for the grid items, while the content will be the style of the elements to be placed inside each grid item. There are as well writing-mode related styles, which will be useful later to experiment with different flow and text directions.

In the first example we will center all the cells content so we can have a fully aligned grid, which is particularly interesting for many web applications.

<div class="grid" style="align-items: center; 
                         justify-items: center">
  <div class="cell row1-column1">
    <div class="item"></div>
  </div>
  <div class="cell row1-column2">
    <div class="item"></div>
  </div>
  <div class="cell row2-column1">
    <div class="item"></div>
  </div>
  <div class="cell row2-column2">
    <div class="item"></div>
  </div>
</div>
grid-alignment-example1

In the next example we will illustrate how to use all the Positional Alignment values so we can place nine items in the same grid cell.

 
<div class="grid">
  <div class="cell row1-column1"
     style="align-self: start; justify-self: start;">
    <div class="item"></div>
  </div>
  <div class="cell row1-column1"
     style="align-self: center; justify-self: start;">
    <div class="item"></div>
  </div>
  <div class="cell row1-column1"
     style="align-self: end; justify-self: start;">
    <div class="item"></div>
  </div>
  <div class="cell row1-column1"
     style="align-self: start; justify-self: center;">
    <div class="item"></div>
  </div>
  <div class="cell row1-column1"
     style="align-self: center; justify-self: center;">
    <div class="item"></div>
  </div>
  <div class="cell row1-column1"
     style="align-self: end; justify-self: center;">
    <div class="item"></div>
  </div>
  <div class="cell row1-column1"
     style="align-self: start; justify-self: end;">
    <div class="item"></div>
  </div>
  <div class="cell row1-column1"
     style="align-self: center; justify-self: end;">
    <div class="item"></div>
  </div>
  <div class="cell row1-column1"
     style="align-self: end; justify-self: end;">
    <div class="item"></div>
  </div>
</div>
grid-alignment-example2

Let’s start playing with inline and block-flow direction and see how it affects to the different Positional Alignment values. I’ll start with the inline direction, which affects only to the justify-xxx set of CSS properties.

<div class="grid" style="align-items: self-start; justify-items: self-start">
  <div class="cell row1-column1">
    <div class="item"></div>
  </div>
  <div class="cell row1-column2">
    <div class="item"></div>
  </div>
  <div class="cell row2-column1">
    <div class="item"></div>
  </div>
  <div class="cell row2-column2">
    <div class="item"></div>
  </div>
</div>
Direction LTR Direction RTL
grid-alignment-example3 grid-alignment-example4

The writing-mode CSS Property applies to the block-flow direction, hence it’s the align-xxx properties the ones affected. In this case, orthogonal writing-modes can be specified in the HTML source code; however, these use cases are not yet fully supported by the current implementation of Grid Layout.

<div class="grid"
      style="align-items: self-start; 
             justify-items: self-start">
  <div class="cell row1-column1">
    <div class="item"></div>
  </div>
  <div class="cell row1-column2">
    <div class="item"></div>
  </div>
  <div class="cell row2-column1">
    <div class="item"></div>
  </div>
  <div class="cell row2-column2">
    <div class="item"></div>
  </div>
</div>
grid-alignment-example3
Vertical LR Vertical RL
grid-alignment-example5 grid-alignment-example6

Technical challenges, accomplished and to be faced

Implementing the Box Alignment specification has been a long task and there is still quite much work ahead for both, WebKit and Blink/Chromium web engines. Perhaps one of the most tedious issue was the definition of a couple of new CSS properties: justify-self and justify-items, which required to touch several Core components, from the CSS parser, the style builder and resolver and finally the rendering.

Another important technical challenge comes from the fact that the Box Alignment properties already present in both web engines were implemented as part of the Flexible Box specification. As it was commented before in this post, the Box Alignment specification aims to generalize the alignment behavior for several layout models, hence these properties were not tied to the Flexible Box implementation anymore; this lead to many technical issue, as I’ll explain later.

The patch implemented for issue 333423005 is a good example of the files to touch and logic to be added in order to implement a new CSS property in Blink/Chromium. There is a similar work to be done in the WebKit web engine; at the time of this writing the similarities are still big, even though some parts changed considerably, like the CSS parsing and style builder logic. As an example, the patch implemented in bug 134419

The following code is quite descriptive of the nature of the CSS Box Alignment properties and how they are applied during the style cascade:

void StyleAdjuster::adjustStyleForAlignment(RenderStyle& style, const RenderStyle& parentStyle)
{
    bool isFlexOrGrid = style.isDisplayFlexibleOrGridBox();
    bool absolutePositioned = style.position() == AbsolutePosition;
 
    // If the inherited value of justify-items includes the legacy keyword, 'auto'
    // computes to the the inherited value.
    // Otherwise, auto computes to:
    //  - 'stretch' for flex containers and grid containers.
    //  - 'start' for everything else.
    if (style.justifyItems() == ItemPositionAuto) {
        if (parentStyle.justifyItemsPositionType() == LegacyPosition) {
            style.setJustifyItems(parentStyle.justifyItems());
            style.setJustifyItemsPositionType(parentStyle.justifyItemsPositionType());
        } else {
            style.setJustifyItems(isFlexOrGrid ? ItemPositionStretch : ItemPositionStart);
        }
    }
 
    // The 'auto' keyword computes to 'stretch' on absolutely-positioned elements,
    // and to the computed value of justify-items on the parent (minus
    // any 'legacy' keywords) on all other boxes (to be resolved during the layout).
    if ((style.justifySelf() == ItemPositionAuto) && absolutePositioned)
        style.setJustifySelf(ItemPositionStretch);
 
    // The 'auto' keyword computes to:
    //  - 'stretch' for flex containers and grid containers,
    //  - 'start' for everything else.
    if (style.alignItems() == ItemPositionAuto)
        style.setAlignItems(isFlexOrGrid ? ItemPositionStretch : ItemPositionStart);
 
    // The 'auto' keyword computes to 'stretch' on absolutely-positioned elements,
    // and to the computed value of align-items on the parent (minus
    // any 'legacy' keywords) on all other boxes (to be resolved during the layout).
    if ((style.alignSelf() == ItemPositionAuto) && absolutePositioned)
        style.setAlignSelf(ItemPositionStretch);
}

The WebKit web engine implements the same logic in the StyleResolver class; the StyleAdjuster class is just a helper class defined in the blink/Chromium engine to assist the StyleReslolver logic during the style cascade in order to make some final adjustmetns.

The issue 297483005 implements the align-self CSS property support in Grid Layout; the follwong code extrated from that patch is a good example of how alingment interacts with the grid tracks.

LayoutUnit RenderGrid::rowPositionForChild(const RenderBox* child) const
{
    bool hasOrthogonalWritingMode = child->isHorizontalWritingMode() != isHorizontalWritingMode();
    ItemPosition alignSelf = resolveAlignment(style(), child->style());
 
    switch (alignSelf) {
    case ItemPositionSelfStart:
        // If orthogonal writing-modes, this computes to 'Start'.
        // FIXME: grid track sizing and positioning does not support orthogonal modes yet.
        if (hasOrthogonalWritingMode)
            return startOfRowForChild(child);
 
        // self-start is based on the child's block axis direction. That's why we need to check against the grid container's block flow.
        if (child->style()->writingMode() != style()->writingMode())
            return endOfRowForChild(child);
 
        return startOfRowForChild(child);
    case ItemPositionSelfEnd:
        // If orthogonal writing-modes, this computes to 'End'.
        // FIXME: grid track sizing and positioning does not support orthogonal modes yet.
        if (hasOrthogonalWritingMode)
            return endOfRowForChild(child);
 
        // self-end is based on the child's block axis direction. That's why we need to check against the grid container's block flow.
        if (child->style()->writingMode() != style()->writingMode())
            return startOfRowForChild(child);
 
        return endOfRowForChild(child);
 
    case ItemPositionLeft:
        // orthogonal modes make property and inline axes to be parallel, but in any case
        // this is always equivalent to 'Start'.
        //
        // self-align's axis is never parallel to the inline axis, except in orthogonal
        // writing-mode, so this is equivalent to 'Start’.
        return startOfRowForChild(child);
 
    case ItemPositionRight:
        // orthogonal modes make property and inline axes to be parallel.
        // FIXME: grid track sizing and positioning does not support orthogonal modes yet.
        if (hasOrthogonalWritingMode)
            return endOfRowForChild(child);
 
        // self-align's axis is never parallel to the inline axis, except in orthogonal
        // writing-mode, so this is equivalent to 'Start'.
        return startOfRowForChild(child);
 
    case ItemPositionCenter:
        return centeredRowPositionForChild(child);
        // Only used in flex layout, for other layout, it's equivalent to 'Start'.
    case ItemPositionFlexStart:
    case ItemPositionStart:
        return startOfRowForChild(child);
        // Only used in flex layout, for other layout, it's equivalent to 'End'.
    case ItemPositionFlexEnd:
    case ItemPositionEnd:
        return endOfRowForChild(child);
    case ItemPositionStretch:
        // FIXME: Implement the Stretch value. For now, we always start align the child.
        return startOfRowForChild(child);
    case ItemPositionBaseline:
    case ItemPositionLastBaseline:
        // FIXME: Implement the ItemPositionBaseline value. For now, we always start align the child.
        return startOfRowForChild(child);
    case ItemPositionAuto:
        break;
    }
 
    ASSERT_NOT_REACHED();
    return 0;
}

The resolveAlignment function call deserves an special mention, since it will lead to the open issues I’m still working on. The Box Alignment specification states that the auto values must be resolved to either stretch or start depending on the kind of element. This is theoretically performed during the style cascade, so it wouldn’t be necessary to resolve it at the rendering stage. The code is pretty simple :

static ItemPosition resolveAlignment(const RenderStyle* parentStyle, const RenderStyle* childStyle)
{
    ItemPosition align = childStyle->alignSelf();
    // The auto keyword computes to the parent's align-items computed value, or to "stretch", if not set or "auto".
    if (align == ItemPositionAuto)
        align = (parentStyle->alignItems() == ItemPositionAuto) ? ItemPositionStretch : parentStyle->alignItems();
    return align;
}

The RenderFlexibleBox implementation has to define a similar logic and what is more important, the default value of all the Box Alignment properties have been changed to auto, instead of stretch as it’s stated in the Flexbible Box specification.

To make things even more complicated, many HTML elements are being rendered by RenderFlexibleBox objects as an implementation decision, without the proper display value set to indicate such assumption. This causes many issues and layout tests failures, since the resolved value for auto depends on the kind of element, which is defined by its display property value. Additionally, there are also problems with the anonymous render objects added to the tree on certain implementations.

Both WebKit and Blink/Chromium are affected by these issues; Mathml is a good example for the WebKit engine, since most if its render objects are implemented using a RenderFlexibleBox; also, it assigns and manipulates the align-{self, items} properties during the layout. The RenderFullScreen object is a source of problems for the Blink/Chromium web engine on this regard; it uses a RenderFleixibleBox because of its stretch default behavior, which is not the case anymore according to the Box Alignment specification.

I’m still working on theses issues in both web engines, so this issue is trying to face part of the problems on Blink/Chromium. There are a similar bug in the WebKit engine with similar challenges.

Another pending issue present in both web engines is the lack of support for different writing-modes. Eventhouth the Grid Layout logic is prepared to support them, it’s still buggy and for certain combinations it does not produce the expected outcome.

I’d like to finish this post pointing out that anybody can follow the progress of the Box Alignment spec implementation for Grid Layout you can track these bugs on either of the web engine you are more interested on:

  • Blink/Chromium
    • bug 249451: [CSS Grid Layout] Implement row-axis Alignment
    • bug 376823: [CSS Grid Layout] Implement column-axis Alignment
  • WebKit
    • bug 133224 – [meta] [CSS Grid Layout] Implement column-axis Alignment
    • bug 133222 – [meta] [CSS Grid Layout] Implement row-axis Alignment

This work wouldn’t be possible without the support of Bloomberg and Igalia, who are comitted to provide a better web platform for developers.

Igalia & Bloomberg logos

Igalia and Bloomberg working to build a better web platform

by jfernandez at September 08, 2014 01:48 PM

Eduardo Lima Mitev: Drawing Web content with OpenGL (ES 3.0) instanced rendering

This is a follow up article about my ongoing research on Web content rendering using aggressive batching and merging of draw operations, together with OpenGL (ES 3.0) instanced rendering.

In a previous post, I discussed how relying on the Web engine’s layer tree to figure out non-overlapping content (layers) of a Web page, would (theoretically) allow an OpenGL based rasterizer to ignore the order of the drawing operations. This would allow the rasterizer to group together drawing of similar geometry and submit them efficiently to the GPU using instanced rendering.

I also presented some basic examples and comparisons of this technique with Skia, a popular 2D rasterizer, giving some hints on how much we can accelerate rendering if the overhead of the OpenGL API calls is reduced by using the instanced rendering technique.

However, this idea remained to be validated for real cases and in real hardware, specially because of the complexity and pressure imposed on shader programs, which now become responsible for de-referencing the attributes of each batched geometry and render them correctly.

Also, there are potential API changes in the rasterizer that could make this technique impractical to implement in any existing Web engine without significant changes in the rendering process.

To try keep this article short and focused, today I want to talk only about my latest experiments rendering some fairly complex Web elements using this technique; and leave the discussion about performance to future entries.

Everything is a rectangle

As mentioned in my previous article, almost everything in a Web page can be rendered with a rectangle primitive.

Web pages are mostly character glyphs, which today’s rasterizers normally draw by texture mapping a pre-rendered image of the glyph onto a rectangular area. Then you have boxes, images, shadows, lines, etc; which can all be drawn with a rectangle with the correct layout, transformation and/or texturing.

Primitives that are not rectangles are mostly seen in the element’s border specification, where you have borders with radius, and different styles: double, dotted, grooved, etc. There is a rich set of primitives coming from the combination of features in the borders spec alone.

There is also the Canvas 2D and SVG APIs, which are created specifically for arbitrary 2D content. The technique I’m discussing here purposely ignores these APIs and focuses on accelerating the rest.

In practice, however, these non-rectangular geometries account for just a tiny fraction of the typical rendering of a Web page, which allows me to effectively call them “exceptions”.

The approach I’m currently following assumes everything in a Web page is a rectangle, and all non-rectangular geometry is treated as exceptions and handled differently on shader code.

This means I no longer need to ignore the ordering problem since I always batch a rectangle for every single draw operation, and then render all rectangles in order. This introduces a dramatic change compared to the previous approach I discussed. Now I can (partially) implement this technique without changing the API of existing rasterizers. I say “partially” because to take full advantage of the performance gain, some API changes would be desired.

Drawing non-rectangular geometry using rectangles

So, how do we deal with these exceptions? Remember that we want to draw only with rectangles so that no operation could ever break our batch, if we want to take full advantage of the instanced rendering acceleration.

There are 3 ways of rendering non-rectangular geometry using rectangles:

  • 1. Using a geometry shader:

    This is the most elegant solution, and looks like it was designed for this case. But since it isn’t yet widely deployed, I will not make much emphasis on it here. But we need to follow its evolution closely.

  • 2. Degenerating rectangles:

    This is basically to turn a rectangle into a triangle by degenerating one of its vertices. Then, with a set of degenerated rectangles one could draw any arbitrary geometry as we do today with triangles.

  • 3. Drawing geometry in the fragment shader:

    This sounds like a bad idea, and it is definitely a bad idea! However, given the small and limited amount of cases that we need to consider, it can be feasible.

I’m currently experimenting with 3). You might ask why?, it looks like the worse option. The reason is that going for 2), degenerating rectangles, seems overkill at this point, lacking a deeper understanding of exactly what non-rectangle geometry we will ever need. Implementing a generic rectangle degeneration just for a few tiny set of cases would have been initially a bad choice and a waste of time.

So I decided to explore first the option of drawing these exceptions in the fragment shader and see how far I could go in terms of shader code complexity and performance (un)loss.

Next, I will show some examples of simple Web features rendered this way.

Experiments

The setup:

While my previous screen-casts were ran in my working laptop with a powerful Haswell GPU, one of my goals then was to focus on mobile devices. Hence, I started developing on an Arndale board I happen to have around. Details of the exact setup is out of the scope now, but I will just mention that the board is running a Linaro distribution with the official Mali T604 drivers by ARM.

My Arndale board

Following is a video I ensambled to show the different examples running on the Arndale board (and my laptop at the same time). This time I had to record using an external camera instead of screen-casting to avoid interference with the performance, so please bear with my camera-on-hand video recording skills.



This video file is also available on Vimeo.

I won’t talk about performance now, since I plan to cover that in future deliveries. Enough to be said that the performance is pretty good, comparable to my laptop in most of the examples. Also, there are a lot of simple known optimizations that I have not done because I’m focusing on validating the method first.

One important thing to note is that when drawing is done in a fragment shader, you cannot benefit from multi-sampling anti-aliasing (MSAA), since sampling occurs at an earlier stage. Hence, you have to implement anti-aliasing your self. In this case, I implemented a simple distance-to-edge linear anti-aliasing, and to my surprise, the end result is much better than the MSAA with 8 samples I was trying on my Haswell laptop before, and it is also faster.

On a related note, I have found out that MSAA does not give me much when rendering character glyphs (the majority of content) since they come already anti-aliased by FreeType2. And MSAA will slow down the rendering of the entire scene for every single frame.

I continue to dump the code from this research into a personal repository on GitHub. Go take a look if you are interested in the prototyping of these experiments.

Conclusions and next steps

There is one important conclusion coming out from these experiments: The fact that the rasterizer is stateless makes it very inefficient to modify a single element in a scene.

By stateless I mean they do not keep semantic information about the elements being drawn. For example, lets say I draw a rectangle in one frame, and in the next frame I want to draw the same rectangle somewhere else on the canvas. I already have a batch with all the elements of the scene happily stored in a vertex buffer object on GPU memory, and the rectangle in question is there somewhere. If I could keep the offset where that rectangle is in the batch, I could modify its attributes without having to drop and re-submit the entire buffer.

The solution: Moving to a scene graph. Web engines already implement a scene graph but at a higher level. Here I’m talking about a scene graph in the rasterizer itself, where nodes keep the offset of their attributes in the batch (layout, transformation, color, etc); and when you modify any of these attributes, only the deltas are uploaded to the GPU, rather than the whole batch.

I believe a scene graph approach has the potential to open a whole new set of opportunities for acceleration, specially for transitions and animations, and scrolling.

And that’s exciting!

Apart from this, I also want to:

  • Benchmark! set up a platform for reliable benchmarking and perf comparison with Skia/Cairo.
  • Take a subset of this technique and test it in Skia, behind current API.
  • Validate the case of drawing drop shadows and multi-step gradient backgrounds.
  • Test in other different OpenGL ES 3.0 implementations (and more devices!).

Let us not forget the fight we are fighting: Web applications must be as fast as native. I truly think we can do it.

by elima at September 08, 2014 01:16 PM

Chromium Blog

Chrome 38 Beta: New primitives for the next-generation web

Today’s Chrome Beta channel release includes a ton of new primitives and APIs to simplify development and give developers more control over their web applications. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

New HTML element: <picture>

This release adds support for the new <picture> element thanks to the hard work of community contributor Yoav Weiss, who was able to dedicate his time to implementing this feature in multiple rendering engines because of a successful crowdfunding campaign that raised 50% more than its funding goal.

The <picture> element takes the concept of responsive design, previously solved by sending duplicate resources to the client, and bakes an elegant solution right into the web platform. It allows developers to list multiple versions of images that may be appropriate for the browser to display based on screen size, pixel density, or other factors.

<picture>
    <source media="(min-width: 45em)" srcset="large.jpg">
    <source media="(min-width: 32em)" srcset="med.jpg">
    <img src="small.jpg" alt="The president giving an award.">
</picture>


New JavaScript features

Chrome 38 also enables by default several new JavaScript language features from the draft ECMAScript 6 (ES6) specification. Additions include:
  • Maps and sets, two highly-requested data structures which make storing and interacting with data simpler and more rational.
  • Iterators now provide an easy and extensible way to iterate over sequenced data types such as arrays and strings, as well as the new maps and sets.
  • Symbols, which help prevent object properties from unintentionally interfering with each other.
  • Math functions such as Math.sign and Math.log10, which prevents developers from having to re-implement these functions and provides the performance boost of built-in functions. Take a look at the full list of new functions.
Future releases of Chrome will contain even more ES6 features as the specification matures. Stay posted!

Other updates in this release
  • The Network Information ("NetInfo") API is now enabled, giving web applications access to the current type of network on a device running Android, iOS, or Chrome OS. This could allow an app to only do data-intensive activities such as syncing when connected to a Wi-Fi connection.
  • The addition of the Screen Orientation API allows developers to not only detect whether a device is in portrait or landscape mode, but also lock the screen orientation while a user is within that app.
  • The CSS value "image-rendering: pixelated" is now supported, which allows scaled images to appear to be composed of very large pixels. Example use cases include high-performance display of zoomed photos in image editing software without large bandwidth or load time costs.
  • The Encoding API enables the encoding and decoding of data from binary streams, such as converting between a raw ArrayBuffer and a string.
  • The new File interface allows developers to create and interact with File objects in the same way as Blob objects.
  • SVG fonts are no longer supported, except on Windows systems older than Windows 7. Note that while the feature works on those systems, it is considered deprecated.
As always, visit chromestatus.com/features for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates!

Posted by Andreas Rossberg, Senior Symbolic Software Engineer

by Google Chrome Blog (noreply@blogger.com) at September 08, 2014 12:25 PM

Chrome 37 Beta: DirectWrite on Windows and the <dialog> element

Today’s Chrome Beta channel release includes a slew of new developer features to help you make richer, faster and more compelling web content and apps, especially for mobile devices. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

DirectWrite on Windows

Chrome 37 adds support for DirectWrite, an API on Windows for clear, high-quality text rendering even on high DPI displays. Before DirectWrite, Chrome used the Graphics Device Interface (GDI) to render text. GDI dates back to the mid-80's and reflects the engineering tradeoffs of that time, particularly for slower, lower-resolution machines. The switch to DirectWrite has been a top user request for years, and required extensive re-architecting and streamlining of Chrome's font rendering engine.

Some users should begin seeing better-looking fonts and increased rendering performance as we roll out DirectWrite, with no changes required by web developers. Assuming everything goes smoothly, all users will experience the improvements by the Chrome 37 stable release.

Compare the below screenshots, taken with and without DirectWrite enabled.



New HTML element: <dialog>

In this release we're also adding support for the <dialog> HTML5 element, which enables developers to create styled dialog boxes in their web applications and control them via a JavaScript API. For more details, check out some code samples and see <dialog> in action. The <dialog> element is a better-designed alternative to showModalDialog(), which is now disabled as we recently announced.

Other updates in this release

  • The Web Cryptography JavaScript API is enabled by default starting in Chrome 37, allowing developers to perform cryptographic operations such as hashing, signature generation/verification, and encryption.
  • Subpixel font scaling is now supported, which enables smooth animations of text between font sizes.  
  • TouchEvent co-ordinates are now doubles instead of longs, enabling higher-fidelity touch interactions on high-DPI displays.
  • CSS cursor values "zoom-in" and "zoom-out" are now unprefixed.
  • The number of cores on a physical machine can now be accessed by navigator.hardwareConcurrency.
  • The user's preferred languages are now accessible by navigator.languages, and the languagechange event is fired when this is updated.
  • The CSS Shapes Module allows developers to define non-rectangular text wrapping boundaries around floated elements.
  • NPAPI deprecation continues according to our previously-announced plan with a harder-to-bypass blocking UI
  • The default monospace font on Windows is now Consolas instead of Courier New.
  • Cross-origin fonts are now blocked unless the response includes the appropriate CORS headers.
As always, visit chromestatus.com/features for a complete overview of Chrome’s developer features,  and circle +Google Chrome Developers for more frequent updates!

Posted by Emil A Eklund, Software Engineer and Senior Blog DirectWriter



by Google Chrome Blog (noreply@blogger.com) at September 08, 2014 12:23 PM

September 05, 2014

Chromium Blog

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.

yellow-triangle.png

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.

Screen Shot 2014-09-05 at 12.05.52 PM.png

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.

Screen Shot 2014-08-29 at 1.26.59 PM.png

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 September 05, 2014 02:08 PM

September 04, 2014

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 39.0.2144.0 (Platform version: 6228.0.0) for all Chrome OS devices except the Toshiba Chromebook and HP Chromebox. 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).

Ben Henry
Google Chrome

by Ben Henry (noreply@blogger.com) at September 04, 2014 07:20 PM

Dev Channel Update

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

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at September 04, 2014 02:30 PM

September 03, 2014

Google Chrome Releases

Admin Console Update

The Admin console has been updated with the following changes to user and device settings, which require version 37 or above:
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 September 03, 2014 03:43 PM

Chrome for Android Update

The Chrome Team is excited to announce the stable release of Chrome 37 for Android. Chrome 37.0.2062.117 will be available in Google Play over the next few days. This release contains a number of new features including:
  • Signing in to Chrome signs you in to your favorite Google sites.
  • Updated look and feel with elements of Material Design.
  • Lots of bug fixes and performance improvements!
A partial list of changes in this build is available in the Git history. 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 September 03, 2014 03:14 PM

Stable Channel Update for Chrome OS

The Stable channel has been updated to 37.0.2062.119 (Platform version:  5978.80.0/5978.81.0) for all Chrome OS devices except Acer C7 Chromebook, Samsung Chromebook Series 5 and HP Pavilion Chromebook  . This build contains a number of bug fixes, security updates and feature enhancements. Systems will be receiving updates over the next several days. Here is a list of Chromium changes. 

Some highlights of these changes are:

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.


Below, we highlight fixes that were either contributed by external researchers or particularly interesting. Please see the Chromium security page for more information.


  • [$30000][386988] Critical CVE-2014-3176, CVE-2014-3177: A special reward to lokihardt@asrt for a combination of bugs in V8, IPC, sync, and extensions that can lead to remote code execution outside of the sandbox.
  • [$1500][367567] Medium CVE-2014-3172: Issue related to extension debugging. Credit to Eli Grey.

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 September 03, 2014 01:55 PM

Beta Channel Update

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

A full list of changes is available in the Git log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.


Matthew Yuan
Google Chrome

by matthewyuan@chromium.org (noreply@blogger.com) at September 03, 2014 01:36 PM

Beta Channel Update

The Chrome Team is delighted to announce the promotion of Chrome 38 to the beta channel with 38.0.2125.24 for Windows, Mac and Linux.

This release contains many stability and developer improvements including:
  • New experimental user switching design which makes changing profiles and into incognito mode simpler.
  • A new experimental Guest mode.
  • Experimental UI for Chrome supervised users.
  • Lots of under the hood changes for stability and performance.

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


Matthew Yuan
Google Chrome

by matthewyuan@chromium.org (noreply@blogger.com) at September 03, 2014 11:52 AM

Chromium Blog

Moving Towards a Single Cloud Messaging API

In April we released chrome.gcm, an API that allows Chrome apps and extensions to use the Google Cloud Messaging (GCM) service to interact with their server-side components via push messaging. Since the new API offers significant improvements and has been used for push messaging in Chrome apps and extensions since May 2014, we are now deprecating the legacy chrome.pushMessaging API.

Developers will start to see a deprecation message in the console if they use chrome.pushMessaging, and no new Chrome apps and extensions will be accepted to the Chrome Web Store if they use the deprecated API. Beginning in mid-January 2015, Chrome apps and extensions that continue to use chrome.pushMessaging will be delisted in the Chrome Web Store. When upgraded to use chrome.gcm, these apps will once again be discoverable via searching and browsing the Web Store. In early March, the chrome.pushMessaging API will be removed and all Chrome apps and extensions that continue to reference it will be automatically disabled. They can be enabled once again when upgraded to use chrome.gcm.

For a high level overview of how an app or extension can leverage chrome.gcm, check out our Google I/O Bytes video. Learn how to upgrade your Chrome apps and extensions by consulting the chrome.gcm API documentation and following this tutorial. Lastly, subscribe to the GCM for Chrome Feedback group to ask questions, get help, and learn more about the transition.

Posted by Jake Leichtling and Filip Gorski, Product Manager and Software Engineer

by Google Chrome Blog (noreply@blogger.com) at September 03, 2014 11:32 AM

September 02, 2014

Google Chrome Releases

Beta Channel Update for Chrome OS

The Beta channel has been updated to 38.0.2125.26 (Platform version: 6158.12.0) for all Chrome OS devices. 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:
  • MTP support in the Files app - you can now plug in your Android phone and get files from it.
  • We’ve added a set of features to enhance touch screen accessibility.
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 September 02, 2014 02:35 PM

Stable Channel Update

The stable channel has been updated to 37.0.2062.103 for Windows.  This addresses some user feedback related to how Chrome renders text when display scaling is set to 125% or lower.

As always, 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 September 02, 2014 11:20 AM

August 29, 2014

Google Chrome Releases

Beta Channel Update for Chrome OS

The Beta channel has been updated to 37.0.2062.119 (Platform version: 5978.80.0/5978.81.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 August 29, 2014 05:07 PM

August 28, 2014

Google Chrome Releases

Dev Channel Update

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

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at August 28, 2014 06:31 PM

Chrome Beta for Android Update

Chrome Beta for Android has been updated to 37.0.2062.117 and will be available in Google Play over the next few days. This release fixes various stability and performance bugs, and issues with the UI. A partial list of changes in this build is available in the Git revision 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 August 28, 2014 05:58 PM

Chromium Blog

Mac Chrome: When I’m Sixty-Four (Bits)

On the heels of Tuesday’s release of 64-bit Chrome for Windows, all Mac Chrome users on the beta channel will be updated to a new 64-bit version of Chrome 38. Previously, Chrome was a 32-bit app on Macs. While doubling the number of bits won’t make things twice as good, it does allow us to make a number of speed and security improvements.

64-bit Chrome has become faster as a result of having access to a superior instruction set, more registers, and a more efficient function calling convention. Improved opportunities for ASLR enhance this version’s security. Another major benefit of this change comes from the fact that most programs on a modern Mac are already 64-bit apps. In cases where Chrome was the last remaining 32-bit app, there were launch-time and memory-footprint penalties as 32-bit copies of all of the system libraries needed to be loaded to support Chrome. Now that Chrome’s a 64-bit app too, we expect you’ll find that it launches more quickly and that overall system memory use decreases.

Because of this change, Chrome for Mac will no longer support 32-bit NPAPI plugins, although their 64-bit counterparts are supported. Users shouldn’t notice any changes, because most major plugins are available in both 32-bit and 64-bit form, and many major websites have been switching from NPAPI towards more modern HTML5 APIs. This is also a good time to remind everyone that NPAPI support will be removed from Chrome later this year.

Nearly every Mac user has a computer capable of running this 64-bit version, so we’re automatically updating all Mac Chrome beta channel users. Those few users with first-generation Intel Macs will miss out on the fun, but as we bid them farewell, we’ll remind them that they’ll still be able to run the latest version on the stable channel, Chrome 37.

You can check to see if the Chrome you’re running is a 64-bit version by checking Chrome’s About page (chrome://help) and looking next to the version number. If it says “64-bit” there, that’s a sure sign that you’re running one of these new builds. We hope that this is the only visible difference that you’ll find between the old 32-bit and new 64-bit versions, but in case you find anything amiss during the beta period, please let us know.

Posted by Mark Mentovai, Software Engineer and Register Doubler

by Google Chrome Blog (noreply@blogger.com) at August 28, 2014 05:00 PM

Google Chrome Blog

This time it's personal

Anyone who’s argued over the TV remote knows that sharing a living room doesn’t mean you want to share everything else. The same is true on the web. So in the latest Chrome beta, we're exploring a new way for you to share your computer without sharing your business.

Get started by clicking on “You” in the upper right corner of your Chrome window and then clicking “Sign in to Chrome.” You’ll be able to switch devices and pick up where you left off with all of your tabs, bookmarks, and history automatically kept in sync.

If you share a computer, click "Switch person" to add your profile and get your own bookmarks, apps, and theme. Switching lets you keep your stuff separate.
With the new “Guest mode,” you can let others use Chrome without letting them see your stuff. And after they’ve closed out their tabs, their browsing information is deleted from your computer as well. To enable Guest mode, click on You (or your name if you’ve signed in) > Switch person > Browse as Guest.
Here's to no more login tango or making friends open incognito tabs. Happy (shared) browsing!

Posted by Roger Tawa, your personal Chrome Engineer

by Google Chrome Blog (noreply@blogger.com) at August 28, 2014 04:50 PM

Google Chrome Releases

Stable Channel Update

The stable channel has been updated to 37.0.2062.102 for Windows.  This corrects a bug which led to multi-byte characters sometimes not being rendered on Windows.

As always, 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 August 28, 2014 04:35 PM