The main goal of the Chromium project has always been to help unlock the potential of the open web.  We work closely with the industry to standardize, implement and evangelize web technologies that help enable completely new types of experiences, and push the leading edge of the web platform forward.

But in 2009, many people were using browsers that lagged behind the leading edge. In order to reach the broadest base of users, developers often had to either build multiple versions of their applications or not use the new capabilities at all. We created Chrome Frame — a secure plug-in that brings a modern engine to old versions of Internet Explorer — to allow developers to bring better experiences to more users, even those who were unable to move to a more capable browser.

Today, most people are using modern browsers that support the majority of the latest web technologies. Better yet, the usage of legacy browsers is declining significantly and newer browsers stay up to date automatically, which means the leading edge has become mainstream.

Given these factors we’ve decided to retire Chrome Frame, and will cease support and updates for the product in January 2014. If you are a developer with an app that points users to Chrome Frame, please prompt visitors to upgrade to a modern browser. You can learn more about these changes in our FAQ.

If you’re an IT administrator you can give your employees the full capabilities of a modern browser today, even if you depend on older technology to run certain web apps. Check out Chrome for Business coupled with Legacy Browser Support, which allows employees to switch seamlessly between Chrome and another browser. Chrome is secure, stable and speedy, and runs on all major desktop and mobile OSs. IT admins can also configure 100+ policies to make Chrome fit their needs.

It’s unusual to build something and hope it eventually makes itself obsolete, but in this case we see the retirement of Chrome Frame as evidence of just how far the web has come.

Posted by Robert Shield, Google Chrome Engineer

Cube Slam is a Chrome Experiment built with WebRTC, an open web technology that lets you communicate in real-time in the browser (and in this case, play an old-school arcade game with your friends) without downloading and installing any plug-ins. In this post, we wanted to explain a bit about how Cube Slam works.

Cube Slam uses getUserMedia to access your webcam and microphone (with your permission, of course), RTCPeerConnection to stream your video to a friend, and RTCDataChannel to transfer the bits that keep the gameplay in sync. If you and your friend are behind firewalls, RTCPeerConnection uses a TURN relay server (hosted on Google Compute Engine) to make the connection. However, when there are no firewalls in the way, the entire game happens directly peer-to-peer, reducing latency for players and server costs for developers.

Cube Slam is the first large-scale application to use RTCDataChannel, which provides an API similar to WebSocket, but sends the data over the RTCPeerConnection peer-to-peer link. RTCDataChannel sends data securely, and supports an "unreliable" mode for cases where you want high performance but don't care about every single packet making it across the network. In cases like games where low delay often matters more than perfect delivery, this ensures that a single stray packet doesn't slow down the whole app.

RTCDataChannel supports unreliable mode in desktop Chrome today. We're working on implementing the latest WebRTC spec, where we'll use the standard SCTP protocol to support reliable mode as well. WebRTC will also be available on Chrome for Android later this year, and you can try it now by flipping “Enable WebRTC Android” in chrome://flags. Several browsers are currently working on implementing WebRTC, and we’re looking forward to the day when you can have a Cube Slam face-off against your friends on any browser and any device.

To learn more about the tech in Cube Slam, you can check out our technology page and source code. Disable the shields! Destroy the screen! Have fun!

Posted by Justin Uberti, Software Engineer and Channeler of Data

You may have seen our recent demo of Racer at Google I/O, and wondered how it was made. So today we wanted to share some of the web technologies that made this Chrome Experiment “street-legal” in a couple of months. Racer was built to show what’s possible on today’s mobile devices using an entirely in-browser experience. The goal was to create a touch-enabled experience that plays out across multiple screens (and speakers). Because it was built for the web, it doesn’t matter if you have a phone or a tablet running Android or iOS, everyone can jump right in and play.

   

Racer required two things: speedy pings and a consistent experience across screens. We delivered our minimal 2D vector drawings to each device’s HTML5 Canvas using the Paper.js vector library. Paper.js can handle the path math for our custom race track shapes without getting lapped. To eke out all the frame rate possible on such a large array of devices we rendered the cars as image sprites on a DOM layer above the Canvas, while positioning and rotating them using CSS3’s transform: matrix().

Racer’s sound experience is shared across multiple devices using the Web Audio API (available in latest iOS and Android M28 beta). Each device plays one slice of Giorgio Moroder’s symphony of sound—requiring five devices at once to hear his full composition. A constant ping from the server helps synchronize all device speakers allowing them to bump to one solid beat. Not only is the soundtrack divided across devices, it also reacts to each driver’s movements in real time—the accelerating, coasting, careening, and colliding rebalances the presence of every instrument.

