Monday, December 1st, 2008
Category: Chrome
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:
- 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.
Wednesday, October 29th, 2008
Category: Chrome, Google
The Google folks have been doing a really good at consistently blogged about the decisions that were made as they created Chrome:
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.
Thursday, October 23rd, 2008
Category: Chrome
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.
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?
Monday, October 20th, 2008
Category: Browsers, Chrome, Plugins
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.
