Big news: Chrome Frame is now stable and out of beta!

Today, we’re very happy to take the Beta tag off of Google Chrome Frame and promote it to the Stable channel. This stable channel release provides our most polished version of Google Chrome Frame to date, allowing users to access modern web technologies like HTML5 on legacy browsers. You now can download the stable version of Google Chrome Frame and users of the Beta will be automatically updated to it in the days ahead. If you’re an IT administrator, we’ve also posted an MSI installer for deploying Google Chrome Frame in your network.

Chrome Frame is now much faster and stable. It's extremely simple to have a site use Chrome Frame:

For the next step the Chrome Frame team is focusing on making start-up speed even faster and removing the need for administrator rights when installing the plug-in.

Congrats to the Chrome Frame team!

[Disclosure: Alex Russell, the chipper-looking fellow in the video, and I have worked together at Google and on Dojo before.]

First, he uncovers new support for the EventSource API that allows for simple server push of DOM events as shown in this simple client and server pairing:

Then, he finds out that the Web Worker API now supports complex messages, so you can postMessage more than Strings. Send over objects and Arrays with ease:

The Chrome Web Store was shown off at the Google I/O keynote (streaming live) today along with the other great news of open codecs, great new tools, and more.

I found myself torn about this one. For one, it seems tied into Chrome itself. The problem that Sundar stated (developers needing a good channel; users having a hard time finding things) is valid for the entire Web. We don't need a Firefox Web Store, IE Web Store, etc etc etc. We have an opportunity to do better here.

That being said, it was great to see the early stages here and how they give developers the ability to place your Web application in to an experience where you can put a price tag on top.

I would love to get details here. How do you package the application? Do you have to upload the package to the store?

I wonder if there is room for a distributed system that allows me to put a price tag on my web application, but keep it at my URL.

What do you think? There is a session on the store... so I look forward to the deets!

Web Sockets

First up, we have Web Socket support being turned on by default on the developer channel. If you want to be a really cool JS h4x0r you should write a server app using node.js. If you want it to work on older browsers, try out the old favourite shim tale of use Flash to degrade, and Mozilla support should be coming soon and surely IE9 will support it too ;)

Now you can code like this:

Chrome Extensions Beta

Although I curse at the weak support on Chrome Mac (coming by end of week though!), other Chromers can use the new beta extension system pioneered by the awesome Aaron Boodman and team:

Today, we're really happy to release a beta of extensions that begins to deliver on our initial vision. Extensions are as easy to create as webpages. Users can install and uninstall them quickly without restart, and extensions have a great polished look that fits in with Google Chrome's minimalist aesthetic. When developers upload an extension it is available to users immediately, with limited restrictions and manual reviews only in a few situations.

On the technical side, we've been able to use Google Chrome's multiprocess architecture to help keep extensions stable and safe. And Chromium's extensive performance monitoring infrastructure has helped us ensure extensions affect Google Chrome's speed as little as possible. You can learn more details about the internals of our system in the videos below.

I am excited about the new extension systems of Chrome and Jetpack, and wrote up thoughts on how we are jumping out of the page and into the runtime as Web developers.

rel="noreferrer" and target="_blank"

I missed the fact that in Chrome you can opt-in to a new process from a link. This is important as every tab is NOT necessarily in its own process. People assume that is the case (a one to one mapping) but it isn't (and has interesting security implications):

In many cases, though, Google Chrome needs to keep pages from related tabs in the same process, since they may access each other's contents using JavaScript code. For example, clicking links that open in a new window will generally cause the new and old pages to share a process.

In practice, web developers may find situations where they would like links to other pages to open in a separate process. As one example, links from messages in your webmail client would be nice to isolate from the webmail client itself. This is easy to achieve now, thanks to new support in WebKit for HTML5's "noreferrer" link relation.

To cause a link to open in a separate process from your web page, just add rel="noreferrer" and target="_blank" as attributes to the tag, and then point it at a URL on a different domain name. For example:

He nicely aggregates a lot of the info that has been seen on Chrome Frame into one place, and his series covers:

