Chromium Blog: 2009

Tab-Modality and You

Thursday, December 17, 2009

Years ago, I remember watching a webcast of the introduction of the Aqua user interface when Mac OS X Public Beta was first demoed. The part I distinctly remember was realizing the brilliance of sheets. Like many great innovations, they were simple in retrospect and solved a problem you didn't realize you had: the modality problem — the fact that dialog boxes blocked interacting with the whole application even though only one window needed the information that you, as the user, had to provide. I watched in wonder as a save dialog blocked only the one window that needed saving, leaving all the other windows free. Finally, a solution to limit the modality.
Because modality sucks.
Back in 2000, sheets worked well because the smallest unit of user interaction with an application was a window. Soon after, though, things started to change. Web browsers in particular were among the first to start using tabs to put more than one document in a window. This caused a snag. A web page can require modal interaction from the user: picking a file, or supplying a username and password. Yet we don't want to prevent the user from switching to a different tab and continuing to interact with other websites. If the finest-grained modality control we have is per-window, how can we achieve that outcome?
Chromium's current answer comes from combining Cocoa's child window support with sheets to get tab-modal sheets:Google Mac blog. The other thing to note is that right now tab-modal sheets are only used for website authentication. The other sheets we use (for file selection, etc) are currently window-modal; we hope to convert them over soon.
The fate of tab modal sheets, however, isn't certain. A way to enforce tab-modal interaction is certainly needed. But is attaching sheets to the tabs the right way to achieve that goal? At the last WWDC, I talked to some graphic designers who were opposed to the idea. "Reusing sheets in a context that isn't window modality will only confuse the user!" On the other hand, my position is that the concept of modality is the same, and the context is similar enough that users will find that sheets help them understand the modality in which they must interact.
So the story isn't over. Tab-modal sheets are our contribution to the ongoing discussion, an experiment to see what works and what doesn't. Together we can work out the best way to help users interact with their computers.
Posted by Avi Drissman, Software Engineer

Google Chrome Extensions: A quick recap of our first week in beta

Wednesday, December 16, 2009

sign updiscussion groupPosted by Arne Kurrik, Developer Advocate, Google Chrome Extensions

Security in Depth: The Extension System

Tuesday, December 15, 2009

In our earliest discussions about the extension system, we knew we wanted to raise the bar for security, but how can we secure the platform while still letting developers create awesome extensions that have rich interactions with web pages? During our threat analysis, we realized there were two main security concerns: malicious extensions and "benign-but-buggy" extensions.
A malicious extension is an extension written by an ill-intentioned developer. For example, a malicious extension might record your passwords and send them to back to a central server. The tricky part about defending against malicious extensions is that there are privilege separation. Each extension declares the privileges it needs in its content scripts. The background page has the lion's share of the extensions privileges but is isolated from direct contact with web pages. Content scripts can interact directly with web pages but are granted few additional privileges. Of course, isolated world" where they are protected from the page's JavaScript.
Of course, attackers will write malicious extensions and well-intentioned developers will write buggy extensions. The extension system improves security by making it easier for developers to write secure extensions. If you would like to learn more about the security of the extension system, you can read our academic paper describing all the details.
Posted by Adam Barth, Software Engineer

New Tech Talks Posted

Monday, December 14, 2009

I'm excited to announce four new tech talks on the guts of Chromium have been posted to YouTube! These should be especially useful for developers who work on Chromium whether they're fairly new to the project or have been around the block.
We've done tech talks
Because of Chromium's multi-process architecture, painting within Chromium is far from typical. In this talk, Brett Wilson starts from Skia and the WebKit render tree, follows the bits across the process boundaries, and continues all the way to your screen. He also details many of the differences in painting between platforms, how things work in test shell, and interesting corner cases like resizing.
WebKit's Gutswith Eric Seidel

What's the Difference Between Chromium OS and Google Chrome OS?

Friday, December 11, 2009

