Today we’re announcing the addition of 64-bit support to Chrome, with two brand new 64-bit Dev and Canary channels for Windows 7 and 8 users, giving a faster and more secure browsing experience. To try it out, download the 64-bit installer from our Canary or Dev download pages. The new version replaces the existing version while preserving all your settings and bookmarks, so there’s no need to uninstall a current installation of Chrome.

The majority of our users on Windows 7 or higher now have systems capable of running 64-bit applications, and this version of Chrome can take full advantage of these newer capabilities. This includes several improvements that align perfectly with Chrome’s core principles of speed, security and stability:

• Speed: 64-bit allows us to take advantage of the latest processor and compiler optimizations, a more modern instruction set, and a calling convention that allows more function parameters to be passed quickly by registers. As a result, speed is improved, especially in graphics and multimedia content, where we see an average 25% improvement in performance.

• Security: With Chrome able to take advantage of the latest OS features such as High Entropy ASLR on Windows 8, security is improved on 64-bit platforms as well. Those extra bits also help us better defend against exploitation techniques such as JIT spraying, and improve the effectiveness of our existing security defense features like heap partitioning.

• Stability: Finally, we’ve observed a marked increase in stability for 64-bit Chrome over 32-bit Chrome. In particular, crash rates for the the renderer process (i.e. web content process) are almost half that of 32-bit Chrome.

We encourage all our users, especially developers, to give the new 64-bit Chrome a spin, and we’re looking forward to hearing your feedback so we can make 64-bit Chrome work great and bring its benefits to our Beta and Stable channel users.

Posted by Will Harris, Software Engineer and Stretcher of Pointers

Last September, we announced our plan to remove NPAPI support from Chrome by the end of 2014. This change will improve Chrome’s security, speed, and stability as well as reduce complexity in the code base. Over the last few quarters, we’ve been encouraged to see an overall 12.9% drop in per-user instantiations of NPAPI plug-ins and declining usage of the most popular NPAPI plug-ins:

Monthly Plug-In Launch Percentage

	Sept 2013	May 2014
Silverlight	15	13.3
Google Earth	9.1	0.1
Unity	9.1	3.1
Google Talk	8.7	8.7
Java	8.9	7.2
Facebook	6	4.2

We are actively helping still-popular NPAPI-based
services migrate to open-web-based alternatives.

Deprecation has proceeded as scheduled. As of September 23rd, 2013, the Chrome Web Store no longer accepts NPAPI-based Apps and Extensions. Webpage-instantiated NPAPI plug-ins have been blocked by default since January 2014 using the infobar UI. NPAPI support was removed from Linux in Chrome 35.

To further prepare users and developers for complete removal, we’ll be making two more updates in the coming weeks. Starting today, the Chrome Web Store will no longer show NPAPI-based Apps and Extension on the home page, search results, and category pages. In Chrome 37, webpage-instantiated NPAPI plug-ins will be blocked using the harder-to-bypass page-action blocking UI.

Most use cases that previously required NPAPI are now supported by JavaScript-based open web technologies. For the few applications that need low-level APIs, threads, and machine-optimized code, Native Client offers the ability to run sandboxed native code in Chrome. To help ease the transition from NPAPI, NaCl recently exposed two new Pepper APIs for media playback and processing. The MediaStreams API enables low latency multimedia playback, and the Hardware Decode API enables efficient video decoding.

For more information, please see the developer NPAPI deprecation guide. We look forward to the transition to a safer, more mobile-friendly web.

Posted by Justin Schuh, Software Engineer and Plug-in Retirement Planner

Today’s Chrome Beta channel release includes several new developer features to help you make richer, 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.

element.animate()

The forthcoming Web Animations JavaScript API lets you animate web content from script. The element.animate() function included in today’s Beta is the first part of the API to ship in Chrome: it makes it possible to create simple CSS Animations using JavaScript. This means that animations can be dynamically generated without paying a CSS style recalculation cost. Animations created in this way are also cancelable and provide guaranteed end events (in contrast, CSS Transitions only generate events if they cause a style change). Here's an example of how you'd use it:

