Soon after the V8 project started we also began work on what would become the Sputnik tests. The goal was to create a test suite based directly on the language spec that checked the behavior of every object, function and individual algorithm in the language. The task was given to a team in Russia – hence the name "Sputnik" – which went about systematically producing tests. As the test suite grew we used it to ensure that V8 conformed to the spec and to detect unexpected changes in our behavior.
Now that the test suite is complete we're happy to be able to release it as an open source project, under the BSD license. We hope Sputnik can be as useful to other implementers of JavaScript as it has been to us, particularly at a time where implementations change rapidly.
The goal is not that all implementations should pass all tests. V8 set out with that intention and we learned the hard way that sometimes you have to be incompatible with the spec to be compatible with the web. Rather, we want Sputnik to be a tool for identifying differences between implementations.
One of the biggest challenges for web developers today is the many incompatibilities between browsers. Finding these differences is the first step towards removing them. In an ideal world web developers would not have to worry about which browser is being used to view their site and users would not have to worry about whether a site supported their browser. We hope the Sputnik tests will make the browser community take another step towards making that a reality.
Posted by Christian Plesner Hansen, Software Engineer
You can invoke new developer tools by selecting "JavaScript console" from the Developer menu (or using Ctrl+Shift+J). For example, running the statistical profiler on the V8 benchmark suite (below screenshot) will give exact information on the actual code execution as the data is generated straight from running the optimized code from V8.
As with the rest of Google Chrome, the developer tools are open source and built upon WebKit and in particular WebKit's Inspector. We would love to get feedback - both in terms of bugs reports and feature requests - on the Chromium public issue tracker. Or even better yet, we would love to get contributions to improving developer tools further in WebKit and Google Chrome.
First of all, we've set up a new discussion group for extension-related topics. Going forward, chromium-extensions will be your one-stop shop for extension development news, feedback and questions. If you're interested in developing extensions, we invite you to join us at chromium-extensions.
Second, as part of the latest dev channel release, we've had to make a breaking change to the crx format. This change adds signatures to our package format, which are necessary to enable automatic updates. Unfortunately, this means that any existing extensions will stop working, and will have to be repackaged.
If you've developed an extension, you can learn how to repackage your extensions for Chrome v 3.0.189.0 in the packaging doc on our developer site. Note that your extension ID will now be your public key, so you'll have to change any code that uses that.
If you're using an extension someone else has developed, you will have to reinstall it once the developer has repackaged it (as described above). We've already updated our sample extensions.
Even though the whole point of the dev channel is to make our APIs available early while they're still changing, we don't make these changes lightly. Once we push the extension system to the stable channel, breaking changes should be very rare (we'd like to say non-existent, but we don't want to jinx ourselves).
Open source projects aren't simply about a runnable binary, they're about the community of users, testers, and developers who devote their time and skills to working on a product they believe in. They go hand in hand: there's no binary without the community and there's no community without the binary. At some point in the life-cycle of a project, you have to stop thinking solely about your small band of developers and start growing the larger supporting community that will become your users, testers, localizers, documentation writers, and possibly even new coders.
In "The Cathedral and the Bazaar", Eric Raymond writes:
"When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the foreseeable future."
We in the Chromium project feel like our Mac and Linux builds are at this stage, if not beyond it. They run pretty well and demonstrate the fundamental architecture that sets Chromium apart from other browsers. Sure, the bells and whistles aren't all there, but the core functionality of web browsing is. We feel that we've delivered on ESR's "plausible promise" and that it's enough to start attracting those who really want to help make this the best product it can be. We're not done yet, nor is it ready for the average user. It is, however, ready for those who want to live on the bleeding edge and help lend their talents towards completing it.
The community we build today is what will make it a better product down the road, and without that community the product will ultimately suffer. ESR describes testers as "a project's most valuable resource" and my first-hand experience with Camino and Mozilla bear this out. A web browser is a program that accepts an infinite number of inputs and having people who can test webpages the developers wouldn't normally encounter is a tremendous aid. Testing on diverse hardware and software setups is also invaluable as developers tend to only run the latest and greatest (and fastest!). Eventually we might uncover many of these issues on our own, but probably not.
Another pillar of open source, along with releasing early, is releasing often. To that end, the dev channel will automatically receive weekly updates as development continues. You will be able to see the product improving from week to week and help immediately identify when things break. Getting feedback on new features as soon as they are completed helps the developers know if they hit the mark and helps close the feedback loop with the community. The community benefits by being more involved and connected and promoting further transparency in the development process. This wouldn't be possible if we only teased users with releases at widely-spaced intervals when most decisions had been set in stone (end-users who want that can use the beta or release channels).
To answer these questions, it's helpful to know how Google Chrome releases are made, the relationship between "dev," "beta," and "stable" update channels, and how you can test new versions. In this post, we'll be expanding on Mark Larson's earlier explanation of the update channel system.
Stable channel. As Mark outlines, the Stable channel is, well, stable. As a web developer, that means that as long as the major version — the "2" in "version 2.0.181.1" — doesn't change, you can count on Stable channel builds to use the same versions of WebKit (CSS, layout, etc.), V8 (JavaScript), and other components that might affect how a page loads or renders. Stable updates between major version releases are generally focused on addressing security issues, fixing egregious bugs, and improving stability. The big developer-facing bits of the browser won't change on the Stable channel until the next major version is released, and you can always preview upcoming changes using the Beta channel.
Beta channel. As a web developer, being on the Beta channel will ensure that you can test your sites with the next version of Google Chrome's rendering behavior before it's sent to the Stable channel and into the hands of most users. Whenever a major version lands in the Beta channel, the versions of WebKit, V8, networking, and the other systems that affect how web pages load and render generally become fixed. These versions may change during the major version's beta cycle, but changes are usually incremental fixes to help stabilize a feature rather than changes in behavior. New versions of WebKit may be introduced during a beta period, but those versions are always accompanied by a new build number (e.g. 2.0.169.xx vs. 2.0.172.xx) and are unlikely to differ drastically. As this major version moves closer to a stable release, these kinds of changes become more and more infrequent. Since Google Chrome development moves so quickly, you should stay on the Beta channel to catch compatibility issues ahead of time.
Dev channel. The Dev channel is where the sausage gets made. Dev releases happen frequently, and they track what's happening upstream in WebKit, V8, and other relevant systems very closely. This means that changes that might affect rendering, performance, and layout are likely to occur on the Dev channel on a regular basis. We don't recommend that you install the Dev channel if you're looking to maintain site compatibility, since tracking breaking changes as they happen can be a major headache. You should be able to spot any problems early enough via the Beta channel.
Users are on the Stable channel by default. To get onto the Beta or Dev channel, follow these instructions. Once you change to a less stable channel, e.g. from Stable to Dev, there isn't a supported "downgrade" path. If you change from the less stable channel back to a more stable one, Google Chrome will simply stop updating until your new channel "catches up" with the installed build. To force an immediate downgrade, uninstall and reinstall using an appropriate installer. This may occasionally cause errors when your more stable (older) version tries to read the newer user data left over from the previous installation.
Once you have a copy of Google Chrome, you can test your site's compatibility. Google Doctype has a helpful FAQ on best practices for Google Chrome compatibility. In short, prefer object detection over userAgent string parsing; don't rely on pixel-accurate font and element sizes; declare your pages' encodings correctly; double check <object> and <embed> parameters; check for illegal markup; and avoid browser-specific CSS.
The Chromium and WebKit teams work hard to ensure compatibility with websites. If after reading the above you discover browser problems, please don't hesitate to file a bug. If a particular problem with your site occurs in both Google Chrome and a corresponding version of Safari, it may be due to a WebKit issue, which you can file in the WebKit bug tracker. If the problem only happens in Google Chrome, log an issue in the Chromium bug tracker.
Starting a sandbox involves a single call to sandbox_init() specifying which resources to block for a specific process. In our case we lock down the process pretty tightly. That means no network access, and very limited or no access to files and Mach ports.
When Chromium starts a renderer process, we open an IPC channel (a UNIX socketpair) back to the browser process before turning on the sandbox. Any resources a process owns before turning on the sandbox stay with the process, so this channel can still be used after the sandbox is enabled. When we want to pass a shared memory area between processes, we send it over as an mmaped file handle using the sendmsg() API. We don't need to do anything else, as Apple's sandbox API is smart enough to allow access to file descriptors passed between processes in this manner even if the receiving process itself is forbidden from calling open().
One sticky point we run into is that the sandboxed process calls through to OS X system APIs. There is no documentation available about which privileges each API needs, such as whether they need access to on-disk files, or call other APIs to which the sandbox restricts access. Our approach to date has been to "warm up" any problematic API calls before turning the sandbox on. This means that we call through to the API, to allow it to cache whatever resource it needs. For example, color profiles and shared libraries can be loaded from disk before we "lock down" the process. To get a more complete understanding of our use of the sandbox in OSX, you can read the OSX sandboxing design doc.
As we continue the porting efforts for Chromium on the Mac, it's very satisfying to see the puzzle pieces fit into place alongside the native system APIs. It's important to us that the Mac port of Chromium feels and performs like a native Mac application, and that it provides the kind of high-quality experience Mac users expect.