• Basics of Chrome Frame: what is it?
• Supporting Chrome Frame: <meta http-equiv="X-UA-Compatible" content="chrome=1"> and the like
• Detecting Chrome Frame: Using CFInstall and the like
• Forcing Chrome Frame: How to hack the registry and using cf:

Darrel Karisch has posted on just that, with his CSS Scripting Layout:

This document describes a new set of CSS properties and object specifications that together compose a powerful declarative means to describe complex arbitrary layout criteria that are both reusable and extensible. The new properties are Javascript expressions that are woven together in a constraint resolving system to perform a specified layout. Additionally, a set of global objects defined in the constraint resolution Javascript execution environment enable powerful operations to be expressed succinctly resulting in more readable and compact layout specifications.

An prototype implementation has been coded as a Chrome extension, and to get this:

you code CSS like this:

Huh. What do you think?

Google is getting into the operating system business (again) with Google Chrome OS. Palm put WebKit at the heart of a device with webOS, the Crunchpad talked about it for the netbook, and there have long been desktop-boot-to-browser devices out there.

Google Chrome OS goes deeper:

Google Chrome OS is an open source, lightweight operating system that will initially be targeted at netbooks. Later this year we will open-source its code, and netbooks running Google Chrome OS will be available for consumers in the second half of 2010. Because we're already talking to partners about the project, and we'll soon be working with the open source community, we wanted to share our vision now so everyone understands what we are trying to achieve.

Speed, simplicity and security are the key aspects of Google Chrome OS. We're designing the OS to be fast and lightweight, to start up and get you onto the web in a few seconds. The user interface is minimal to stay out of your way, and most of the user experience takes place on the web. And as we did for the Google Chrome browser, we are going back to the basics and completely redesigning the underlying security architecture of the OS so that users don't have to deal with viruses, malware and security updates. It should just work.

Google Chrome OS will run on both x86 as well as ARM chips and we are working with multiple OEMs to bring a number of netbooks to market next year. The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies. And of course, these apps will run not only on Google Chrome OS, but on any standards-based browser on Windows, Mac and Linux thereby giving developers the largest user base of any platform.

It is interesting that Google pre-announced this so far in advance. Google is very different from other companies, that normally hold back for a release. They instead come out and tell you what they are doing (sometimes) and promise to open source it :)

This is great news for Web developers of course. The Web as a platform continues to push outwards, and we can use our skills to reach more and more folks out there.

There is a reason that we won't see the fruit of this labour for awhile though, and that is because there is a ton of work to be done. I am excited to see us all come together to push the Open Web platform further and get to a point where it can do everything we need to create compelling user experiences!

Some will say that Android and Chrome OS are totally different beasts, but Jim Pick does have a point:

Google now has two competing open source in-house Linux-based operating systems with Webkit browsers. This won't end well.

Competition baybee.

He has quickly reported back and is happy with the results.

Something like this:

will give you errors such as:

Invalid value for parameter 0. Property windowId: expected integer, got string.

It will be interesting to see how the APIs look when you go for this style throughout. Looking forward to see more.

This is how you will probably create a new tab using the Chrome extensions API when it comes out.

Aaron Boodman talked about the choice and how they are looking to make the APIs look more like this:

I'm using the CRUD pattern as a starting point for all the major sub-systems' APIs. My hope is that this will have a number of positive effects:

• Minimize API design hand-wringing
• Provide a large base of functionality quickly
• Make it easy for Chromium developers to add new APIs
• Make it easy for extension developers to learn new APIs

I got this all working for a few methods, and then I got to writing the validation code. I could write the code by hand, but that's so much work. And why bother when somebody has gone and invented JSON Schema.

That's right, it's a schema language for JSON. And of course it has a schema, written in JSON schema. Whee!

So we should be able to just declare the expected structure for our API parameters and push the validate() button. Probably there will have to be extra stuff around the edges, but this should get rid of a majority of the grunt work.

I have found that I favor this approach a lot, and you see the same in libraries such as Prototype (Ruby does a lot of this hash munging too). I wish we could just get named parameters in the language so this all just integrated very nicely indeed. What do you think?