The last couple of weeks since we open sourced Chromium OS have been pretty exciting. The discussion groups have been buzzing and a number of sites have put up Chromium OS builds for download. While we're happy that developers have been building Chromium OS there are a few things we would like to clarify:

This is not ready for consumers yet — everything you see can and probably will change by the time Google Chrome OS-based devices are available late next year.
Please note that Google has not released an official binary for Chromium OS and therefore if you download Chromium OS binaries please ensure that you trust the site you are downloading them from.
While we will try our best to help you through the Chromium discussion forums, we will not be officially supporting any of these builds. Remember that you are downloading that specific site/developer's build of Chromium OS.

We have also received a number of questions that we wanted to answer directly and so we put together the following FAQ to clarify some of these issues.
One of the top questions has been around the distinction between Google Chrome OS and Chromium OS. Google Chrome OS is to Chromium OS what Google Chrome browser is to Chromium. Chromium OS is the open source project, used primarily by developers, with code that is available for anyone to checkout, modify and build their own version with. Meanwhile, Google Chrome OS is the Google product that OEMs will ship on Netbooks next year. Therefore, dear developers who have built and posted Chromium OS binaries, you're awesome and we appreciate what you are doing, however we have to ask you to call the binaries you've put up for download "Chromium OS" and not "Google Chrome OS".
Thanks!Posted by Martin Bligh, Software Engineer

WebGL Spec Initial Public Draft Released

Thursday, December 10, 2009

Google is one of the Khronos member companies helping to develop the Shiny teapot demo illustrating compositing of 3D graphics with the web page

Chromium-dev mailing list, for more general WebGL questions, use the WebGL public mailing list.

Posted by Ken Russell, Software Engineer

Web Sockets Now Available In Google Chrome

Wednesday, December 9, 2009

Starting in the Google Chrome Chromium.
The pywebsocket, which can be used as an Apache extension module, or can even be run as standalone server.
You can use Google Chrome and pywebsocket to start implementing Web Socket-enabled web applications now. We're more than happy to hear your feedback not only on our implementation, but also on API and/or protocol design. The protocol has not been completely locked down and is still in discussion in IETF, so we are especially grateful for any early adopter feedback.
Posted by Yuzo Fujishima (藤島勇造), Fumitoshi Ukai (鵜飼文敏), and Takeshi Yoshino (吉野剛史), Software Engineers

Extensions beta launched, with over 300 extensions!

Tuesday, December 8, 2009

limited restrictions

form.

Posted by Erik Kay and Aaron Boodman, Software Engineers

Google Chrome for Linux goes beta!

Tuesday, December 8, 2009

simplethanks to Ibrar and Paweł for our FTP stacklet us know what you thinkPosted by Dan Kegel and Evan Martin, Software Engineers

Links That Open in New Processes

Friday, December 4, 2009

We've introduced a new way for web developers to take advantage of Google Chrome's
In this case, Google Chrome knows that the page will be opened in a new window, that no referrer information will be passed to the new page, and that the window.opener value will be null in the new page. As a result, the two pages cannot script each other, so Chrome can load them in separate processes. Google Chrome will still keep same-site pages in the same process, to allow them to share caches and minimize overhead.
We hope you find this useful on your own sites!
Posted by Charlie Reis, Software Engineer

Technically speaking, what makes Google Chrome fast?

Thursday, December 3, 2009

Earlier this year, we heard from many of you on

What is DNS pre-resolution, and how does it make Google Chrome even faster?

Why is DNS pre-resolution difficult to do?

Explain in more detail how adaptive pre-resolution works.

How else is DNS pre-resolution beneficial? Can it help with browser start-up time?

How do we measure and benchmark the benefits of DNS pre-resolution?

What's next for DNS pre-resolution?

V8 JavaScript engine
with Mads Ager

What are DOM bindings?
What are the most recent improvements in DOM bindings, for Google Chrome as well as other browsers?
The Google Chrome beta release in August 2009 included improvements in DOM bindings. Tell us more.
How do we measure and benchmark improvements in DOM bindings?
In general, what are the biggest performance impediments for a browser?
What are some of the performance benefits of Google Chrome's multiprocess architecture?

