RockMelt, the Chromium-based social Web browser has reached a new milestone today. Following its first public beta that was released in early March, RockMelt Beta 2 has started being pushed to the browser's users. The new version brings many new features, alongside the usual bug fixes, performance enhancements, and a new base for the browser -- Chromium 10, which also powers Google Chrome's stable channel releases at the moment. The previous RockMelt beta was based on Chromium 9, and it's nice to see it kept up-to-date.
Perhaps the most intriguing new feature in RockMelt Beta 2 is the new bookmarking system, intuitively called View Later. RockMelt's developers have come to the conclusion that, in a modern browser that offers address auto-complete and makes the most visited sites accessible on the new tab page, people don't use bookmarks anymore -- at least not the way they used to back in the day. These days apparently, bookmarking is mostly about saving interesting pages for future reference. Which is where View Later comes in. You just click on the new clock icon at the far right of the address bar (where Chrome's star icon is), and you've added the page you're viewing to your View Later queue. You can even add individual posts from Facebook or Twitter. Your View Later contents are synced using RockMelt's general sync mechanism.
RockMelt Beta 2 also packs a new Twitter app, which now lets you edit retweets, view direct messages, reply to all, and easily use Twitter search. It uses Twitter's new real-time API, so you get the tweets exactly at the moment they're published.
The Chat bar has been redesigned, making it easier to keep track of multiple conversations, since chats are now docked in the Chat bar along the bottom of the browser, where they even stay visible while you browse the Web. Incoming chat messages will trigger notifications, and the ability to drag individual chat sessions out of the bar and into separate windows is still there.
All in all a solid update, that has started rolling out today and will reach all of the browser's users in a week's time. What remains to be seen is how many people are willing to switch from any of the 'big guys' to RockMelt for its added features.
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.
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="
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.
Gamers and other enthusiasts know the importance of keeping their video card's drivers current, but it's not something the vast majority of the computing public pays any attention to. If the computer is running OK, there's no need to update drivers, right?
As it turns out, there's a very good reason to update: your old driver might be causing your Web browser to crash excessively. That's what Google is reporting over at the Chromium blog. If you're surfing with Chrome and using an outdated driver, it could be wreaking havoc with Chrome's GPU acceleration and WebGL features.
Along with HTML5 support and tracking protection, hardware acceleration has become part of the 'geeky trinity' of features to trumpet in next-gen Web browsers. As developers tap deep into your computer's hardware to squeeze out additional performance gains, keeping your drivers fully updated -- especially for the graphics card which is handling all that accelerated rendering -- is going to be very, very important.
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.
What about all us Windows, Mac, and Linux users? Well, now we can get in on the action, too, even though the Chrome Web Store loudly proclaims ** THIS APP REQUIRES A CHROME NOTEBOOK **!
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.
Your operating system can run processes in the background -- things like realtime antivirus protection and streaming movies and music around your home -- and so can Google Chrome. Background apps have existed in Chrome and Chromium for some time, but now that the Chrome Web Store is open and its apps are available for installation, Google has posted a blog about why backgrounding is cool.
It's really all about Chrome being your "OS" even if you're using a Windows or Mac computer. With the ability to run Web apps in the background and Native Client support headed to the beta and stable channels in relatively short order, Chrome Web Apps will soon be capable of doing many of the same things your traditional desktop apps can do.
Google's post talks about using backgrounding to issue notifications (as apps like TweetDeck and exfm do) or to prefetch data. There's really no end to the possibilities, and we're exited to see what the next generation of Chrome Web Apps can really do.
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.
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!
Did you know that Google alone is releasing four different versions of the Google Chrome browser regularly? And that is not even counting the Chromium releases that make up the core of the browser. This guide describes the differences between those releases. It also links to the official download pages where each build can be downloaded.
Google Chrome Stable: As the name suggests, a stable release of the web browser that has been tested extensively. Aimed at the end user and computing environments where only stable releases are used.
Google Chrome Beta: The beta releases often contain features that need to be tested by a wider audience. They are not stable yet but more thoroughly tested than the developer releases.
Google Chrome Dev: Google Chrome developer releases have been the cutting edge releases for some time. They get updated often, may contain new features but also bugs that need to be sorted out before the features are added to the beta channel.
Google Chrome Canary: The new cutting edge version of the Chrome browser. Canary releases are not as often releases as Chromium snapshots but more often than dev releases. These builds get the new features first before they are added to dev builds, providing they cause no problems.
Chromium: Chromium is the Open Source part of the Google browser. Chromium may get updated several times a day. The browser does not contain Google browser specific features.
Which Google Chrome browser is right for you?
That question is not that easy to answer. If you like to test new features you may want to consider downloading the dev or canary versions of the browser. Users who do not want to experience bugs may prefer the beta or stable releases.
Last month, we opened Google Cloud Print to users in the Chrome notebook pilot program. Google Cloud Print allows printing from any app on any device, OS or browser without the need to install drivers. Today, we are very pleased to announce the beta launch of Google Cloud Print for mobile documents and Gmail for mobile, which we will be rolling out to users throughout the next few days. To read more about how to use Google Cloud Print for these mobile use cases, read more in the Google Mobile blog.