You create a JSON manifest in your extension directory, tell Chrome about it via --enable-extensions --load-extension="c:\myextension" (only required while extensions are in dev mode) and then you can navigate to chrome-extension://00123456789ABCDEF0123456789ABCDEF0123456/hello_world.html assuming the manifest of:

Aaron's work wouldn't be complete with some notion of userscripts, and the document discusses that:

Finally, NPAPI plugins are supported for the binary side of the house, and you just need to point to the location of that code via "plugins_dir": "plugins".

There are also more resources:

• API Pattern
• Manifest details
• Todo list example
• Userscripts

Not your mothers JavaScript

The Chrome team has also launched a new website to showcase interesting web app examples and samples.

Calling it openwebexperiments or something, and being a bit more inclusive would have been nice (since these all seem to work fine in Safari, Firefox, etc ..... but the idea is good!

Chromium extensions will follow a multi-process architecture to share the same kind of stability and security that regular web pages have in Chromium. All of an extension's code runs in a single process, separate from the browser (with the exception of user scripts which run in whichever renderers they apply to). Extension code can communicate with user scripts, and vice versa, through a message passing API.

The document discusses an example extension and the "chrome scripts" that pull off the work:

Much like with user scripts, an extension can register "chrome scripts" to run in the context of the extension process. These scripts have special access to the browser UI, and can communicate with extension UI and user scripts. Chrome scripts are loaded and run when the extension is loaded (generally on browser startup). They can register to listen for special events, like tab switching, window closing, navigation, etc.

As an example, consider an Auto-Link extension that shows a button on the toolbar which converts all addresses on the page to links to Google Maps. Maybe the button is disabled when there are no addresses on the page. This extension would consist of:

1. a user script which detects addresses and has the ability to convert addresses to links
2. a toolstrip containing the HTML, CSS, and script necessary to draw the button
3. a chrome script that listens for browser events and controls the state of the toolbar button

manifest.json (snippet):

PLAIN TEXT

JAVASCRIPT:

1.  
2.     ...
3.     // these two are loaded into the extension process
4.     chrome_scripts: ["chrome/main.js"],
5.     toolstrip: "chrome/toolstrip.html",
6.     // this is loaded into renderers
7.     user_scripts: {
8.       "matches": ["http://*/*", "https://*/*"],
9.     "files": ["content/address.js"]
10.     },
11.     ...
12.  

content/address.js:

PLAIN TEXT

JAVASCRIPT:

1.  
2. extension.addEventListener("on-message", function (e) {
3.   if (e.message == "autolink") {
4.     doAutoLink();
5.   } else if (e.message == "check-for-addresses") {
6.     var found = checkForAddresses();  // implemented elsewhere
7.     e.channel.postMessage({hasAddresses: found});
8.   }
9. }, false);
10.  

chrome/main.js:

PLAIN TEXT

JAVASCRIPT:

1.  
2.     extension.addEventListener("tab-changed", function (e) {
3.       // user switched tabs, so check if our button should be enabled
4.       e.tab.postMessage("check-for-addresses");
5.     }, false);
6.  
7.  
8.     extension.addEventListener("on-message", function (e) {
9.       // we got a response from our user script
10.       var found = e.message["hasAddresses"];
11.       var toolstrip = e.tab.browserWindow.getToolstrip("autolink");
12.       toolstrip.contentWindow.document.getElementById("autolink").disabled = !found;
13.     }, false);
14.  

chrome/toolstrip.html:

PLAIN TEXT

HTML:

1.  
2. <html>
3. <body>
4.   <button onclick="autolink()" id="autolink">Auto-Link</button>
5.   <script>
6.     function autolink() {
7.       extension.currentTab.postMessage("autolink");
8.     }
9.   </script>
10. </body>
11. </html>
12.  

It is also well known that SunSpider tests Regexp that isn't targeted to what is actually done on the Web. The V8 benchmark has updated tests that aim to do a better job here. Being Google, they also have this index laying around, so they took advantage of that to test against popular webpages:

During development we have tested Irregexp against one million of the most popular webpages to ensure that the new implementation stays compatible with our previous implementation and the web. We have also used this data to create a new benchmark which is included in version 3 of the V8 Benchmark Suite. We feel this is a good reflection of what is found on the web.

I would love to see this available for other browsers to test on :)