Posted by Min Li Chan, Product Marketing Manager

An Update for Google Chrome's Developer Tools

Monday, November 30, 2009

Since we first

To take our newest release for a spin, get Google Chrome from the feedback and your contributions to improve developer tools in WebKit and Google Chrome even more.
Posted by Pavel Feldman, Software Engineer and Anders Sandholm, Product Manager

Extensions: One Step Closer to the Finish Line

Monday, November 23, 2009

docsdiscussion group
Posted by Lei Zheng, Software Engineer

Hello, open source developers. Would you like to help build an operating system for web users?

Thursday, November 19, 2009

Today we announced the Chromium OS project on the How to build and contribute

Open Source

We expect to publish additional design docs and documentation in the upcoming few months. You can track what we're doing on this blog and we hope you will join us in this effort.
Posted by Glen Murphy, Martin Bligh, Will Drewry, Software Engineers

A 2x Faster Web

Wednesday, November 11, 2009

Today we'd like to share with the web community information about SPDY, pronounced "SPeeDY", an early-stage research project that is part of our effort to Google Group.
Posted by Mike Belshe, Software Engineer and Roberto Peon, Software Engineer This post is cross-posted at the Google Research Blog

Introducing Google Chrome Frame

Tuesday, September 22, 2009

Today, we're releasing an early version of documentation. Please share your feedback in our

Posted by Amit Joshi, Software Engineer, Alex Russell, Software Engineer and Mike Smith, Product Manager

Extensions Status: On the Runway, Getting Ready for Take-Off

Wednesday, September 9, 2009

sample extensionsbe cautiousa few APIsthis post about some recent changesPosted by Aaron Boodman, Software Engineer

A New FTP Implementation Goes Live

Thursday, September 3, 2009

Starting in the Dev channel release 4.0.203.2, we are using our new FTP implementation by default on Windows. (It was already enabled by default on Linux and Mac.) This switchover is an important milestone in the development of our network stack. We'd like to acknowledge two Chromium contributors who made this possible.
The new FTP implementation was initially written by Ibrar Ahmed single–handedly. It was a long journey for him because he worked on it in his spare time. Ibrar has a master's degree in computer science from International Islamic University. After working as software engineer and associate architect at other companies, he recently started his own tele-medicine company. We thank Ibrar for his contribution to the Chromium network stack!
Paweł Hajdan Jr. started to work on the new FTP code in July as one of his summer intern projects at Google. Paweł added new unit tests, fixed bugs and compatibility issues, and is taking the lead in bringing the new FTP code to production quality.
Finally, we used Mozilla code for parsing and formatting FTP directory listings (ParseFTPList.cpp), which was originally written by Cyrus Patel.
In the near term, the original WinInet-based FTP implementation will still be available as an option on Windows. Specify the --wininet-ftp command-line option to enable it. (The original --new-ftp option is now obsolete and ignored.) During this period we will fix FTP bugs only in the new FTP implementation. When we're happy with the quality of the new FTP code, we will remove the original WinInet-based implementation, finally eliminating our dependency on WinInet.
Please help us achieve that goal by testing FTP with a Dev channel release and filing bug reports. Follow these guidelines when reporting bugs:

Please don't add a comment like "Here is another URL that doesn't work for me" to a bug. Always open a new bug, and give a link to another bug if you think they are similar.
Make the steps to reproduce as detailed as possible, and always include the version number of Chrome.
Check if the problem can be reproduced with --wininet-ftp on Windows and include that information in the bug report.

Posted by Wan-Teh Chang, Software Engineer

Bookmarks Here, Bookmarks There, Bookmarks Everywhere

Monday, August 17, 2009

As of today's chromium-dev.
Happy syncing!
Posted by Tim Steele, Software Engineer

Chromium Memory Usage

Thursday, August 6, 2009

