Chromium Blog
News and developments from the open source browser project
Danger: Mac and Linux builds available
Thursday, June 4, 2009
In order to get more feedback from developers, we have early
developer channel
versions of Google Chrome for
Mac OS X
and
Linux
, but whatever you do, please DON'T DOWNLOAD THEM! Unless of course you are a developer or take great pleasure in incomplete, unpredictable, and potentially crashing software.
How incomplete? So incomplete that,
among other things
, you won't yet be able to view YouTube videos, change your privacy settings, set your default search provider, or even print.
Meanwhile, we'll get back to trying to get Google Chrome on these platforms stable enough for a beta release as soon as possible!
Posted 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
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
.
Posted by Alex Russell, Software Engineer
Google Chrome, Sandboxing, and Mac OS X
Monday, June 1, 2009
Sandboxing
is a technique that Google Chrome employs to help make the browser more secure, and was discussed in a
previous blog post
. On Windows, getting a process sandboxed in a way that's useful to us is a pretty complicated affair. The relevant source code consists of over 100 files and is located under the
sandbox/
directory in Chromium's Open Source repository. But for our Mac and Linux ports, sandboxing is a very different story. On Linux there are a number of different sandboxing mechanisms available. Different Linux distributions ship with different (or no) sandboxing APIs, and finding a mechanism that is guaranteed to work on end-user's machines is a challenge. Fortunately, on Mac OS X, the OS APIs for sandboxing a process are easy to use and straightforward.
Sandboxing on the Mac
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.
Posted by Jeremy Moskovich, Software Engineer
Extensions at Google I/O
Wednesday, May 27, 2009
Today I gave a presentation at
Google I/O
explaining some of the cool ideas that lie at the heart of our upcoming
extension system
. For those who didn't get a chance to attend the conference, you can check out the slides, below:
The actions menu, visible in full-screen mode, will let you show speaker notes. We'll also post a video of the talk as soon as it's available.
As some of you know, it's already possible to write
extensions
using the latest developer build of Google Chrome. You can find out more about the system, and learn how to write your first extension, by reading our
HOWTO
document. We've really focused on making extensions as easy as possible to write, so you'll be up and running in no time.
We're still pretty early in the development of the extensions system, and we're constantly adding new features and tweaking the APIs based on your feedback. So if you try it out, we'd love to hear from you at
chromium-discuss@chromium.org
.
Happy coding!
Update:
Video of this talk is now
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
multi-process architecture
, a simple way to see the effect of an increased working set on JavaScript performance is to log in to GMail in one tab and run JavaScript benchmarks in another. The objects from the two tabs are allocated in the same object heap and therefore the benchmarks are run with a working set that includes the GMail objects.
V8's approach to scalability is to use
generational garbage collection
. The main observation behind generational garbage collection is that most objects either die very young or are long-lived. There is no need to examine long-lived objects on every garbage collection because they are likely to still be alive. Introducing generations to the garbage collector allows it to only consider newly allocated objects on most garbage collections.
Splay: A Scalability Benchmark
To keep track of how well V8 scales to large object heaps, we have added a new benchmark, Splay, to
version 4
of the V8 benchmark suite. The Splay benchmark builds a large
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
technical
and
not
). Reading code and documentation is pretty much unavoidable when you're a developer, but you really can't beat hearing directly from the expert's mouth on topics that you're interested in.
Last Wednesday, 5 Chromium experts gave mini tech talks on subjects ranging from the network stack to hacking on WebKit. Armed with 2 video cameras, a microphone, and a whiteboard, we did the best we could to capture these talks and make them available to Chromium developers around the world. Whether you're a seasoned Chromium contributor or just getting started, I think these videos have a lot to offer.
Here's a rundown of the videos:
Darin Fisher
talking about Chromium's multi-process architecture
Brett Wilson
talking about the various layers of Chromium
Dimitri Glazkov
talking about hacking on WebKit
Ben Goodger
talking about Views (and how to write good tests for them)
Wan-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
O3D
, a new shader-based API for 3D graphics in the browser. We are excited about this release: we believe that a 3D API for the web will allow web developers to create powerful, immersive 3D apps, that are comparable to the experience offered by client applications and game consoles. This will make the web better, not to mention more fun!
O3D is still at an early stage and is not a part of the Chromium code base. However, we hope that, combined with projects like Mozilla's
Canvas 3D
, it will encourage the discussion within the graphics and web communities about a new open web standard on 3D graphics for the web. With JavaScript (and browsers) becoming faster every day, we believe it is the right time for such a standard to emerge. To help you participate in this broader discussion, Google has created a forum where you can
submit suggestions
on what features a 3D API for the web should have.
If you are interested to learn more about O3D, you can visit us at
code.google.com/apis/o3d
.
A video of the O3D Beach Demo
Posted by Henry Bridge, O3D Product Manager and Gregg Tavares, Software Engineer
Labels
$200K
1
10th birthday
4
abusive ads
1
abusive notifications
2
accessibility
3
ad blockers
1
ad blocking
2
advanced capabilities
1
android
2
anti abuse
1
anti-deception
1
background periodic sync
1
badging
1
benchmarks
1
beta
83
better ads standards
1
billing
1
birthday
4
blink
2
browser
2
browser interoperability
1
bundles
1
capabilities
6
capable web
1
cds
1
cds18
2
cds2018
1
chrome
35
chrome 81
1
chrome 83
2
chrome 84
2
chrome ads
1
chrome apps
5
Chrome dev
1
chrome dev summit
1
chrome dev summit 2018
1
chrome dev summit 2019
1
chrome developer
1
Chrome Developer Center
1
chrome developer summit
1
chrome devtools
1
Chrome extension
1
chrome extensions
3
Chrome Frame
1
Chrome lite
1
Chrome on Android
2
chrome on ios
1
Chrome on Mac
1
Chrome OS
1
chrome privacy
4
chrome releases
1
chrome security
10
chrome web store
32
chromedevtools
1
chromeframe
3
chromeos
4
chromeos.dev
1
chromium
9
cloud print
1
coalition
1
coalition for better ads
1
contact picker
1
content indexing
1
cookies
1
core web vitals
2
csrf
1
css
1
cumulative layout shift
1
custom tabs
1
dart
8
dashboard
1
Data Saver
3
Data saver desktop extension
1
day 2
1
deceptive installation
1
declarative net request api
1
design
2
developer dashboard
1
Developer Program Policy
2
developer website
1
devtools
13
digital event
1
discoverability
1
DNS-over-HTTPS
4
DoH
4
emoji
1
emscriptem
1
enterprise
1
extensions
27
Fast badging
1
faster web
1
features
1
feedback
2
field data
1
first input delay
1
Follow
1
fonts
1
form controls
1
frameworks
1
fugu
2
fund
1
funding
1
gdd
1
google earth
1
google event
1
google io 2019
1
google web developer
1
googlechrome
12
harmful ads
1
html5
11
HTTP/3
1
HTTPS
4
iframes
1
images
1
incognito
1
insecure forms
1
intent to explain
1
ios
1
ios Chrome
1
issue tracker
3
jank
1
javascript
5
lab data
1
labelling
1
largest contentful paint
1
launch
1
lazy-loading
1
lighthouse
2
linux
2
Lite Mode
2
Lite pages
1
loading interventions
1
loading optimizations
1
lock icon
1
long-tail
1
mac
1
manifest v3
2
metrics
2
microsoft edge
1
mixed forms
1
mobile
2
na
1
native client
8
native file system
1
New Features
5
notifications
1
octane
1
open web
4
origin trials
2
pagespeed insights
1
pagespeedinsights
1
passwords
1
payment handler
1
payment request
1
payments
2
performance
20
performance tools
1
permission UI
1
permissions
1
play store
1
portals
3
prefetching
1
privacy
2
privacy sandbox
4
private prefetch proxy
1
profile guided optimization
1
progressive web apps
2
Project Strobe
1
protection
1
pwa
1
QUIC
1
quieter permissions
1
releases
3
removals
1
rlz
1
root program
1
safe browsing
2
Secure DNS
2
security
36
site isolation
1
slow loading
1
sms receiver
1
spam policy
1
spdy
2
spectre
1
speed
4
ssl
2
store listing
1
strobe
2
subscription pages
1
suspicious site reporter extension
1
TCP
1
the fast and the curious
23
TLS
1
tools
1
tracing
1
transparency
1
trusted web activities
1
twa
2
user agent string
1
user data policy
1
v8
6
video
2
wasm
1
web
1
web apps
1
web assembly
2
web developers
1
web intents
1
web packaging
1
web payments
1
web platform
1
web request api
1
web vitals
1
web.dev
1
web.dev live
1
webapi
1
webassembly
1
webaudio
3
webgl
7
webkit
5
WebM
1
webmaster
1
webp
5
webrtc
6
websockets
5
webtiming
1
writable-files
1
yerba beuna center for the arts
1
Archive
2024
Aug
Jun
May
Apr
Mar
Feb
2023
Nov
Oct
Sep
Aug
Jun
May
Apr
Feb
2022
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.