elem.animate([
    {transform: 'translateX(0px)'},
    {transform: 'translateX(100px)'}
], 3000);

HTML Imports

HTML Imports, part of the Web Components standards umbrella, offer a way to include HTML documents in other HTML documents using <link rel="import">:

<head>
  <link rel="import" href="/path/to/imports/stuff.html">
</head>

An HTML Import can contain CSS, JavaScript, HTML, or anything else an .html file can include. This means they provide a convention for bundling related HTML/CSS/JS (even other HTML Imports) into a single package, making them a fantastic tool for delivering Web Components to users.

Data-binding with Object.observe()

Object.observe() lets you observe changes to JavaScript objects. You can define a callback that observes multiple objects and will receive all changes to any objects in a single asynchronous call. This is especially useful for framework authors implementing data-binding.

// Let's say we have a model with data
var model = {};

// Which we then observe
Object.observe(model, function(changes) {

    // This asynchronous callback runs and aggregates changes
    changes.forEach(function(change) {

        // Letting us know what changed
        console.log(change.type, change.name, change.oldValue);
    });

});

Other updates in this release

• Chrome no longer sends touchcancel on touch scroll, improving compatibility with other browsers and making it possible to add touch UI effects like pull-to-refresh without re-implementing scrolling and fling physics in JavaScript.
• Some CSS properties such as scrollTop and offsetHeight will now return fractional values in browser-zoom situations.
• The new WOFF 2.0 Web Font compression format offers a 30% average gain over WOFF 1.0 (up to 50%+ in some cases).
• DevTools now faithfully emulates touch with mouse, allowing you to test touch interactions on Chrome for Android using the mobile emulation feature of DevTools.
• Unprefixed CSS Transforms enables rich web content by allowing elements to be transformed in two-dimensional or three-dimensional space.

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 Shane Stephens and Doug Stockwell, Animated Software Engineers

In 2009, we developed ThreadSanitizer (aka TSan), a runtime data race detector based on binary translation. The tool helped find thousands of threading errors in various projects, including almost 180 bugs in Chromium. In 2010, we started experimenting with compiler-based instrumentation instead of binary translation, and once the approach had proven itself, our team redesigned ThreadSanitizer from scratch, focusing on compile-time instrumentation for greater speed and accuracy.

The new tool, ThreadSanitizer v2, is now part of both LLVM and GCC. Not only is it able to detect data races in C++ and Go code, but it is also able to report synchronization issues like deadlocks, unjoined threads, destroying locked mutexes, use of async-signal unsafe code in signal handlers, and others.

ThreadSanitizer v2 recognizes atomic operations, so it produces far more accurate reports and can also find bugs in lock-free algorithms, which are hard to detect otherwise. For example, it has helped us find incorrect synchronization in LazyInstance, incorrect lock-free queue implementation, and issues with concurrent sweeping in V8.

The new version is up to 20 times faster than the old ThreadSanitizer, which makes it possible to use it for heavyweight browser tests. Thanks to this, we’ve found several bugs in code that wasn’t covered by smaller unit tests, like races on the WebKit strings, garbage collection in Blink, a use-after-free in Blink, a handful of reports in WebRTC and many more. This has also improved bug reproducibility: the more times the test is repeated, the higher the chance to reproduce a flaky bug.

Over the last half-year almost 100 bugs were detected by the new tool, and we’re actively working on more. Our future plans include extensive use of TSan on ClusterFuzz and adding regular testing for various Chromium subprojects to catch new regressions quickly.

The ThreadSanitizer page contains all of the information necessary to start using the tool in your project. The tool is easy to use and can be integrated with any buildsystem: just add a single compile-time flag and run the program to see the error reports. For Chromium developers there’s a special page with instructions on dev.chromium.org.

Posted by Alexander Potapenko, Software Engineer and Synchronization Lookout

Today’s Chrome Beta channel release includes a slew of new developer features to help you make richer, 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.

More developer control over touch and zoom input

