Planet Chromium

July 01, 2015

Google Chrome Releases

Android WebView Beta Update

The Chrome team is happy to announce that the WebView beta channel has been updated to 44.0.2403.73 and will be available in Google Play over the next few days for devices on Android 5.0 and higher.

This release contains miscellaneous performance, stability and other fixes.

Interested in trying the WebView beta channel?  Find out how right here.  If you notice any issues, please file a bug.

Alex Mineer
Google Chrome and WebView

by Alex Mineer (noreply@blogger.com) at July 01, 2015 07:04 PM

June 29, 2015

Igalia Chromium

Manuel Rego: CSS Grid Layout is just around the corner (CSSConf US 2015)

Coming back to real life after a wonderful week in New York City is not that easy, but here we’re on the other side of the pond writing about CSS Grid Layout again.

First kudos to Bocoup for the CSSConf US 2015 organization. Specially to Adam Sontag and the rest of the conference staff. You were really supportive during the whole week. And the videos with live transcripts were available just a few days after the conference, awesome job! The only issue was the internet connection which was really flaky.

So, yeah I attended CSSConf this year, but not only that, I was also speaking about CSS Grid Layout and the video of my talk is already online together with the slides.

During the talk I described the basic concepts, syntax and features of CSS Grid with different live coding examples. Then I tried to explain the main tasks that the browser has to do in order to render a grid and gave some tips about grid performance. Finally, we reviewed the browsers adoption and the status of Chromium/Blink and Safari/WebKit implementations that Igalia is doing.

CSS Grid Layout is just around the corner talk sketchnotes by Susan CSS Grid Layout is just around the corner talk sketchnotes by Susan

The feedback about my talk was incredibly positive and everybody seemed really excited about what CSS Grid Layout can bring to the web platform. Big thanks to you all!

Of course, there were other great talks at CSSConf as you can check in the videos. From the top of my head, I loved the one by Lea Verou, impressive talk as usual where she even released a polyfill for conic gradients on the stage. SVG and animations have two nice talks by Chris Coyier and Sarah Drasner. PostCSS and inline styles were also hot topics. Responsive (and responsible!) images, Fun.css and CSS? WTF! were also great (and probably I’m forgetting some other).

Last, on Thursday’s night we attended BrooklynJS which had a great panel discussing about CSS. The inline styles vs stylesheets topic became hot, as projects like React are moving people away from stylesheets. Chris Coyier (one of the panelists and also speaker at CSSConf) wrote a nice post past week giving a good overview of this topic. Also The Four Fives were amazing!

On top of that, as part of the collaboration between Igalia and Bloomberg, I was visiting their fancy office in Manhattan. I spent a great time there talking about grids with several people from the team. They really believe that CSS Grid Layout will change the future of the web benefiting lots of people in different use cases, and hopefully helping to alleviate performance issues in complex scenarios.

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

Looking forward for the next opportunity to talk about CSS Grid Layout. Keeping the hard work to make it a reality as soon as possible!

June 29, 2015 10:00 PM

June 26, 2015

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 45.0.2439.3 (Platform version: 7204.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).

Matthew Yuan
Google Chrome

by Matthew Yuan (noreply@blogger.com) at June 26, 2015 11:52 AM

June 25, 2015

Google Chrome Releases

Beta Channel Update for Chrome OS

