Chromium Blog
News and developments from the open source browser project
WebP in Chrome, Picasa, Gmail With a Slew of New Features and Improvements
Friday, May 20, 2011
Since we
announced
WebP
, a new image format based on WebM technology and the VP8 codec, we’ve been working hard with the open web community to improve and enhance it. Today we are happy to share news about a few new features and expanded support for WebP.
New Features
WebP's compression algorithms have been significantly improved while remaining completely
compatible with the previous releases. We hope the quality of a few sample images in the new gallery will
delight you
.
On the decoding side, we have integrated a fancy upsampler. Fancy upsampling reduces the pixelation of strong edges. You can see this feature when you zoom in, for example on a
WebP image with red edges
converted from this PNG original:
Original image in PNG format
Without fancy upsampling: strong stair-like pattern
With fancy upsampling: smoother edge
We also introduced the ability to incrementally decode the data as your computer downloads it from the web, a feature that allows the browser to display images without having to wait for the whole file to download. This feature is already enabled in Chrome 12.
On the encoding side, to further improve quality, we focused on segmenting the picture into areas with similar compressibility. For each of these segments, we tune the amount of compression and filtering differently, and bits are redistributed where they are most useful. Take for instance the image reproduced below [1]:
The easy segment contains lot of disparate signals and can be compressed more than the difficult one, which will be assigned more bits. In this example, the encoder only used two segments. By using even more segments (up to four), WebP is now able to retain many of the original
details
of the image [2]. This is in contrast to the frequent
ringing artifacts
one can clearly
see in JPEG
images.
The uneven distribution of bits between difficult and easy area is controlled in the new encoder using the
-sns
parameter, short for Spatial Noise Shaping. Its value can be set from 0 to 100 (0 meaning OFF) and with a default of 80. Note that when you enable SNS,
PSNR
may be degraded, but the overall visual quality is much improved.
We’ve added simple encoding and decoding example binaries to the
libwebp library
. In addition, we’ve added JNI support that allows Java programs to decode WebP images. Next up is transparency, also known as Alpha channel; we’re experimenting with it
now
and planning to add it to the next stable version of the codec. In parallel, we continue to improve the codec’s speed and will release a complete specification for the metadata format.
Increased adoption
WebP is now natively supported in Chrome and
Opera
. Google products including Gmail and Picasa Web Albums, have also added support to WebP so you can share, send and receive WebP images. WebP support is coming to AppEngine. In addition,
Google Instant Previews
now store images in WebP to reduce their storage needs.
Users that want to manipulate WebP images can now do so using software developed by the community including
Pixelmator
,
ImageMagick
, the
WebP format plugin
for Photoshop and the
Java VP8 decoder
. The open-source community has also contributed support for Mac OS X with
MacPorts packages
, Linux
Debian
,
OpenSUSE
and
Gentoo
packages and the
Apache HTTP Server
. On Windows, users who want to view WebP images natively, can download the
WebP codec
. This codec brings WebP support to such software as Microsoft Office 2010, Windows Media Center and Photo Edit.
The new features,
quality improvements
and increased adoption of WebP get us excited about its future. As always, we’re looking for more feedback as well as code contributions from the community. Let us know on the
mailing list
how your experiments are panning out and what new features you’d like to see in the future.
Image credits:
[1]: "Kayaker at Ekstremsportveko 2010, Voss". Image Author: Kjetil Birkeland Moe. Reproduced with permission of the author.
PNG source
, and
Blog post
by author with comparison of JPEG and WebP.
[2]: A storm at Pors-Loubous,
Plogoff
,
Finistère
, France. Image Author: Henri Camus. Permission: CC-BY; CC-BY-1.0. Source:
http://commons.wikimedia.org/wiki/File:A_storm_at_Pors-Loubous.jpg
Posted by Richard Rabbat, Product Manager and Pascal Massimino, Software Engineer
ChromeVox: Built-In Spoken Feedback For Chrome OS
Thursday, May 19, 2011
Cross posted at the
Google Code
blog
We recently unveiled
ChromeVox
— a built-in screen reader for Chrome OS — during Google I/O 2011. This is an early developer beta that is designed to help authors of web applications come up to speed with platform accessibility on Chrome OS.
ChromeVox is built as a Chrome extension — this means that unlike most accessibility software, it is built using only web technologies like HTML5, CSS and Javascript. As the built-in accessibility solution for Chrome OS, it can help users with special needs access modern web apps, including those that utilize
W3C ARIA
(Access to Rich Internet Applications) to provide a rich, desktop-like experience.
ChromeVox leverages two of Chrome's experimental extension APIs, the
experimental.tts API
for cross-platform text-to-speech, and the experimental.accessibility API that lets an extension listen for accessibility events in Chrome's menus and toolbars. In turn, ChromeVox exposes a
simple screen reader API
to web developers who wish to further customize the ChromeVox user experience. Thus, within your application, you can:
Automatically generate spoken messages and earcons.
Set ChromeVox to synchronize with your application's current focus.
ChromeVox also comes with an interactive
online tutorial
that demonstrates how users of spoken feedback interact with webpages. Examples range from static content to interactive applications. You can test these same navigation techniques within your own applications to quickly verify users can reach all portions of your application using the keyboard and obtain meaningful feedback. You can then annotate your application with the necessary ARIA properties and other accessibility enhancements to ensure that blind and visually impaired users gain complete access to your application. Please see our
Google I/O 2011 talk
for more.
Details on enabling accessibility in Chrome OS can be found on the
Accessibility help page
, and the Chrome extension is available for download from
our Wiki page
. For now, ChromeVox is targeted at end-users on Chrome OS, but it may also prove a useful tool to web developers using Chrome on all major platforms. We welcome your feedback via our Open Source project website at
http://google-axs-chrome.googlecode.com
.
Posted by T.V. Raman, Research Scientist
SSL FalseStart Performance Results
Wednesday, May 18, 2011
Last year, Google’s Adam Langley, Nagendra Modadugu, and Bodo Moeller proposed
SSL False Start
, a client-side only change to reduce one round-trip from the
SSL
handshake.
We implemented SSL False Start in Chrome 9, and the results are stunning, yielding a significant decrease in overall SSL connection setup times. SSL False Start reduces the latency of a SSL handshake by 30%
1
. That is a big number. And reducing the cost of a SSL handshake is critical as
more
and
more
content providers move to SSL.
Our biggest concern with implementing SSL False Start was backward compatibility. Although nothing in the SSL specification (also known as TLS) explicitly prohibits FalseStart, there was no easy way to know whether it would work with all sites. Speed is great, but if it breaks user experience for even a small fraction of users, the optimization is non-deployable.
To answer this question, we compiled a list of all known https websites from the Google index, and tested SSL FalseStart with all of them. The result of that test was encouraging: 94.6% succeeded, 5% timed out, and 0.4% failed. The sites that timed out were verified to be sites that are no longer running, so we could ignore them.
To investigate the failing sites, we implemented a more robust check to understand how the failures occurred. We disregarded those sites that failed due to certificate failures or problems unrelated to FalseStart. Finally, we discovered that the sites which didn’t support FalseStart were using only a handful of SSL vendors. We reported the problem to the vendors, and most have fixed it already, while the others have fixes in progress. The result is that today, we have a manageable, small list of domains where SSL FalseStart doesn’t work, and we’ve added them to a list within Chrome where we simply won’t use FalseStart. This list is public and posted in the chromium source code. We are actively working to shrink the list and ultimately remove it.
All of this represents a tremendous amount of work with a material gain for Chrome SSL users. We hope that the data will be confirmed by other browser vendors and adopted more widely.
1
Measured as the time between the initial TCP SYN packet and the end of the TLS handshake.
Posted by Mike Belshe, Software Engineer
Chrome Web Store in 41 languages and In-App Payments
Friday, May 13, 2011
Since we
launched
the Chrome Web Store, we’ve been working on several new improvements. Today, we’re happy to share our progress towards making the Chrome Web Store available to all Chrome users worldwide and the availability of Google In-App Payments for web app developers.
First, as we
announced
at Google I/O, the
In-App Payments API
is now available for app developers. We demo-ed the way
Graphicly
uses this API and
Angry Birds
announced that they will use it to offer users the Mighty Eagle for in-app purchase on the web. Integrating the API into your app is as simple as adding a single line of code and provides a frictionless user experience for making purchases within the app. We hope to gather
feedback
on the API before making it fully available this summer.
Second, the Chrome Web Store is now available in 41 languages. This is our second step towards launching
Chrome Web Store in 15 additional countries
. Developers interested in targeting international users can now go to the Chrome Web Store and publish free apps in these countries in preparation for launch. We will also support publishing paid apps in selected countries later this year.
Localizing your apps will expose them to many more users and allow them to be featured in the local Chrome Web Store homepages. We hope this expanded functionality will allow you to create brand new international apps or to
localize your existing apps
.
If you have additional questions, please take a look at our
FAQ
or join our
developer discussion group
.
Posted by Alexandra Levich, Product Manager
Remote debugging with Chrome Developer Tools
Monday, May 9, 2011
Google Chrome Developer Tools (or DevTools) front-end is implemented as an HTML CSS JavaScript web application. It uses a serialized message channel in order to communicate with the inspected page. Originally, we were working on establishing this serialized asynchronous interaction in order to bring DevTools front-end out of the inspected page process. But once it was done, we could take it even further and run DevTools front-end outside the browser. Here is how you can give it a try:
Run the Chrome instance that you will be debugging remotely with the remote debugging
command line switch
:
chrome.exe --remote-debugging-port=9222 --user-data-dir=remote-profile.
It is essential that you use a different instance of Chrome for the remote session and that is why we run it with the
--user-data-dir
argument.
Navigate to the pages you intend to debug.
Now run a regular (client) Chrome instance and navigate to
http://localhost:9222
there.
You will see a number of links that will bring you to the remote debugging sessions for the corresponding pages. Click them and enjoy debugging your Chrome pages over the wire:
We implemented the remote debugging infrastructure in the WebKit repository (or as we say “upstream”), so that other WebKit port owners could expose remote debugging capabilities with a minimal effort. See more information on remote debugging in our
WebKit blog post
. For more information on the remote debugging and Chrome Developer Tools in general, see our
documentation page
.
Posted by Pavel Feldman, Software Engineer
Updating JavaScript Benchmarks for Modern Browsers
Wednesday, May 4, 2011
Benchmarks are incredibly important for influencing the direction of JavaScript engines. Over the past two years, JavaScript has gotten dramatically faster across all major browsers, particularly in areas that popular benchmarks measure. As it turns out, browser developers are a competitive bunch. However, as JS engines get faster, benchmarks must evolve in order to keep pushing them in the right direction.
We’ve been constantly updating our
V8 benchmark suite
to force us to get faster in areas that are important to web developers. We’ve fixed bugs and added new tests for
regular expressions
and
memory management
. We’re very focused on JavaScript performance, so we scrutinize our benchmark carefully to make sure that it’s as useful a measuring stick as possible.
The two other widely cited JS benchmarks are
SunSpider
from Apple, and
Kraken
, a new benchmark from Mozilla.
SunSpider was one of the first suites of tests, first appearing in 2007. It’s done a lot to help improve JS engines, but many of the tests in the suite are less relevant to the web in 2011. Even for the more relevant tests, JavaScript has gotten so fast that many finish in only a few milliseconds. This just isn’t long enough to figure out which engine is faster--a golf cart and a Tesla will finish a 10-foot race in nearly the same time.
To make the benchmark more meaningful, we’ve experimented by making the race longer by running each of the tests in SunSpider 50 times consecutively. While repeating a trivial test many times isn’t a great solution, it does provide an opportunity for some optimization. With this change, the results begin to reflect Chrome’s true performance. It’s more than 30% faster on the SunSpider suite overall and up to 4x faster on some of the individual tests.
Kraken, a more modern benchmark, is in better shape. Unfortunately, the
canonical
version of the benchmark has not been updated to reflect all the latest changes which address at least
one important bug
. As a result, the benchmark is less useful and has even (mis)led us to spend time making some
irrelevant optimizations
in Chrome. To help us focus on the right things, we’re now testing the latest version of Kraken built directly from Mozilla’s source code repository.
We’re posting a
modified version of SunSpider
and the
latest version of Kraken
to make it easy to run the benchmarks in your own browser and compare results.
Posted by Mike Belshe, Software Engineer
Adding more yellow to the Mac color scheme
Monday, May 2, 2011
We’re pleased to announce that
Google Chrome Canary for Mac
is now available.
When we
released
Google Chrome Canary for Windows last year to help get more feedback on crashes from the bravest Chrome users, we weren’t sure how many people would tolerate using a completely untested build of Chrome. Since then, hundreds of thousands of Windows users have contributed to Chrome’s development by using the Canary and sending us valuable feedback. Thanks!
The Mac version of Google Chrome Canary follows the same philosophy: it automatically updates more frequently than the Dev channel, and does not undergo any manual testing before each release. Because we expect it to be unstable and, at times, unusable, you can run it concurrently with a Dev, Beta, or Stable version of Google Chrome. Your Canary data remains separate, but if you
set up Sync
in each version of Chrome that you use, you can automatically continue using the same set of bookmarks, extensions, themes, and more.
If you’re a Mac user and want to help us test the bleeding edge, or if you just want to see our icon in shades of yellow,
take it for a spin!
Posted by Mark Mentovai, Software Engineer
Providing transparency and controls for Adobe Flash Player’s local storage
Tuesday, April 26, 2011
Many web users today are aware of
browser cookies
, and every major browser allows users to view and delete the browser cookies stored on their computer. However, some users may not be aware that many websites use different types of local storage as well, including Adobe Flash Player
Local Shared Objects
(LSOs), referred to by some people as “Flash cookies.”
In the past, in order to view Flash LSOs and delete them from your computer, you had to visit an
online settings application
on Adobe’s website. To make local storage data deletion easier, we worked with Adobe and others in the web community to design the
NPAPI ClearSiteData API
. This API, which Adobe has implemented in Flash Player 10.3, has made it possible to delete Flash LSOs directly from the browser itself.
As of this week’s
Chrome Dev channel release
, you can delete local plug-in storage data (such as Flash LSOs) from within Chrome by clicking
Wrench > Tools > Clear browsing data
and selecting “Delete cookies and other site and plug-in data.”
Above: The chrome://settings/clearBrowserData dialog.
“Plug-in data” here refers to client-side data stored by plug-ins that obey the NPAPI ClearSiteData API, such as Flash Player 10.3. You can also configure Chrome’s
content settings
to clear plug-in data automatically whenever you close the browser.
Above: The chrome://settings/content dialog.
To our knowledge, Adobe Flash Player is currently the only NPAPI plug-in which has implemented support for the NPAPI ClearSiteData API, but we hope other plug-ins will follow suit. We believe providing control over plug-in data directly in the browser creates a better experience for both users and website developers.
Posted by Bernhard Bauer, Software Engineer
Chrome Developer Tools: Understanding Stack Traces
Wednesday, April 20, 2011
One of the biggest challenges in JavaScript development is dealing with script errors. We’ve been working hard to improve and extend the set of tools that lets you better understand how your JavaScript code works. Let’s have a quick look at five features of
Google Chrome Developer Tools
that can help you work with exceptions and stack traces more efficiently:
Exception call stack
. When something goes wrong, you can open the developer tools console. There you’ll find a number of uncaught JavaScript exception messages there. Each message has a link to the file name with the line number you can navigate to. However, there might be several execution paths that lead to the error and it’s not always obvious which one of them has happened. Exceptions in the console are now accompanied with the complete JavaScript call stacks after the developer tools window has been opened.
Pause on exception
. The developer tools’ Scripts panel enables you to pause JavaScript execution each time an exception is thrown and inspect its call stack, scope variables and state of your app. You can choose whether to pause only on uncaught exceptions or on all exceptions.
Logging stack traces
. Printing log messages to the developer tools console is also very helpful in understanding how your application behaves. Now you can make the log entries even more informative by including associated stack traces. You can instrument your code with console.trace() calls that would print current JavaScript call stack. Moreover, you can check that some invariants are true using console.assert() which prints a full stack trace when its conditional expression passed as first parameter evaluate to false.
Error.stack
. Each Error object has a property named “stack” that contains the stack trace.
Handler function for window.onerror
. Recently we’ve added support for setting a handler function to window.onerror. Whenever a JavaScript exception is thrown in the window context and is not caught by any try/catch block, the function will be invoked with the exception’s message, the URL of the file where the exception was thrown and the line number in that file passed as three arguments in that order. You may find it convenient to set an error handler that would collect information about uncaught exceptions and report it back to your server.
For a more complete reference on working with the Google Chrome Developer Tools, check out our
home page
. We further described improvements to exception handling and stack traces in our recent
WebKit blog post
.
Posted by Yury Semikhatsky, Software Engineer
Protecting users from malicious downloads
Tuesday, April 5, 2011
[cross-posted on the
Google Online Security Blog
]
For the past five years Google has been offering protection to users against websites that attempt to distribute malware via drive-by downloads — that is, infections that harm users’ computers when they simply visit a vulnerable site. The data produced by our systems and published via the
Safe Browsing API
is used by Google search and browsers such as Google Chrome, Firefox, and Safari to warn users who may attempt to visit these dangerous webpages.
Safe Browsing has done a lot of good for the web, yet the Internet remains rife with deceptive and harmful content. It’s easy to find sites hosting free downloads that promise one thing but actually behave quite differently. These downloads may even perform actions without the user’s consent, such as displaying spam ads, performing click fraud, or stealing other users’ passwords. Such sites usually don’t attempt to exploit vulnerabilities on the user’s computer system. Instead, they use social engineering to entice users to download and run the malicious content.
Today we’re pleased to announce a new feature that aims to protect users against these kinds of downloads, starting with malicious Windows executables. The new feature will be integrated with Google Chrome and will display a warning if a user attempts to download a suspected malicious executable file:
Download warning
This warning will be displayed for any download URL that matches the latest list of malicious websites published by the
Safe Browsing API
. The new feature follows the same
privacy policy
currently in use by the Safe Browsing feature. For example, this feature does not enable Google to determine the URLs you are visiting.
We’re starting with a small-scale experimental phase for a subset of our users who subscribe to the Chrome development release channel, and we hope to make this feature available to all users in the next stable release of Google Chrome. We hope that the feature will improve our users’ online experience and help make the Internet a safer place.
For webmasters, you can continue to use the same interface provided by
Google Webmaster Tools
to learn about malware issues with your sites. These tools include binaries that have been identified by this new feature, and the same
review process
will apply.
Posted by Moheeb Abu Rajab, Google Security Team
New experimental APIs for Chrome extensions
Monday, April 4, 2011
In the latest Chrome beta release, we made available two new
experimental extension APIs
: the Web Navigation and Proxy Extension APIs. They are the first in
a series of low-level APIs
that allow extension and application authors integrate more closely with the user’s browsing experience. We're excited about these APIs and want to get them in front of developers early so we can receive their feedback on any additional needs.
The
Web Navigation Extension API
allows extension developers to observe browser navigation events. These events fire both for top-level navigation and in-page navigation. The API therefore allows an extension to keep track of exactly what page (or section thereof) the tab is showing, and how the user got there. We foresee a number of use cases for this API, including extensions that gather and present statistical or benchmarking data, safe-browsing extensions, and developer tools.
The
Proxy Extension API
closes one of our most popular
feature requests
, allowing users to configure Chrome’s proxy settings via extensions. Proxies can be configured for the entire browser or independently for regular and incognito windows. Configuration options range from setting a single proxy server to installing remote or even local
PAC scripts
. A
sample extension
demonstrates these capabilities.
Sample extension showcasing individual proxy settings for normal and incognito windows.
To try out these new APIs, please go to about:flags and enable “Experimental Extension APIs”. To protect our users' privacy, when these APIs reach the stable channel, extensions that use them will need to request explicit permission from users.
Let us know
if you create something cool with one of these APIs. If we like it, we may feature you in the extensions gallery.
We’re looking forward to seeing what you’ll create!
Posted by Dominic Battré, Software Engineer and Jochen Eisinger, Software Engineer
Taking Chrome to Lite speeds
Friday, April 1, 2011
When we created Chrome, we focused on
speed, simplicity, and security
as its hallmark traits. Today, we’re proud to announce a new extension for Chrome, called
ChromeLite
, which is a giant, sprightly
leap
ahead on all three fronts.
In our never-ending quest for speed, our team members recently gathered to race the latest and greatest browser versions against each other. Much to our surprise, the winning browser was neither the latest version of Chrome nor another modern browser, but was instead an early text-based browser called
Lynx
.
Inspired by Lynx’s approach, we decided to experiment with stripping out all the extraneous details of a web page to accelerate page load time by removing a web page’s formatting, colors, images, audio, and video. The end result?
ChromeLite
-- the extension which brings you the web as it was originally conceived: nothing but pure text, presented in an aesthetically pleasing monochrome palette.
ChromeLite dramatically simplifies the user experience of web browsing by rendering the entire web in plain text. Users won’t have to worry about various
media codecs
and browser
plug-ins
to view much of the content on the web today. Preliminary analysis by our top-notch security team also suggests that running ChromeLite reduces your susceptibility to targeted exploits on the web by removing a popular attack surface: color.
In short, we hope ChromeLite gives all users on the web yet another option to safely and speedily enjoy the web in all its pure,
unadulterated simplicity
. If you’re looking to get your fingers accustomed to these new blazing speeds once you’ve
installed ChromeLite
, check out our newly developed
Chromercise regimen
.
Posted by Jeff Chang, Product Manager and Dominic Mazzoni, Software Engineer
UA String Changes Coming In Chrome 11
Thursday, March 31, 2011
When websites want to know what browser you're using, they often examine the "user agent", or "UA" string. This is a string that provides information about what browser and operating system you're using. Beginning with Chrome 11, we're making some changes to our UA string, which can affect website compatibility.
For reference, here is what the current (Chrome 10) UA string looks like on a few different platforms:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
And in comparison, here are the UA strings for Chrome 11 on the same platforms:
Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.16 Safari/534.24
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.16 Safari/534.24
Let's break down the differences in detail. We've made four changes, two of which are Windows-specific:
On Windows, the initial "
Windows
;
" platform identifier has been removed. This was redundant with the subsequent OS version identifier, and makes us more compatible with Internet Explorer, whose UA string doesn't have this initial token.
The "
U
" SSL encryption strength token has been removed. This token dates from more than a decade ago, when U.S. export laws limited the encryption strength that could be built into software shipped to various other countries; the valid values are "
U
" (for "USA" 128-bit encryption support), "
I
" (for "International" 40-bit encryption support), and "
N
" (for "None", no encryption support). These days, every browser ships with 128-bit SSL support everywhere, so it's not necessary to advertise it.
On 64-bit versions of Windows, tokens have been added after the OS version. For 32-bit Chrome builds running on 64-bit Windows, we've added "
WOW64
". (
WOW64
" stands for "Windows 32-bit On Windows 64-bit" and is the name Microsoft gives its 32-bit compatibility subsystem.) In our source code, we've also added identifiers for 64-bit native builds, specifically "
Win64
; x64
" for x64-based processors and "
Win64; IA64
" for Itanium systems. (However, we don't currently ship such builds, or have any immediate plans to.) These tokens are useful for sites that need to provide download links for native executables, and match what Internet Explorer uses.
The locale has been removed. Web authors who want to know what languages a browser supports should use the HTTP
Accept-Language
header instead, which can supply multiple locales. In fact, websites that relied on the UA string locale probably had some very unhappy visitors, because Chrome always had a bug where the UA string locale was reported as "
en-US
", regardless of the user's desired locale(s)!
One more question remains: why are we making these changes now? Because websites tend to use common pieces of code to check all browsers' UA strings, it's important for browsers to stay in sync with each other. Mozilla has made the above changes in Firefox 4 (and more; see
http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/
for details), which was released recently, and we wanted to change Chrome to match as soon as possible, to minimize the disruption to web authors.
As the changes above have trickled into our Canary and Dev builds, we've already found and fixed some problems in Google's UA string parsing libraries that have caused compatibility issues with Google sites (though not all of the affected sites have updated yet). If you see problems on other sites you think might be caused by the new UA string, try running Chrome with an alternate UA string using the
--user-agent="<Put older UA string here>"
command line flag. (You can double-check the UA string Chrome sends to websites by typing
about:
in your address bar and hitting <enter>.) If that fixes the problem, please let us know by filing a bug in our bug tracker at
http://crbug.com/
.
Posted by Peter Kasting, Software Engineer
Getting smoother animated web content while reducing CPU usage
Tuesday, March 29, 2011
The web is becoming more interactive and animated day by day. Many web pages use the
Canvas
element to draw rich 2D content via the
2D context
or modify DOM elements on the fly. These pages generally use the
setTimeout
or
setInterval
APIs to receive frequent callbacks, allowing them to redraw their content periodically, or use DHTML to move elements on the page. As 3D content drawn using the
WebGL API
increases in popularity, it will use similar animation techniques.
Unfortunately, setTimeout and setInterval don’t take into consideration whether the destination element, or even the tab that contains it, is actually visible. So, pages with high-frequency timers will consume CPU resources even if the tab is in the background. On laptops, netbooks, and mobile devices of all kinds, reducing CPU consumption is essential in order to prolong battery life. Additionally, excess CPU consumption by background tabs reduces the smoothness of animations on the foreground tab.
Excessive CPU consumption by timers on web pages is not a theoretical problem. We have measured web sites containing mostly static text content firing timers at a rate of over two hundred per second.
Mozilla recently introduced the experimental
mozRequestAnimationFrame API
, which has different semantics than setTimeout or setInterval. Instead of the developer specifying a target frame rate, the browser runs the given callback when it is ready to produce the next animated frame. The callbacks are specifically known to be relevant to the animation of the page, and don’t run too often.
An experimental webkitRequestAnimationFrame API has been upstreamed to WebKit, and is available starting in Chrome 10. This is essentially the same as mozRequestAnimationFrame, but supports an optional second argument which is the element that the callback intends to animate. This additional information will allow the browser to avoid animating elements that are not visible to the user. See this
bug report
for more details. Chrome doesn’t run requestAnimationFrame callbacks for background tabs at all, which dramatically reduces CPU consumption when multiple tabs containing animated content are in the same window.
The
WebGL samples
project contains a three dimensional graphics library that has been modified to use requestAnimationFrame rather than setTimeout or setInterval. Take a look at this library for a good example of how to convert existing timeout based animations to the new style, while preserving compatibility with browsers that don’t support requestAnimationFrame.
In the forthcoming Chrome 11 release, we plan to reduce CPU consumption even for pages that are using setTimeout and setInterval. For background tabs, we intend to run each independent timer no more than once per second. This change has already been implemented in the Chrome dev channel and canary builds. While there may be some compatibility impact for web pages, we believe that improving the user experience for the foreground tab, and increasing battery life, are problems needing to be addressed. Please
send us your comments
on this planned change.
Posted by Kenneth Russell, Software Engineer
A Mini-Newsletter From Your Google Chrome Security Team
Tuesday, March 8, 2011
We’re always working hard to enhance the Chrome browser with bug fixes, new defenses and new features. The
release of Chrome 10
is no different, and there are some items worth highlighting:
Chrome 10: Flash sandboxing
With Chrome 10, our first cut of the previously announced
Flash sandboxing initiative
is now enabled by default for the Windows platform on Vista and newer. Additionally, because we automatically update Flash to the latest and most secure version, this should provide useful defense in depth.
Chrome 10: Out-of-date plug-in warnings
As we
previously mentioned
, we believe that some of the most significant opportunities to increase user security revolve around plugins. We’ve made a number of improvements in this area, including actively encouraging users to update their plug-ins to the most secure version. Chrome now detects when a plug-in is out of date and blocks it with a simple infobar. This infobar helps guide the user towards updating their plug-in with the latest security fixes.
Chrome 10: Plug-in blocking enhancements
Some of our more advanced users prefer fine-grained control over which plug-ins they wish to run -- which can have security and privacy benefits. Chrome has long had a feature which blocks plug-ins by default (Wrench menu -> Preferences -> Under the hood -> Content Settings -> Plug-ins). We’ve improved this feature by adding a context menu to the blocked plug-in placeholder. This menu lets users control which plug-ins do and do not run. Using a context menu helps prevent clickjacking attacks that try to bypass the block. Plug-in placeholders can also be hidden (for example, if they are floating over and obscuring real content), and the actual plug-in that wishes to run is made apparent.
Chromium Security Rewards program still going strong
We mentioned in passing in the
9.0.597.107 release notes
that our
rewards program
has passed $100,000 of rewards. We’d like to re-iterate our thanks to all the named researchers in our
Hall of Fame
. We’re continually delighted with the stream of interesting and clever bugs that we receive, so it will be exciting to see what the rest of 2011 brings. Remember, we love giving out money!
Still hiring!
We are always looking to expand the Google Chrome Security Team, and we’re looking for a wide range of talents. We can promise exciting and varied work, working to protect hundreds of millions of users and working alongside the best in the industry. Why not have a look at
our job posting
?
Posted by Chris Evans, Google Chrome Security Team, Bernhard Bauer, Software Engineer, and Carlos Pizano, Software Engineer
GPU acceleration old drivers = :(
Tuesday, March 1, 2011
Over the last few months, we’ve made a lot of progress using graphics hardware (commonly referred to as the GPU) to make Chrome faster and more power-efficient. However, as we’ve rolled out features like WebGL and GPU-accelerated HTML5 video, we noticed a troubling trend: users with old graphics drivers experienced a significant increase in crashes when using these features. Because stability is one of Google Chrome’s core principles, we’ve recently become stricter about requiring up-to-date drivers and graphics hardware by adding ranges of old drivers to Google Chrome’s software rendering list.
Developers should continue to ensure that the software-rendered version of their sites work properly for users without GPU-accelerated browsers, so we expect most content to continue to function normally for Google Chrome users with out-of-date drivers -- albeit, without the same performance you might expect from Chrome. WebGL content on out-of-date systems will currently not display, but we are working to provide a software path so that these systems can run basic 3D applications.
As our ability to determine whether a machine can reliably use GPU features improves, we hope to extend hardware acceleration support to more and more users. Here are some steps you can take to maximize the chances that Chrome will run fully hardware-accelerated on your computer:
Use the latest major version of your operating system (such as Windows 7 or Mac OS 10.6)
Install
all system updates and driver updates
that are available for your system.
Posted by Henry Bridge, Product Manager
Chrome Developer Tools: Back to Basics
Thursday, February 24, 2011
It’s been an exciting past few months in the
Google Chrome Developer Tools
world as we keep adding new features, while polishing up existing ones to respond to your feedback.
One of the areas we have focused a lot of our energy is on network instrumentation. Recently we’ve made many improvements that will hopefully improve your experience when using Chrome Developer Tools. These improvements include:
Network aspects of your web page are now inspected in the
Network panel
. This gives you access to even more information at a single glance. You can sort and clear data, preserve log information upon navigation and even export network data into
HAR
format.
All the timing information about your resource loads now comes from the network stack, not WebKit, so timing information now adequately represents raw network timing. You can see detailed timing for different phases of the loading by hovering over the log entry.
We now push raw HTTP headers and status messages into Chrome Developer Tools. As a result, you now see precisely what the browser received from the server and not just how the rendering engine interpreted that information.
Similarly to the old Resources panel, you can see syntax-highlighted resource contents.
We’ve also made CSS editing a whole lot easier. In particular, you’ll now find separate fields for property names and values instead of a single field for both. As you type, you will see suggestions of available keywords for property values.
But that’s only the tip of the iceberg. Similar to the changes in the network panel, the
CSS sidebar
now shows the raw information that the browser gets from the server - not the rendering engine’s interpretation of the information. As a result, you can use Chrome Developer Tools to see CSS properties that are not recognized by WebKit (e.g., engine-specific or simply erroneous properties). This finally puts an end to the nightmare of disappearing invalid properties.
For a more complete reference on working with the Chrome Developer Tools, check out our new
home page
. The CSS improvements that we implemented upstream in WebKit are further described in our
WebKit blog post
. And for even more tips on how to use Chrome Developer Tools, watch the new video below.
Posted by Pavel Feldman and Alexander Pavlov, Software Engineers
Amping Up Chrome’s Background Feature
Wednesday, February 23, 2011
Many users rely on apps to provide timely notifications for things like calendar events and incoming chat messages, but find it cumbersome to always keep a Chrome window open. Extensions and packaged apps can already display notifications and maintain state without any visible windows, using
background pages
. This functionality is now available to hosted apps - the most common form of apps in the
Chrome Web Store
- via a new background window mechanism.
Apps and extensions that use the new “background” feature can continue to run in the background—even if the user closes down all of Chrome’s windows. “Background apps” will continue to run until Chrome exits. The next time Chrome starts up, any background windows that were previously running will also be re-launched. These windows are not going to be visible but they will be able to perform tasks like checking for server-side changes and pre-emptively loading content into local storage.
One way you can use background windows is to preload content and data so that they are immediately available when the user opens your app. You could also issue HTML5 notifications to alert the user when important events occur—for example, a friend wants to initiate a chat session. There are plenty of possibilities here, and we look forward to seeing what you’ll do.
To protect our users’ privacy, we’ve made this functionality available only to apps and extensions; regular websites will not be able to open background windows. Developers will also need to declare the “background” capability on their apps.
Users can easily see which background apps (and extensions) are running in their system through the “Background Apps” menu of the Chrome icon in the system tray (Windows/Linux) or dock (Mac). Chrome will automatically load background components when the user logs in, and the Chrome icon will remain in the system tray or dock as long as background apps are running- even if all Chrome windows are closed. To close all background components, a user just needs to exit Chrome.
The feature is already available in Chrome’s Dev channel. For details on the API, check out our
developer’s guide
, which also includes sample apps to try out.
Posted by Andrew Wilson, Software Engineer and Michael Mahemoff, Developer Relations
Extending the Omnibox
Tuesday, February 22, 2011
One of the most powerful aspects of Google Chrome is the omnibox, also known as the address bar. You can type URLs and searches into one unified place and it all just works. With the new
omnibox API
, extension developers can make the omnibox even more powerful.
The omnibox API lets extension developers add their own keyword command to the omnibox. When the user types a query prefixed by this keyword, the extension can suggest potential completions and react to the user's input.
For example,
this extension
lets you search and switch between your open tabs from the omnibox:
Keep an eye out for cool new extensions as developers get their hands on this API!
Posted by Matt Perry, Software Engineer
Native Client: Getting Ready for Takeoff
Friday, February 18, 2011
Over the last few months we have been hard at work getting
Native Client
ready to support the new
Pepper
plug-in interface. Native Client is an open source technology that allows you to build web applications that seamlessly and safely execute native compiled code inside the browser. Today, we’ve reached an important milestone in our efforts to make Native Client modules as portable and secure as JavaScript, by making available a first release of the revamped
Native Client SDK
.
The SDK now includes support for a comprehensive set of Pepper interfaces for compute, audio, and 2D Native Client modules. These interfaces are close to being stable, with some important exceptions that are listed in the
release notes
.
In addition, we’ve focused on improving security. We have enabled auto-update and an outer sandbox. This allowed us to remove the
expiration date
and localhost security restrictions we had adopted in previous research-focused releases. Beyond security, we’ve also improved the mechanism for fetching Native Client modules based on the instruction set architecture of the target machine, so developers don’t need to worry about this any more.
We are excited to see Native Client progressively evolve into a developer-ready technology. In the coming months we will be adding APIs for 3D graphics, local file storage, WebSockets, peer-to-peer networking, and more. We’ll also be working on Dynamic Shared Objects (DSOs), a feature that will eventually allow us to provide Application Binary Interface (ABI) stability.
Until the ABI becomes stable, Native Client will remain off by default. However, given the progress we’ve made, you can now sticky-enable Native Client in Chrome 10 through the about:flags dialog. Otherwise, you can continue using a command line flag to enable Native Client when you want to.
A big goal of this release is to enable developers to start building Native Client modules for Chrome applications. Please watch this blog for updates and use our
discussion group
for questions, feedback, and to engage with the Native Client community.
Posted by Christian Stefansen, Product Manager
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
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
.