The touch-action CSS property offers developers a declarative mechanism to selectively disable touch scrolling, pinch-zooming, or double-tap-zooming on parts of their web content. Use cases include precise control over the dreaded 300ms click delay on mobile, reliable side-swipe UIs, and high-fidelity polyfills of Pointer Events. It’s also a prerequisite for future optimizations to enable scrolling and zooming that never block on the main thread. Update May 20th: touch-action has been delayed until Chrome 36.

Also new in this release, web content on desktop computers will now receive mouse scroll wheel events with the ctrlKey modifier set. There are many sites that want to do something more appropriate for the user than trigger browser zoom. For example, when a user holds control and scrolls over a map in Google Maps, they almost certainly want to zoom in on the map, not invoke browser zoom to zoom the page. This change will enable such a use case.

New JavaScript functionality

Chrome 35 includes support for a number of new JavaScript features defined in the ECMAScript 6 standard. Together, they will help JavaScript developers write application logic that is easier to read, more powerful, and more memory efficient.

A Promise represents a value that may not be available yet but will be known at some point in future. With Promises, you can write cleaner asynchronous code. WeakMaps and WeakSets allow you to create efficient, garbage-collected data structures. In both, references to objects are held weakly: if there is no other reference to an object stored in the WeakSet, it can be garbage collected. This helps avoid memory leaks.

Object.observe lets you observe changes to JavaScript objects. Your callback can observe multiple objects and will receive all changes to any objects in a single asynchronous call. This is especially useful for framework authors implementing data-binding.

Update April 29th: Object.observe has been pushed back to Chrome 36.

Unprefixed Shadow DOM

Shadow DOM is one of several new API primitives landing under the Web Components umbrella. It brings reliable composition of user interface elements to the web platform and allow developers to:

1. Scope their HTML markup, CSS, hiding the implementation details of complex components.
2. Build their own first-class elements and APIs just like the <video> or <audio>, when combined with Custom Elements

With Shadow DOM, web frameworks can stop worrying about their widgets inadvertently breaking pages by using conflicting CSS selectors, class or id names, and start relying on DOM as the interoperable way of building components.

Numerous improvements and changes have been made to the specification since the days of the prefixed implementation of Shadow DOM made available in Chrome 25, so if you were already using the prefixed Shadow DOM API please take a look at the latest documentation as well as the up-to-date HTML5 Rocks articles and look for deprecation warnings.

Other new features in this release

• CSS Font Loading can be used to dynamically load font resources. It gives developers more control over the user experience on pages that use Web Fonts. For instance, you can ask Chrome to start downloading the web fonts you'll need on demand and be notified when they become available.
• The SVG 'paint-order' property offers a way to control the order in which fill, stroke and markers are painted.
• The unprefixed version of the Web Audio API.

Removed features

Web platform feature deprecation and removal are important for the health of the web. Removing features allows browser vendors like Chromium to simplify our codebases, minimize security attack surfaces, and, most importantly, evolve the web API surface to address the needs of today’s users and developers.

Features removed in this release include HTMLVideoElement-specific prefixed fullscreen API, TextTrackCue constructor, <isindex>, Legacy Web Notifications, document.createAttributeNS, support for NPAPI on Linux, and Attr.isId, ownerElement, prefix setter. If you’d like to hear more about these changes or participant in discussions, please chime in our mailing list and look for "Intent to Remove" or “Intent to Deprecate” threads.

Recently deprecated features

The most prominent recently deprecated feature is window.showModalDialog, which will be removed in our next release, Chrome 36. Please read Opera’s explanation of the change to learn more. Other deprecated features include Element.setAttributeNodeNS, overflowchanged Event, HTMLSourceElement.media, MediaError.MEDIA_ERR_ENCRYPTED, Prefixed media source extensions, and webkitRequestAnimationFrame. Support for these features will be completely removed from Chrome in a future release.

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 Rick Byers, Software Engineer and Touch API Tamer

Today's release of the Dart SDK version 1.3 includes a 2x performance improvement for asynchronous Dart code combined with server-side I/O operations. This puts Dart in the same league as popular server-side runtimes and allows you to build high-performance server-side Dart VM apps.