The Beta channel has been updated to 44.0.2403.62 (Platform version: 7077.60.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 June 25, 2015 11:10 AM

Dev Channel Update for Chrome OS


The Dev channel has been updated to 45.0.2431.0 (Platform version: 7173.2.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 Matthew Yuan (noreply@blogger.com) at June 25, 2015 10:57 AM

June 24, 2015

Google Chrome Releases

Android WebView Beta Update

The Chrome team is happy to announce that the WebView beta channel has been updated to 44.0.2403.64 and will be available in Google Play over the next few days for devices on Android 5.0 and higher.

This release contains miscellaneous performance, stability and other fixes.

Interested in trying the WebView beta channel?  Find out how right here.  If you notice any issues, please file a bug.

Alex Mineer
Google Chrome and WebView

by Alex Mineer (noreply@blogger.com) at June 24, 2015 07:15 PM

Beta Channel Update

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

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at June 24, 2015 01:04 PM

Igalia Chromium

Javier Fernández: Performance analysis of Grid Layout

Now that we have a quite complete implementation of CSS Grid Layout specification it’s time to take care of performance analysis and optimizations. In this essay, which is the first of a series of posts about performance, I’ll first introduce briefly how to use Blink (Chrome) and WebKit (Safari) performance analysis tools, some of the most interesting cases I’ve seen during my work on the implementation of this spec and, finally, a basic case to compare Flexbox and Grid layout models, which I’d like to evolve and analyze further in the coming months.

Performance analysis tools

Both WebKit and Blink projects provide several useful and easy to use scrips (python) to run a set of test cases and take different measurements and early analysis. They were written before the fork, that’s why related documentation can be found at WebKit’s track, but both engines still uses them, for the time being.

Tools/Scripts/run-perf-tests
Tools/Scripts/webkitpy/performance_tests/

There are a wide set of performance tests under PerformanceTest folder, at Blink’s/WebKit’s root directory, but even though both engines share a substantial number of tests, there are some differences.

(blink’s root directory) $ ls PerformanceTests/
Bindings BlinkGC Canvas CSS DOM Dromaeo Events inspector Layout Mutation OWNERS Parser resources ShadowDOM Skipped SunSpider SVG XMLHttpRequest XSSAuditor

Chromium project has introduced a new performance tool, called Telemetry, which in addition of running the above mentioned tests, it’s designed to execute more complex cases like running specific PageSets or doing benchmarking to compare results with a preset recording (WebPageRelay). It’s also possible to send patches to performance try bots, directly from gclient or git (depot_tools) command line. There are quite much information available in the following links:

Regarding profiling tools, it’s possible both in Webkit and Blink to use the –profiler option when running the performance tests so we can collect profiling data. However, while WebKit recommends perf for linux, Google’s Blink engine provides some alternatives.

CSS Grid Layout performance tests and current status

While implementing a new browser feature is not easy to measure performance while code evolves so much and quickly and, what it’s worst, be aware of regressions introduced by new logic. When the feature’s syntax changes or there are missing or incomplete functionality, it’s not always possible to establish a well defined baseline for performance. It’s also a though decision to determine which use cases we might care about; obviously the faster the better, but adding performance optimizations usually complicates code, it may affect its robustness and it could lead to unexpected, and even worst, hard to find bugs.

At the time of this writing, we had 3 basic performance tests:

Why we have selected those uses cases to measure and keep track of performance regression ? First of all, note that auto-sizing one of the most expensive branches inside the grid track sizing algorithm, so we are really interested on both, improving it and keeping track of regressions on this code path.

body {
    display: grid;
    grid-template-rows: repeat(100, auto);
    grid-template-columns: repeat(20, auto);
}
.gridItem {
    height: 200px;
    width: 200px;
}

On the other hand, fixed-sized is the easiest/fastest path of the algorithm, so besides the importance of avoiding regressions (when possible), it’s also a good case to compare with auto-sized.

body {
    display: grid;
    grid-template-rows: repeat(100, 200px);
    grid-template-columns: repeat(20, 200px);
}
.gridItem {
    height: 200px;
    width: 200px;
}

Finally, a stretching use cases was added because it’s the default alignment value for grid items and the two test cases already described use fixed size items, hence no stretch (even though items fill the whole grid cell area). Given that I implemented CSS Box Alignment support for grid I was conscious of how expensive the stretching logic is, so I considered it an important use case to analyze and optimize as much as possible. Actually, I’ve already introduced several optimizations because the early implementation was quite slow, around 40% slower than using any other basic alignment (start, end, center). We will talk more about this later when we analyze a case to compare Flexbox and Grid performance in layout.

body {
    display: grid;
    grid-template-rows: repeat(100, 200px);
    grid-template-columns: repeat(20, 200px);
}
.gridItem {
    height: auto;
    width: auto;
}

The basic HTML body of these 3 tests is quite simple because we want to analyze performance of very specific parts of the Grid Layout logic, in order to detect regressions in sensible code paths. We’d like to have eventually some real use cases to analyze and create many more performance tests, but chrome performance platform it’s definitively not the place to do so. The following graphs show performance evolution during 2015 for the 3 tests we have defined so far.

grid-performance-overview

Note that yellow trace shows data taken from a reference build, so we can discount temporary glitches on the machine running the performance tests of target build, which are shown in the blue trace; this reference trace is also useful to detect invalid regression alerts.

Why performance is so different for these cases ?

The 3 tests we have for Grid Layout use runs/second values as a way to measure performance; this is the preferred method for both WebKit and Blink engines because we can detect regressions with relatively small tests. It’s possible, though, to do other kind of measurements. Looking at the graphs above we can extract the following data:

  • auto-sized grid: around 650 runs/sec
  • fixed-sized grid: around 1400 runs/sec
  • fixed-sized stretched grid: around 1250 runs/sec

Before analyzing possible causes of performance drop for each case, I’ve defined some additional tests to stress even more these 3 cases, so we can realize how grid size affect to the obtained results. I defined 20 tests for these cases, each one with different grid items; from 10×10 up to 200×200 grids. I run those tests in my own laptop, so let’s take the absolute numbers of each case with a grain of salt; although differences between each of these 3 scenarios should be coherent. The table below shows some numeric results of this experiment.

grid-fixed-VS-auto-VS-stretch

First of all, recall that these 3 tests produce the same web visualization, consisting of grids with NxN items of 100px each one. The only difference is the grid layout strategy used to produce such result: auto-sizing, fixed-sizing and stretching. So now, focusing on previous table’s data we can evaluate the cost, in terms of layout performance, of using auto-sized tracks for defining the grid (which may be the only solution for certain cases). Performance drop is even growing with the number of grid items, but we can conclude that it’s stabilized around 60%. On the other hand stretching is also slower but, unlike auto-sized, in this case performance drop does not show a high dependency of grid size, more or less constant around 15%.

grid-performance-graphs-2

Impact of auto-sized tracks in layout performance

Basically, the track sizing algorithm can be described in the following 4 steps:

  • 1- Initialize per Grid track variables.
  • 2- Resolve content-based TrackSizingFunctions.
  • 3- Grow all Grid tracks in GridTracks from their baseSize up to their growthLimit value until freeSpace is exhausted.
  • 4- Grow all Grid tracks having a fraction as the MaxTrackSizingFunction.

These steps will be executed twice, first cycle for determining column tracks’s size and another cycle to set row tracks’s size which it may depend on grid’s width. When using just fixed-sized tracks in the very simple case we are testing, the only computation required to determine grid’s size is completing step 1 and determining free available space based on the specified fixed-size values of each track.

// 1. Initialize per Grid track variables.
for (size_t i = 0; i < tracks.size(); ++i) {
    GridTrack& track = tracks[i];
    GridTrackSize trackSize = gridTrackSize(direction, i);
    const GridLength& minTrackBreadth = trackSize.minTrackBreadth();
    const GridLength& maxTrackBreadth = trackSize.maxTrackBreadth();
 
    track.setBaseSize(computeUsedBreadthOfMinLength(direction, minTrackBreadth));
    track.setGrowthLimit(computeUsedBreadthOfMaxLength(direction, maxTrackBreadth, track.baseSize()));
 
    if (trackSize.isContentSized())
        sizingData.contentSizedTracksIndex.append(i);
    if (trackSize.maxTrackBreadth().isFlex())
        flexibleSizedTracksIndex.append(i);
}
for (const auto& track: tracks) {
    freeSpace -= track.baseSize();
}

Focusing now on the auto-sized scenario, we will have the overhead of resolving content-sized functions for all the grid items.

// 2. Resolve content-based TrackSizingFunctions.
if (!sizingData.contentSizedTracksIndex.isEmpty())
    resolveContentBasedTrackSizingFunctions(direction, sizingData);

I didn’t add source code of resolveContentBasedTrackSizingFunctions because it’s quite complex, but basically it implies a cost proportional to the number of grid tracks (minimum of 2x), in order to determine minContent and maxContent values for each grid item. It might imply additional computation overhead when using spanning items; it would require to sort them based on their spanning value and iterate over them again to resolve their content-sized functions.

Some issues may be interesting to analyze in the future:

  • How much each content-sized track costs ?
  • What is the impact on performance of using flexible-sized tracks ? Would it be the worst case scenario ? Considering it will require to follow the four steps of track sizing algorithm, it likely will.
  • Which are the performance implications of using spanning items ?

Why stretching is so performance drain ?

This is an interesting issue, given that stretch is the default value for both Grid and Flexbox items. Actually, it’s the root cause of why Grid beats Flexbox in terms of layout performance for the cases when stretch alignment is used. As I’ll explain later, Flexbox doesn’t have the optimizations I’ve implemented for Grid Layout.

Stretching logic takes place during the grid container layout operations, after all tracks have their size precisely determined and we have properly computed all grid track’s positions relatively to the grid container. It happens before the alignment logic is executed because stretching may imply changing some grid item’s size, hence they will be marked for layout (if they wasn’t already).

Obviously, stretching only takes place when the corresponding Self Alignment properties (align-self, justify-self) have either auto or stretch as value, but there are other conditions that must be fulfilled to trigger this operation:

  • box’s computed width/height (as appropriate to the axis) is auto.
  • neither of its margins (in the appropriate axis) are auto
  • still respecting the constraints imposed by min-height/min-width/max-height/max-width

In that scenario, stretching logic implies the following operations:

LayoutUnit stretchedLogicalHeight = availableAlignmentSpaceForChildBeforeStretching(gridAreaBreadthForChild, child);
LayoutUnit desiredLogicalHeight = child.constrainLogicalHeightByMinMax(stretchedLogicalHeight, -1);
 
bool childNeedsRelayout = desiredLogicalHeight != child.logicalHeight();
if (childNeedsRelayout || !child.hasOverrideLogicalContentHeight())
    child.setOverrideLogicalContentHeight(desiredLogicalHeight - child.borderAndPaddingLogicalHeight());
if (childNeedsRelayout) {
    child.setLogicalHeight(0);
    child.setNeedsLayout();
}
 
LayoutUnit LayoutGrid::availableAlignmentSpaceForChildBeforeStretching(LayoutUnit gridAreaBreadthForChild, const LayoutBox& child) const
{
    LayoutUnit childMarginLogicalHeight = marginLogicalHeightForChild(child);
 
    // Because we want to avoid multiple layouts, stretching logic might be performed before
    // children are laid out, so we can't use the child cached values. Hence, we need to
    // compute margins in order to determine the available height before stretching.
    if (childMarginLogicalHeight == 0)
        childMarginLogicalHeight = computeMarginLogicalHeightForChild(child);
 
    return gridAreaBreadthForChild - childMarginLogicalHeight;
}

In addition to the extra layout required for changing grid item’s size, computing the available space for stretching adds an additional overhead, overall if we have to compute grid item’s margins because some layout operations are still incomplete.

Given that grid container relies on generic block’s layout operations to determine the stretched width, this specific logic is only executed for determining the stretched height. Hence performance drop is alleviated, compared with the auto-sized tracks scenario.

Grid VS Flexbox layout performance

One of the main goals of CSS Grid Layout specification is to complement Flexbox layout model for 2 dimensions. It’s expectable that creating grid designs with Flexbox will be more inefficient than using a layout model specifically designed for these cases, not only regarding CSS syntax, but also regarding layout performance.

However, I think it’s interesting to measure Grid Layout performance in 1-dimensional cases, usually managed using Flexbox, so we can have comparable scenarios to evaluate both models. In this post I’ll start with such cases, using a very simple one in this occasion. I’d like to get more complex examples in future posts, the ones more usual in Flexbox based designs.

So, let’s consider the following simple test case:

<div class="className">
   <div class="i1">Item 1</div> 
   <div class="i2">Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</div>
   <div class="i3">Item 3 longer</div>
</div>

I evaluated the simple HTML example above with both Flexbox and Grid layouts to measure performance. I used a CPU profiler to figure out where the bottlenecks are for each model, trying to explain where differences came from. So, I defined 2 CSS classes for each layout model, as follows:

.flex {
    background-color: silver;
    display: flex;
    height: 100px;
    align-items: start;
}
.grid {
    background-color: silver;
    display: grid;
    grid-template-columns: 100px 1fr auto;
    grid-template-rows: 100px;
    align-items: start;
    justify-items: start;
}
.i1 { 
    background-color: cyan;
    flex-basis: 100px; 
}
.i2 { 
    background-color: magenta;
    flex: 1; 
}
.i3 { 
    background-color: yellow; 
}

Given that there is not concept of row in Flexbox, I evaluated performance of 100 up to 2000 grid or flex containers, creating 20 tests to be run inside the chrome performance framework, described at the beginning of this post. You can check out resources and a script to generate them at our github examples repo.

flexVSgrid

When comparing both layout models targeting layout times, we see clearly that Grid Layout beats Flexbox using the default values for CSS properties controlling layout itself and alignment, which is stretch for these containers. As it was explained before, the stretching logic adds an important computation overhead, which as we can see now in the numeric table above, has more weight for Flexbox than Grid.

Looking at the plot about differences in layout time, we see that for the default case, Grid performance improvement is stabilized around 7%. However, when we avoid the stretching logic, for instance by using any other alignment value, layout performance it’s considerable worse than Flexbox, for this test case, around 15% slower. This is something sensible, as this test case is the idea for Flexbox, while a bit artificial for Grid; using a single Grid with N rows improves performance considerably, getting much better numbers than Flexbox, but we will see these cases in future analysis.

Grid layout better results for the default case (stretch) are explained because I implemented several optimizations for Grid. Probably Flexbox should do the same, as it’s the default value and it could affect many sites using this layout model in their designs.

Thanks to Bloomberg for sponsoring this work, as part of the efforts that Igalia has been doing all these years pursuing a better and more open web.

Igalia & Bloomberg logos

by jfernandez at June 24, 2015 12:03 PM

June 23, 2015

Google Chrome Releases

Stable Channel Update for Chrome OS

The Stable channel has been updated to 43.0.2357.130 (Platform version: 6946.63.0) for all devices. This build contains a number of bug fixes and security updates. Systems will be receiving updates over the next several days.

A summary of security fixes list is available 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 June 23, 2015 09:07 PM

Dev Channel Update

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

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

Anantha Keesara
Google Chrome

by ananthak (noreply@blogger.com) at June 23, 2015 01:40 PM

June 22, 2015

Google Chrome Releases

Chrome Stable Update

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

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

[$5000][464922] High CVE-2015-1266: Scheme validation error in WebUI. Credit to anonymous.
[TBD][494640] High CVE-2015-1268: Cross-origin bypass in Blink. Credit to Mariusz Mlynski.
[TBD][497507] Medium CVE-2015-1267: Cross-origin bypass in Blink. Credit to anonymous.
[TBD][461481] Medium CVE-2015-1269: Normalization error in HSTS/HPKP preload list. Credit to Mike Ruddy.

Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.

Are you a project manager,  with a technical background, who is passionate about Chrome and moving the web forward?  We are hiring!

Anthony Laforge
Google Chrome

by laforge@chromium (noreply@blogger.com) at June 22, 2015 09:30 AM

June 19, 2015

Google Chrome Releases

Beta Channel Update for Chrome OS

The Beta channel has been updated to 44.0.2403.54 (Platform version: 7077.49.0) for all Chrome OS devices except Lenovo ThinkPad 11e, Chromebook 11, HP Chromebook 11 G3 and Asus Chromebook C300. 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 June 19, 2015 11:20 AM

June 18, 2015

Igalia Chromium

Andy Wingo: arrow functions coming to chrome 45!

It's been a long time coming, but I just flipped the bit in V8 that will ship arrow functions in Chrome 45! Woo hoo!

You probably know, but arrow functions are a new way to write functions in JavaScript. They look like this:

// Two arguments, body implicitly returned.
(x, y) => x + y

// With just one argument, no parentheses needed.
x => x * 2

// Body can have braces too; in that case use "return".
x => { return x * 2 }

Relative to the other kind of function that is written like function (x) { return x * 2 }, arrow functions don't define this or arguments in their bodies, instead capturing these values from the environment. There are a couple of other minor differences, too, but instead of writing about them here I'll just point to the great article by Jason Orendorff of the SpiderMonkey team.

Arrow functions are part of the JavaScript language standard that was called "ECMAScript 6" or ES6, and I guess you could still call it that. It seems like a silly thing for the committee to do to throw away all their branding like that but they decided to rename it ECMAScript 2015, which I'm sure is a link that the pedants are glad I have included. The upshot is that the standard is now final, gold master, etched in stone, which from an implementor's perspective is a relief. You can practically feel the anxiety ebbing away by the happy rate at which commits bubble out of source repositories and into shipping browsers, free from the fear that some spec change will force the hack-stream to change course.

From the V8 side, our arrow function implementation has also been a long time coming. My colleague Adrián Pérez did the first half of the work, and I picked up on the back end of things. It seems like such a small feature and in many ways it is, but still it took a long time. Now I know that my readers are a bunch of nerds and many of you like implementing languages, so you might appreciate these nargish points.

One of the first bits is that arrow functions are hard to parse. Consider, this is a valid JavaScript expression:

(x,y)

It's a "comma expression" that will evaluate x then y and its result will be the result of evaluating y. But add an arrow on after the end and you get not an expression but a formal parameter list:

(x,y)=>x+y

Now you might think, well OK, when you see an arrow, rewind the input stream and parse in "arrow function mode". Indeed that would be fine, but not in combination with some additional ES6 features, optional and destructuring arguments. Optional arguments look like this:

(x=42)=>x

The =42 part is the expression that will be evaluated to give x a value, if the function is called with no arguments. Note that this bit is still under implementation in V8 so you can't try it in your browser. An optional argument initializer is an expression and not a value, so you can also have:

(x=(x)=>42)=>x

Combined, this makes rewinding the token stream a proposition of exponential complexity, which is a no-go for a production JavaScript parser. Parsers are on the hot path for page-load times and no browser vendor wants to introduce a pathological case into their page load.

Instead, V8 does something I hadn't seen before. It keeps an open mind about whether something is a comma expression or a formal parameter list of an arrow function, and only makes a decision when it sees the => (or not). As it parses, V8 records places that it would signal an error for either a parameter list or for an expression, and then when that superimposed wave function collapses it checks that the production is valid, signalling the appropriate error if not. I thought this was a really neat trick, so if you're into that thing see expression classifier to see those details.

The other thing that's tricky about arrow functions is the this binding. In JavaScript, this is basically a hidden parameter passed to a function when it is called. Calling a function like o.f() passes the value of o to f as its this parameter. If instead f() is called directly, like with no dot before the call, then undefined is passed as this. Also for sloppy-mode functions, if the passed this value isn't an object, then the global object instead is assigned to this. Finally outside a function, this is bound to the global object.

OK, I know all of you know these things. Thing is, you always have a this, and although it's like a variable it's not a valid variable name, and before ES6 nothing could capture its value, because each function has its own this value. Perhaps you see where I'm going with this (ahem) now. Arrow functions introduce a function scope that doesn't have a this value, and that indeed might capture some other scope's this value, forcing it to be context-allocated. Other parts of ES6 can actually force assignment to this, like a super call, and that assignment can actually come from within an arrow function. Zounds! A simple concept, but there was a lot of incidental complexity in V8 around the implementation. Between Adrián and myself it took like three months to fix this usage in V8 to always just go through the (possibly context-allocated) variable, and there are still probably some devtools bugs to find in the upcoming weeks.

Performance-wise, arrow functions are just like functions. They should be just as fast as if you wrote them with function. So use them with joy, use them with abandon, use them judiciously -- however you decide you use them, don't let perf influence your decision one way or the other.

That's about it! Like all of my JS engine work over the past couple years, this hacking was sponsored by fabulous folks over at Bloomberg, so big ups to them. From me and Adrián at Igalia, until next time! We leave you to puzzle out what this bit of JavaScript evaluates to:

(({},{},({},{})=>({},{}))=>(({},{})=>({},{}),{},{}))({},{})

Happy hacking!

by Andy Wingo at June 18, 2015 04:41 PM

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 45.0.2427.10 (Platform version: 7155.1.0 or 7155.2.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 Matthew Yuan (noreply@blogger.com) at June 18, 2015 10:55 AM

June 17, 2015

Google Chrome Releases

Stable Channel Update for Chrome OS

The Stable channel has been updated to 43.0.2357.125 (Platform version: 6946.58.0/6946.59.0) for all devices. This build contains a number of bug fixes and security updates. Systems will be receiving updates over the next several days.

Some highlights of these changes are:
  • Updated Adobe Flash Player to 18.0.0.160-r1

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 June 17, 2015 08:15 PM

Android WebView Beta Update

The Chrome team is happy to announce that the WebView beta channel has been updated to 44.0.2403.54 and will be available in Google Play over the next few days for devices on Android 5.0 and higher.

This release contains miscellaneous stability and other fixes.

Interested in trying the WebView beta channel?  Find out how right here.  If you notice any issues, please file a bug.

Alex Mineer
Google Chrome and WebView

by Alex Mineer (noreply@blogger.com) at June 17, 2015 07:28 PM

Chrome Beta for Android Update

Chrome Beta for Android has been updated to 44.0.2403.54 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 June 17, 2015 07:27 PM

Beta Channel Update

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

Anantha Keesara
Google Chrome

by ananthak (noreply@blogger.com) at June 17, 2015 04:02 PM

June 16, 2015

Google Chrome Releases

Dev Channel Update

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

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at June 16, 2015 12:37 PM

June 12, 2015

Google Chrome Releases

Beta Channel Update for Chrome OS

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

Dharani Govindan
Google Chrome

by Dharani (noreply@blogger.com) at June 12, 2015 07:06 AM

June 11, 2015

Google Chrome Releases

Dev Channel Update

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

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at June 11, 2015 11:20 PM

Beta Channel Update

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

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at June 11, 2015 11:18 PM

Dev Channel Update

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

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at June 11, 2015 11:17 PM

Stable Channel Update

The stable channel has been updated to 43.0.2357.125 for Linux.  A partial list of changes is available in the log.

Key Fixes:
  • [498426] Resolved browser font magnification/scaling issue.

Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.

Anthony Laforge
Google Chrome

by laforge@chromium (noreply@blogger.com) at June 11, 2015 02:40 PM

Chromium Blog

File System Provider API for easier file management

On Chrome OS, users should be able to work with files in the cloud as easily as they work with local files.
Today, users often have their files spread all over the cloud -- with documents in one place, their photos in another, and videos somewhere else. Working across all of those systems can be a challenge, which is where the File System Provider API in Chrome OS can help. With the File System Provider API, users who install your Chrome App can have your Cloud service seamlessly integrated into the Chrome OS Files app. Working with multiple storage backends becomes as easy as dragging and dropping files locally.

As usual, users can install your Chrome app or extension from the Chrome Web Store. Or, they can add new services directly from the Files app. The new file system will then appear directly in the left navigation column. Users can browse this file system anywhere the Files app is shown, including Save as and Open dialogs.

Screenshot 2015-04-29 at 12.36.48 PM.png

Your extension just needs to call chrome.fileSystemProvider.mount and respond to the listed events. Developers have already created some great apps, including the Box.com official client, an SMB client, and even a way to browse TED talks locally. Check out the documentation or join the mailing list to stay informed about announcements and API changes.

Posted by Tomasz Mikolajewski, Filesystem Fiend

by Google Chrome Blog (noreply@blogger.com) at June 11, 2015 11:14 AM