To sync your phones or tablets, we use WebSockets, which enables rapid two-way communication between devices via a central server. WebSocket technology is just the start of what multi-device apps of the future might use. We’re looking forward to when WebRTC data channels—the next generation of speedy Web communication—is supported in the stable channel of Chrome for mobile. Then we’ll be able to deliver experiences like Racer with even lower ping times and without bouncing messages via a central server. Racer’s backend was built on the Google Cloud Platform using the same structure and web tools as another recent Chrome Experiment, Roll It.

To get an even more detailed peek under the hood, we just published two new case studies on our HTML5 Rocks site. Our friends at Plan8 wrote one about the sound engineering and Active Theory wrote one about the front-end build. You can also join the team at Active Theory for a Google Developers Live event this Thursday, June 13, 2013 at 3pm GMT for an in depth discussion.

Posted by Pete “Spinout“ LePage, Developer Advocate

Last week we launched Roll It, a Chrome Experiment that links phones to computers and gets people out of their chairs and swinging. We wanted to share how we built a physical game experience with no dedicated hardware. It requires just the web, your computer and a phone.

Here’s a look at the APIs and browser-based features we used to create it.

Roll It is a three-dimensional (3D) experience, from the swing of your phone’s accelerometer right up to the virtual models rendered on your computer’s HTML5 Canvas. On the phone side, we hooked into browser events like DeviceOrientation and DeviceMotion to detect the speed and direction of a swing. On the computer side we rendered our scene using Three.js and plugged in Physijs to add physics to the ball and environment.

To sync the phone to the computer we employed WebSockets which enable rapid two-way communication between devices via a central server.

For extra stability we built our backend on Google Cloud Platform:

• Our Google App Engine application, built in Go, dynamically balances users across our relay servers.
• A Google Compute Engine server maintains game state across synced devices.
• Google Cloud Storage speedily serves up the static assets.

We couldn’t have brought this experiment to life without a great team. The theme for Roll It was composed by Mr. Tim Healey. Legwork Studio developed the interfaces and game environment, and teamed up with Mode Set for the development.

To dig deeper into the technology behind Roll It, check out the HTML5 Rocks Case Study, or join the team for a Google Developers Live event this Friday, June 7, 2013 at 5pm GMT for an in-depth discussion.

Posted by Pete LePage, Developer Advocate and Boardwalk King

App notifications send immediate alerts to users about important events as they happen. Chrome and Chrome OS already support basic web notifications, but rich notifications for Chrome packaged apps and extensions can enable users to act directly on these notifications and show rich content like lists and images. For those in beta channel, notifications now live in a center that is outside the browser, which allows them to receive notifications even when the browser is not open. Rich notifications are available in the latest beta channel builds on Windows, dev channel builds on ChromeOS, and will be coming to Mac OS X and Linux soon.

You can trigger a rich notification by calling the create method under the chrome.notifications module:

chrome.notifications.create(  ‘id1’,{         type: ‘basic’,      iconUrl: ‘image1.png’,      title: ‘Althe Frazon’,      message: ‘Lorem ipsum’,      buttons: [{ title: ‘Call’,                  iconUrl: ‘call.png’},                { title: ‘Send Email’,                  iconUrl: ‘email.png’}],      priority: 0},  function() { /* Error checking goes here */} );

Rich notifications include full-bleed icons and space to convey a headline and short message. Additionally, they enable you to create action buttons and respond to clicks right within your app, empowering your users to do anything they could do within the app’s UI itself.

Apart from the basic notification type shown above, you can use other formats like image to show a preview of an image within the notification or list to coalesce multiple notifications from your app into a single one. For example, a mail app could show multiple unread emails within a single notification using the list type. You can also specify different priorities for notifications that determine how long they stay on the screen before moving into the notification center where they continue to live until dismissed by the app or user.  The notification center holds all current notifications and can be pulled up at any time from the launcher on ChromeOS or the system tray on Windows. Users can view and clear all of their notifications in the center, and also access settings to control which apps, extensions and websites can send them notifications.  Notification Center on Windows   Notification Center on ChromeOS You can get started with rich notifications in your app or extension by trying out the Notify Test App and taking a look at the documentation on the Chrome developer site. We’d love your feedback so feel free to ask a question on Stack Overflow, start a discussion on our mailing list, or file a bug on our issue tracker. Posted by Justin DeWitt, Software Engineer and Notifications Knight