We measured request-per-second improvements using three simple HTTP benchmarks: Hello, File, and JSON. Hello, which improved by 130%, provides a measure for how many basic connections an HTTP server can handle, by simply measuring an HTTP server responding with a fixed string. The File benchmark, which simulates the server accessing and serving static content, improved by nearly 30%. Finally, as a proxy for performance of REST apps, the JSON benchmark nearly doubled in throughput. In addition to great performance, another benefit of using Dart on the server is that it allows you to use the same language and libraries on both the client and server, reducing mental context switches and improving code reuse.

The data for the chart above was collected on a Ubuntu 12.04.4 LTS machine with 8GB RAM and a Intel(R) Core(TM) i5-2400 CPU, running a single-isolate server on Dart VM version 1.1.3, 1.2.0 and 1.3.0-dev.7.5. The source for the benchmarks is available.

We are excited about these initial results, and we anticipate continued improvements for server-side Dart VM apps. If you're interested in learning how to build a web server with Dart, check out the new Write HTTP Clients and Servers tutorial and explore the programmer's guide to command-line apps with Dart. We hope to see what you build in our Dartisans G+ community.

Written by Anders Johnsen, Speed Obsessed Software Engineer

Last April we introduced Blink as the new rendering engine for Chromium. Since then, the project has grown to include over 200 active contributors, and code complexity has been reduced significantly. We’ve also made encouraging progress on our top priority for 2014: mobile web performance.

A productive community emerged on our mailing list within Blink’s first few months. Each week, we now see on average 23 new discussion threads and 5 new “intents” to change the web API surface. We’re honored that 41% of our “intents” have come from folks outside of Google, and 33% of our active contributors are non-Googlers. We’re especially excited about recent contributions like Yoav Weiss’s implementation of the <picture> element, the Opera team’s prolific improvements and feature removals, Intel’s performance work, Adobe’s continued work on making the web awesome with CSS Shapes and other graphics and layout work, Samsung’s investment in mobile functionality, and more.

We also built the Chromium Feature Dashboard, a tool for staying up-to-date on Blink’s web API surface. It’s currently tracking implementation of 168 web platform features and anonymous usage statistics for 295 JavaScript APIs & HTML tags and 428 CSS properties. We use these usage statistics to see which features can be safely deprecated. In the offline world, last September we held our first bi-annual contributors’ conference with over 160 participants from 10+ organizations.

On the technical side, code size and complexity remains an ongoing challenge for Blink. Code complexity slows development and leads to bugs. Fortunately, we’ve been able to aggressively remove and simplify our code because Blink’s only supported port is Chromium. In aggregate, nearly half the codebase has been eliminated since work on Blink began last year. Notable simplification efforts include unifying CSS and SVG animations with the Web Animations engine, replacement of our WebIDL compiler, factoring of a blink_platform layer out of core code, and continued work on a C++ garbage collector.

2014 promises an even greater increase in mobile computing, thus we continue to focus Blink’s efforts there. Software performance is critical on mobile devices because of constrained hardware and high user expectations. To improve mobile web performance, we have projects to speed up rendering, minimize binary size, reduce input latency, preserve battery power, shrink memory consumption, and more.

We’ve seen some results already. For example, the tight relationship between Blink and Chromium has allowed us to improve the abstraction layer between Blink and Chromium’s compositor. We’re now much more careful to do work for Blink only just before Chrome draws to the screen, avoiding wasting CPU cycles generating results that will overwritten before the next frame is drawn anyway. Through tighter integration, we’ve also achieved 50% savings in compositing updates that change only CSS transforms. This is just the beginning of our performance work; we expect even further improvements from newer efforts like GPU rasterization and better scheduling.

As we enter our second year, we plan to continue to improve Blink on mobile devices, grow our community, and fight the good fight against complexity creep. Join us or follow along to stay in touch!

Posted by Eric Seidel, Software Engineer and Code Complexity Curtailer