And now, here are the details on the changes:

While the V8 team has been working hard to improve JavaScript performance, one part of the language that we have so far not given much attention is regexps. Our previous implementation was based on the widely used PCRE library developed by Philip Hazel at the University of Cambridge. The version we used, known as JSCRE, was adapted and improved by the WebKit project for use with JavaScript. Using JSCRE gave us a regular expression implementation that was compatible with industry standards and has served us well. However, as we've improved other parts of the language, regexps started to stand out as being slower than the rest. We felt it should be possible to improve performance by integrating with our existing infrastructure rather than using an external library. The SquirrelFish team is following a similar approach with their JavaScript engine.

A fundamental decision we made early in the design of Irregexp was that we would be willing to spend extra time compiling a regular expression if that would make running it faster. During compilation Irregexp first converts a regexp into an intermediate automaton representation. This is in many ways the "natural" and most accessible representation and makes it much easier to analyze and optimize the regexp. For instance, when compiling /Sun|Mon/ the automaton representation lets us recognize that both alternatives have an 'n' as their third character. We can quickly scan the input until we find an 'n' and then start to match the regexp two characters earlier. Irregexp looks up to four characters ahead and matches up to four characters at a time.

After optimization we generate native machine code which uses backtracking to try different alternatives. Backtracking can be time-consuming so we use optimizations to avoid as much of it as we can. There are techniques to avoid backtracking altogether but the nature of regexps in JavaScript makes it difficult to apply them in our case, though it is something we may implement in the future.

Chromium can't be everything to all people. People use web browsers in a variety of environments and for a wide variety of jobs. Personal tastes and needs vary widely from one user to the next. The feature needs of one person often conflict directly with those of another. Further, one of the design goals of Chromium is to have a minimal light-weight user interface, which itself conflicts with adding lots of features.

User-created extensions have been proposed to solve these problems:

• The addition of features that have specific or limited appeal ("that would be great as an extension").
• Users coming from other browsers who are used to certain extensions that they can't live without.
• Bundling partners who would like to add features to Chromium specific to their bundle.

They then define the goals:

An extension system for Chromium should be:

• Webby

• Developing and using extensions should be very similar to developing and using web pages.
• We should reuse the web platform wherever possible instead of creating new proprietary APIs.
• Web developers should be able to easily create Chromium extensions.
• Installing and using an extension should feel lightweight and simple, like using a web app.

Rich

• It should be possible to create extensions as polished as if they had been developed by the Chromium team.
• Eventually, it should be possible to implement major chunks of Chromium itself as extensions.

General

• There should be only one extension system in Chromium that handles all types of extensibility.
• Infrastructure like autoupdate, packaging, and security should be shared.
• Even traditional NPAPI plugins should be deployable as extensions.

Maintainable

• The system should require low ongoing maintenance from the Chromium team, and minimize potential for forward compatibility issues.
• We should not need to disable deployed extensions when we release new versions of Chromium. 

Stable

• Extensions should not be able to crash or hang the browser process.
• Chromium should assign blame to extensions that are overusing resources via tools like the task manager and web inspector.
• Poorly behaving extensions should be easy to disable.

Secure

• It must not be possible for third-party code to get access to privileged APIs because of the extension system.
• Extensions should be given only the privileges they require, not everything by default.
• Extensions should run in sandboxed processes so that if they are compromised, they can't access the local machine.
• It should be trivial for authors to support secure autoupdates for extensions.
• We must be able to blacklist extensions across all Chromium installations.

Open

• Extension development must not require use of any Google products or services.
• Extensions should work the same in Chromium as in Google Chrome.

As the new kid on the block, they get to learn from the good and bad of other add on systems (IE, Firefox, etc). What would you like to see? I love the idea of being able to do as much as possible by using the Web platform as it is, and doing things like adding some new APIs, but also additions to CSS and the like versus a new system.