Today’s Beta channel release introduces several new developer features and a major under-the-hood performance improvement. Unless otherwise noted, changes apply to desktop versions of Chrome and Chrome for Android. We’ll be rolling out the update over the next few hours.

Fullscreen API on Chrome for Android

The Fullscreen API on Chrome for Android allows you to programmatically hide the browser UI and OS status bar. Just like on desktop, you can tell any piece of content to enter fullscreen mode by calling its webkitRequestFullScreen() function. The prefixed version will eventually be replaced by requestFullscreen(). Here you can see the Fullscreen API used in a zombie-inspired Chrome Experiment:

Faster page loads

Starting in today’s Beta, your apps get a free speed boost from Blink’s new threaded HTML parser. It has two under-the-hood performance benefits: (1) reduced jankiness by moving work off the main JavaScript thread, and (2) improved page loading speed through pipelining. Compared to the normal HTML parser, it loads DOM content about 10% faster and reduces the maximum stop time due to parsing by 40%.

Experimental new media features in Chrome for Android

In today's Beta, WebGL joins Web Audio and WebRTC as an option in about:flags in Chrome for Android. Used together or independently, these three features will allow you to create rich, powerful web experiences that work across device form factors. We’re still actively improving the implementations, but we invite you to start experimenting. To see them in action, watch the mobile web demo in the Google I/O 2013 keynote.

Deprecated features

The prefixed version of the Content Security Policy HTTP header is now deprecated, so please use Content-Security-Policy instead of X-WebKit-CSP. The prefixed version will still work for now, but future releases may not support it.

For Chrome Extensions, HTML-based notifications have been deprecated in favor of the new Rich Notifications Chrome API. Extensions developers who are using HTML notifications in their apps or extensions should migrate to the newer Rich Notifications API, as support for the existing createHTMLNotification() feature will stop working in a future release of Chrome.

Other developer features in this release

• You can now use CSS @supports conditional blocks to test whether Chromium supports certain property:value pairs.
• The :unresolved CSS pseudoclass lets you style a Custom Element that hasn’t been registered in the browser yet. Custom Elements are part of Web Components.
• As part of V8's continuing quest to make all JavaScript as fast as possible, recent optimizations have made the asm.js benchmarks more than twice as fast as prior versions of Chrome.
• Chrome Apps and Extensions developers can now use rich notifications to proactively engage with users.

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

For general information about what’s going on in Chromium and Blink, watch the recordings of the fireside chats with the Blink team and the Chrome team at Google I/O 2013.

Posted by Alexandre Elias, Software Engineer and Screen Space Conservationist

AddressSanitizer (ASAN) is a tool for finding memory problems and has been used to find thousands of memory errors in Chromium over the last two years. These kinds of errors will typically lead to heap or data corruption and subsequent crashes in random, unrelated code, which make them quite challenging to find and fix without tools like ASAN. However, ASAN is built using LLVM/Clang and is limited to Mac and Linux builds of Chromium. To address the lack of coverage for Windows-only code, we built SyzyASAN.

SyzyASAN is built on top of the Syzygy toolchain and is an instrumentation-based clone of ASAN for detecting heap errors. It consists of three parts:

• An instrumenter that injects instrumentation into binaries produced by the Microsoft Visual Studio toolchain.
• A run-time library that replaces malloc, free, et al.
• An RPC-based logging server that receives information about detected errors. This lets us get information safely out of sandboxed processes, like Chromium’s renderer.

SyzyASAN operates nearly identically to ASAN, finding errors in the same manner and producing similar reports. SyzyASAN finds some of the hardest-to-locate memory bugs like use-after-free, buffer overruns, and underruns. Focusing on very common memory errors allows SyzyASAN to be relatively efficient.

Although Chrome with SyzyASAN is very usable, the penalties in speed - 4.7x on CPU intensive operations - and memory - a 25% increase plus a fixed 256MB increase in each process - are noticeable so we’ll confine these releases to our Canary channel for now. We’ve been releasing SyzyASAN-instrumented builds to the Windows Canary channel one day each week recently. One day with a little slowdown on the Canary channel gives us plenty of great data. In the last three weeks, we’ve found 150 new bugs in Chromium, several of which could lead to security vulnerabilities.

We’ve put together some instructions for instrumenting your local build and debugging issues. Try it out and help us squash more memory bugs. The Syzygy source code and binaries can be downloaded from our code site, and instructions for how to use it are on our wiki. If you have any questions, suggestions or contributions, feel free to contact syzygy-team@chromium.org. If you’re using Syzygy or SyzyASAN with your project we’d love to hear about it!

Posted by Chris Hamilton, Sanitation Engineer