There's been some public discussion lately about memory usage in Google Chrome. We think about our memory usage quite a bit so we're happy to see other people paying attention too. This has been a topic of discussion before, but our multiprocess architecture makes measuring memory utilization difficult with the standard set of tools. The crux of the problem is that Chromium goes to great lengths to share memory between processes. However, that shared memory is difficult to account for in the Windows Task Manager. On Windows XP, using the default Task Manager measurement of memory leads to double counting. On Vista, using the default view leads to under counting.
There are a couple of more accurate ways to measure memory utilization in Chromium (or Google Chrome). The easiest is to crack open the task manager that is built into Chromium which tries to account for our memory usage more holistically. If you want even more detail, you can click on "Stats for nerds" which is a link to about:memory.

If you don't fully trust Chromium's task manager or about:memory, the gold standard for measuring memory usage is to look at the system's total commit charge before, during, and after using Chromium. It's a little tricky to get right because you'll need to shut down other services that may kick in while you are running your test. Here's the basic procedure:

Shut down any unnecessary services
Reboot your computer
Using the windows task manager, measure the Total Commit Charge of the system*
Run the application you are seeking to test, in this case, Chromium
Measure the Total Commit Charge again
Close the application
Measure the Total Commit Charge one more time
Subtract your first measurement from your second, and you should have the memory used by Chromium
To validate your test, make sure that the first and last measurement are nearly identical

*On XP, Commit Charge shows up on the bottom of the Windows Task Manager. On Vista, look at the Performance tab of the Windows Task Manager and use the "Memory" number.
For more information on memory usage and how to measure it, check out the Memory Usage Backgrounder on chromium.org.
Posted by Brian Rakowski, Product Manager

Google Chrome Developer Tools for Eclipse Users

Tuesday, August 4, 2009

We recently The project is fully open sourced on a BSD-license and consists of two components, an SDK and a debugger. The SDK provides a Java API that enables communication with Google Chrome over TCP/IP. The debugger is an Eclipse plugin that uses the SDK and enables you to debug JavaScript running in Google Chrome from the Eclipse IDE.
We hope this project will help web app developers and welcome feedback as well as contributions.
Posted by Alexander Pavlov, Software Engineer

Careful! Extensions Can Bite!

Wednesday, July 22, 2009

Since we began work on an extensions system for Chromium, we've received a lot of positive feedback. While the system is not yet complete, we've noticed that a lot of you have started creating and installing extensions for daily use. This is really encouraging, and it motivates us to quickly finish things up, to enable extensions by default on all Google Chrome releases.
If you're using extensions now, you should keep in mind that they are powerful software. Extensions integrate with your browser, so they can access and change everything that happens in it. For example, the same technology that enables an extension to periodically check the number of messages in your Gmail inbox could also be used to read all your personal mail and tweet it to your mom! This can happen because of malicious intent or simply because of a bug.
To help protect your experience when using extensions, we recently enabled Omaha protocol, giving developers the ability to push out bug fixes and new features rapidly to users of their extensions. This is an important step towards a v1 release of extensions for all users, so we're pretty excited.
In addition, when we turn the extension system on, we plan to offer a gallery with ratings and comments that you can use to judge whether you want to install a particular extension. We will also have processes in place that, combined with reports from users, should help limit the number of malicious extensions that get uploaded and distributed to users. These processes will include removal of extensions that we have reason to believe are malicious. Until these things are in place and the extension system is officially launched, we recommend that you only install extensions that you built yourself.
Posted by Aaron Boodman, Software Engineer

Smaller is Faster (and Safer Too)

Wednesday, July 15, 2009

We have just started using a new compression algorithm called Courgette to make Google Chrome updates small.
We have built Google Chrome to address here.
Posted by Stephen Adams, Software Engineer

Launching Sputnik into Orbit

Monday, June 29, 2009

Today we're releasing 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

Developer Tools for Google Chrome

Wednesday, June 24, 2009

Since the