I would also love to see the Chromium folks working with others to start sharing some work here. For example, it would be great to have the vbox/hbox work shared. David Hyatt did a lot of work there back in the day with WebKit already.

Graphics in Google Chrome

Google Chrome uses a library called Skia, which is also the graphics engine behind Google's Android mobile OS. The two projects share code that implements WebKit's porting API in terms of Skia. Google Chrome also uses Skia to render parts of the user interface such as the toolbar and tab strip. I'm going to talk about some of the history that led us to choose Skia, as well as how our graphics layer works.

I/O in Google Chrome

We moved the I/O onto a number of background threads which allow the user-interface to proceed asynchronously. We did this for large data sources like cookies, bookmarks, and the cache, and also for a myriad of smaller things. Writing a downloaded file to disk, or getting the icons for files in the download manager? The disk operations are being called from a special background thread. Indexing the contents of pages in history or saving a login password? All from background threads. Even the "Save As" dialog box is run from another thread because it can momentarily hang the application while it populates.

Content, not 'Chrome'

To achieve the streamlined feel we were after, we knew we would have to cut some things, and while we had our own intuitions about what was and wasn't useful in current browsers, we had no idea how those ideas matched to reality. So in typical Google fashion, we turned to data; we ran long studies of the browsing habits of thousands of volunteers, compiled giant charts of what features people did and didn't use, argued over and incorporated that data into our designs and prototypes, ran experiments, watched how our test users reacted, listened to their feedback, and then repeated the cycle over and over and over again.

Even the the more subtle parts of our first-level UI were subjected to similarly intense scrutiny - "what shade of blue best suits XP users", "should the tabs start 18 or 19 pixels below the top of the window?", "what's the correct offset between our buttons?". The answers to these questions were debated and tested for our entire development cycle, and we saw that opinions consistently differed greatly depending on whether we had been Windows 3.1, OS7 or even NeXT users and developers.

The Google Chrome Sandbox

Google Chrome's multi process architecture allows for a lot of flexibility in the way we do security. The entire HTML rendering and JavaScript execution is isolated to its own class of processes; the renderers. These are the ones that live in the sandbox. We expect to work in the near future with the plug-in vendors to securely sandbox them as well.

I have to admit that I personally wish Cairo was chosen, as having the Google engineers behind that project would have been amazing, and benefit would be had for all of the applications that use it.

An SVN watcher found a checkin that relates to Greasemonkey-like support:

Adds a bit of Greasemonkey support hidden behind the --enable-greasemonkey flag.
Implementation follows the pattern of the visited links system.

Things still to be done:

• stop using a hardcoded script directory
• watch script directory and update shared memory when necessary
• move file io to background thread
• support for @include patterns -- now, all scripts are applied to all pages

Committed

It will be interesting to see the level of support for the various APIs, but in general it is fantastic that we have user scripts available in different forms, across browsers. What other platform has that kind of flexibility available to its users?

Chromium gained an important patch over the weekend, with the introduction of Greasemonkey support. The patch came from none other than Aaron Boodman, creator of the original Firefox add-on, and also a Google employee.

For now, it's just a patch and it's not yet clear if and when it will be part of the official Chrome release. As GHacks explains:

Since there is no way of adding extensions to Chrome yet users have to live with some limitations. Only scripts in c:\scripts are loaded and only if the user adds the parameter –enable-greasemonkey by appending it to the program’s shortcut.

The Firefox Greasemonkey extension has been a huge success, and spawned an entire ecosystem of scripts, developers, and users in its own right. Its ultra simplicity has made it immeasurably easier for enthusiasts to "scratch their own back" and patch up a troublesome website in a matter of minutes. It's not hard to see how the pure Javasript approach could be extended to form a more comprehensive extension platform. It will be interesting to see if, as I speculated on my blog today, this patch is to be the seed for Google's overall approach to Chrome extensions.

In any event, the Chrome space has a lot of user-scripting innovations to look forward to in coming months. And I daresay the odd porting effort too.