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 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.
CSS is great for styling, but can be agonizing for laying out applications. There have been attempts to do JavaScript powered layout, but what about adding more semantics to CSS itself?
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.
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!
When Aaron talked about the Chrome extension API he mentioned how he would see if JSON Schema could help them have a JSON heavy API and allow them to easily validate.
He has quickly reported back and is happy with the results.
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:
"description": "The first extension that I made.",
"content_scripts": [
{
"matches": ["http://www.google.com/*"],
"js": ["foo.js"]
}
]
}
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".
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:
a user script which detects addresses and has the ability to convert addresses to links
a toolstrip containing the HTML, CSS, and script necessary to draw the button
a chrome script that listens for browser events and controls the state of the toolbar button
We are seeing great work with faster JavaScript, but what about faster DOM? Or faster CSS? Or faster libraries? Or faster Regexp? Well, members of the Chrome team have announced irregexp, a faster Regexp engine for Chrome. They go into detail on what they had, what they did, and why they did it.
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.
Aaron Boodman posted about the new design document that discusses what the extension system should look like in Chromium and thus Google Chrome:
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.
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.
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.
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.
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.
One of the beautiful elements of having the Chromium project, is that we get a look ahead of what may be shipping in Google Chrome itself, in the same way that WebKit gives us a hint at Safari.Next.
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.