issue tracker. Or even better yet, we would love to get contributions to improving developer tools further in WebKit and Google Chrome.
Posted by Yury Semikhatsky, Software Engineer

Important Updates for Extension Developers

Wednesday, June 17, 2009

We're excited to see many people are experimenting with the upcoming extension features of Chrome in the dev channel. We're getting a lot of great feedback and are working hard to bring extensions to the stable channel as quickly as possible.
First of all, we've set up a new discussion group for extension-related topics. Going forward, 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).Posted by Nick Baum, Product Manager

The Plausible Promise

Tuesday, June 9, 2009

With the release of Mac Chrome to the dev-channel, I wanted to talk about open source and expectations. What was the point of releasing at this stage, you might ask? It's clearly not finished. Clearly. It's missing a large number of features, some half implemented, others not at all. Why even bother? Doesn't it just make us look bad?
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).
Right now we need your help, and it doesn't take a PhD in computer science. Read the bug reporting guidelines for Mac and Linux and get involved. Posted by Mike Pinkerton, Software Engineer

Danger: Mac and Linux builds available

Thursday, June 4, 2009

Linuxamong other thingsPosted by Mike Smith and Karen Grunberg, Product Managers

Web Developers: Keeping Up With Google Chrome

Wednesday, June 3, 2009

Google Chrome is moving fast. Version 2.0 was stabilized just six months after 1.0, and auto-updates have ensured that nearly all users are using the newest version of the browser within days of a release. As a web developer, it can be a bit daunting that the browser version changes so fast: What if the new version breaks something? How can I be prepared for changes that will affect my sites?
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 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.
Posted by Alex Russell, Software Engineer

Google Chrome, Sandboxing, and Mac OS X

Monday, June 1, 2009

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 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.Posted by Jeremy Moskovich, Software Engineer

Extensions at Google I/O

Wednesday, May 27, 2009

Today I gave a presentation at available, as are videos of a number of other Google Chrome-related talks.
Posted by Aaron Boodman, Software Engineer

Scaling JavaScript to Large Web Applications

Thursday, May 21, 2009

The V8 JavaScript engine has been designed for scalability. What does scalability mean in the context of JavaScript and why is it important for modern web applications?
Web applications are becoming more complex. With the increased complexity comes more JavaScript code and more objects. An increased number of objects puts additional stress on the memory management system of the JavaScript engine, which has to scale to deal efficiently with object allocation and reclamation. If engines do not scale to handle large object heaps, performance will suffer when running large web applications.
In browsers without a splay tree and modifies it by creating new nodes, adding them to the tree, and removing old ones. The benchmark is based on a JavaScript log processing module used by the V8 profiler and it effectively measures how fast the JavaScript engine can allocate nodes and reclaim unused memory. Because of the way splay trees work, the engine also has to deal with a lot of changes to the large tree.
We have measured the impact of running the Splay benchmark with different splay tree sizes to test how well V8 performs when the working set is increased:

The graph shows that V8 scales well to large object heaps, and that increasing the working set by more than a factor of 7 leads to a performance drop of less than 17%. Even though 35 MB is more memory than most web applications use today, it is necessary to support such working sets to enable tomorrow's web applications.
Posted by Mads Ager and Kasper Lund, Software Engineers

Chromium Tech Talks

Wednesday, April 29, 2009

Since starting work at Google, I've formed a deep appreciation for the number of high quality talks we have access to here (both Brett Wilson talking about the various layers of ChromiumWan-Teh Chang and Eric Roman talking about Chromium's network stack (and its history)
I hope these are just the first of many tech talks we can offer to you, the Chromium community.
Posted by Jeremy Orlow, Software Engineer

Guest post: 3D graphics in the browser

Tuesday, April 21, 2009

Today, we shared with the open source community an early version of code.google.com/apis/o3d.

A video of the O3D Beach Demo

Posted by Henry Bridge, O3D Product Manager and Gregg Tavares, Software Engineer

Chromium Blog