Event pages keep apps and extensions efficient by allowing them to respond to a variety of events such as timers or navigation to a particular site, without having to remain running persistently. But what if you need to respond to something that occurs outside of Chrome, such as a news alert, a message sent to a user or a stock hitting a price threshold? Until now, you had to do this by repeatedly polling a server. This process consumed bandwidth and reduced the battery life of your users’ machines. For a more efficient solution, starting today you can use Google Cloud Messaging for Chrome (GCM) - across all channels of Chrome.

GCM will be familiar to developers who have used Google Cloud Messaging for Android. To send a message, all you need to do is:

1. Request a token (channel ID) via chrome.pushMessaging.getChannelId(). 
2. Pass the returned token to your server. 
3. Whenever you need to send a message to your app or extension, post the message along with the token to the GCM server-side API. 

Your message is then delivered in near real time to Chrome. This makes your event page wake up (if it’s not already running), and the message is delivered to your chrome.pushMessaging.onMessage listener.



To use GCM, your users must be signed into Chrome, as the service relies on an efficient push channel that’s only established for signed-in users. Messages are automatically delivered to all the devices where the user has signed in and installed your app/extension.

To add GCM to your app/extension, take a look at the overview of the service or start with some of the sample apps—and start pushing!

Posted by Mark Scott, Product Manager

Last year, Chrome introduced manifest V2 to Apps and Extension developers, which brings a variety of security and API improvements such as a default Content Security Policy. As of Chrome 18, manifest V1 was officially deprecated. At the time, we published our manifest version support schedule to give developers transparency and insight into our plans for migrating to the new version.

Today, we’re announcing a slight update to that schedule, to let developers know that they have until Monday, March 4, 2013 to make updates to their existing manifest V1-based items. After that date, the Chrome Web Store will block all updates to products based on manifest V1 unless the update includes switching it to manifest V2.

Developers are strongly encouraged to migrate their items to manifest V2 now. Follow the migration tutorial, and you can always contact us on the chromium-apps forum and our G+ page with any questions you may have.

Posted by Joe Marini, Developer Advocate

Even though Chrome extensions and legacy packaged apps are similar at a technical level, users have very different expectations for how extensions and apps should look and behave. Users expect extensions to interact with the whole browser, whereas they expect apps to act solely in their containing tab or window.

Until now, all Chrome legacy packaged apps could request the same permissions and use the same APIs as extensions to interact with Chrome. In order to make the capabilities of legacy packaged apps more closely align with user expectations, we’ve decided to limit the extensions permissions that legacy packaged apps can request.

Beginning this week, you won’t be able to publish legacy packaged apps in the Chrome Web Store that request any of the following permissions:
(a) any host permissions, including "< all urls >" 
(b) the top-level "content_scripts" key 
(c) the "debugger", "devtools", "pageCapture", "plugin", "proxy", "tabs'", "history", "webNavigation" permissions 
(d) the top-level "npapi" key 

Existing legacy packaged apps in the Chrome Web Store will not be affected, and those existing apps can continue to be updated without being subject to these new restrictions. 

If you have questions, please get in touch with us on the Chromium extensions or Chromium apps groups.

Posted by Peter Ludwig, Product Manager

If you’re a Chrome extensions power user, you may be familiar with a task manager that looks like this:



That’s a lot of extensions running! Most of the time, they’re probably just sitting idle, waiting for the user to interact with them. Do they really need to be running and using your memory all the time?

Over the last several months, we've been working on a new feature for the extension system called Event Pages that we think will help reduce the memory used by these idle extensions. 

How They Work 

Event pages are an evolution of background pages, with one major improvement: rather than running in the background all the time, an event page only runs when it is handling events. Once an event page becomes idle, it is unloaded, freeing memory until the next time it’s needed. Learn more from the event page documentation.

To help event pages support some important use cases, we’re also developing a few new APIs.

• The alarms API allows an extension to wake itself up at set times, to support features like periodically syncing data to the cloud. 
• Some new events let extensions know when they have been installed, or when their event page is being unloaded. 
• A declarative version of the webRequest API lets extensions do network interception without the need for a background page at all. 

Try it Out 

We plan to release event pages to Chrome’s beta and stable channels late this summer, but you can start experimenting with them on the developer channel today. Try converting your overweight extension to event pages, and let us know how it works.

Posted by Matt Perry, Software Engineer

Cross-posted from the Google Developers Blog.

A year ago, we released a preview of the PageSpeed Insights Chrome Developer Tools extension, which analyzes the performance of web pages and provides suggestions to make them faster. Today, we’re releasing version 2.0 of the PageSpeed Insights extension, available in the Chrome Web Store.

PageSpeed Insights analyzes all aspects of a web page load and points out the specific things you can do to make your page faster. For instance, PageSpeed Insights can inform you about an expensive JavaScript call that blocks the renderer for too long, remind you about that new photo on the front page of your web site that you might have forgotten to resize or optimize, or recommend changing the way you load third-party content so it no longer blocks the page load.

PageSpeed Insights for Chrome is a Chrome Developer Tools extension that analyzes all aspects of the page load, including resources, network, DOM, and the timeline. If you're already familiar with Chrome Developer Tools, you'll find that PageSpeed Insights integrates with a toolset you're already using.



Using technologies like Native Client, PageSpeed Insights is able to run the open-source PageSpeed Insights SDK securely and with the performance of native code. Leveraging the Insights SDK enables the Chrome extension to automatically optimize the images, CSS, JavaScript and HTML resources on your web page and provide versions of those resources that you can easily deploy on your website.

We hope you’ll give PageSpeed Insights for Chrome a try and start optimizing your web pages today. We’d love to hear from you, as always. Please try PageSpeed Insights for Chrome, and give us feedback on our mailing list with questions, comments, and new features you’d like to see.


Posted by Libo Song and Bryan McQuade, Software Engineers

Security is one of our core values, alongside speed, stability and simplicity. From day one, we’ve designed Chrome’s extension system with security in mind. Since we launched the extension system, the state of the art in web security has advanced with technologies like Content-Security-Policy (CSP). Extension developers have been able to opt into these features, and now we’re enabling these security features by default.

Unfortunately, securing extensions with CSP by default is incompatible with the legacy extension system. We’re passionate about extension compatibility, so we’re going to make this change gradually to minimize pain for users and developers.

Users can continue to install extensions that are available in the store regardless of whether they are secured with CSP or not. This means they will not lose any of the functionality they've added to Chrome.

Developers will be able to choose when to enable the new behavior. To ease the transition, we've introduced a new manifest version attribute in the extension manifest in Chrome 18 (currently in beta). When a developer updates his or her extension to use manifest_version 2, Chrome will enforce the following CSP policy by default:

script-src 'self'; object-src 'self' 

This policy imposes the following restrictions on extensions:

1. Extensions can no longer use inline scripts, such as <script> ... </script>. Instead, extensions must use out-of-line scripts loaded from within their package, such as <script src="foo.js"></script>. 
2. Extensions can no longer use eval(). Note: If you’re using eval to parse JSON today, we suggest using JSON.parse instead. 
3. Extensions can load plug-ins, such as SWF files, only from within their package or from a whitelist of HTTPS hosts. 

A recent study from researchers at UC Berkeley suggested that these restrictions, taken together, would substantially improve the security of the extension system:

These defenses are extremely effective: adopting one of the recommended CSPs would prevent 96% (49 out of 51) of the core extension vulnerabilities we found. 

For most extensions, updating them to manifest_version 2 will require the developer to move inline scripts out-of-line and to move scripts loaded from the network into the extension package. Developers are not required to update their extensions to manifest_version 2 immediately, but, over time, more of the extension ecosystem will encourage developers to update their extensions. For example, at some point, we’ll likely start requiring new extensions uploaded to the web store to use manifest_version 2. You can find a complete list of changes and more details about CSP in the extension documentation.

We expect these changes will make the security of Chrome’s extension system even better. If you have any feedback, please feel encouraged to email the extension developers mailing list.


Posted by Adam Barth, Chrome Security Engineer

Interested in making your Chrome Extension (or packaged app) talk using synthesized speech? Chrome now includes a Text-to-Speech (TTS) API that’s simple to use, powerful, and flexible for users.

Let’s start with the "simple to use" part. A few clever apps and extensions figured out how to talk before this API was available – typically by sending text to a remote server that returns an MP3 file that can be played using HTML5 audio. With the new API, you just need to add "tts" to your permissions and then write:

chrome.tts.speak('Hello, world!');

It’s also very easy to change the rate, pitch, and volume. Here’s an example that speaks more slowly:

chrome.tts.speak('Can you understand me now?', {rate: 0.6});

How about powerful? To get even fancier and synchronize speech with your application, you can register to receive callbacks when the speech starts and finishes. When a TTS engine supports it, you can get callbacks for individual words too. You can also get a list of possible voices and ask for a particular voice – more on this below. All the details can be found in the TTS API docs, and we provide complete example code on the samples page.

In fact, the API is powerful enough that ChromeVox, the Chrome OS screen reader for visually impaired users, is built using this API.

Here are three examples you can try now:

    TTS Demo (app)
    Talking Alarm Clock (extension)
    SpeakIt (extension)

Finally, let's talk about flexibility for users. One of the most important things we wanted to do with this API was to make sure that users have a great selection of voices to choose from. So we've opened that up to developers, too.

The TTS Engine API enables you to implement a speech engine as an extension for Chrome. Essentially, you provide some information about your voice in the extension manifest and then register a JavaScript function that gets called when the client calls chrome.tts.speak. Your extension then takes care of synthesizing and outputting the speech – using any web technology you like, including HTML5 Audio, the new Web Audio API, or Native Client.

Here are two voices implemented using the TTS Engine API that you can install now:

    Lois TTS - US English
    Flite SLT Female TTS - US English

These voices both use Native Client to synthesize speech. The experience is very easy for end users: just click and install one of those voices, and immediately any talking app or extension has the ability to speak using that voice.

If a user doesn't have any voices installed, Chrome automatically speaks using the native speech capabilities of your Windows or Mac operating system, if possible. Chrome OS comes with a built-in speech engine, too. For now, there's unfortunately no default voice support on Linux – but TTS is fully supported once users first install a voice from the Chrome Web Store.

Now it's your turn: add speech capability to your app or extension today! We can't wait to hear what you come up with, and if you talk about it, please add the hashtag #chrometts so we can join the conversation. If you have any feedback, direct it to the Chromium-extensions group.

Posted by Dominic Mazzoni, Software Engineer

Are you already a happy user of Chrome Developer Tools but always wanted that particular feature added to make you even more productive? Then we have some exciting news for you: our developer tools are now extensible!

You can now add new panels and sidebar section panes, retrieve network requests data, evaluate scripts on the page being inspected, and add custom audit rules.



The extension support is still experimental, but we wanted to let you know early, so we can incorporate your feedback before releasing the APIs.

Here’s how to get started with writing extensions for Chrome Developer Tools:

• Use the dev channel of Chrome as the APIs are still under development;
• Enable experimental extension APIs using the chrome://flags page;
• List experimental in the permissions list of your extension;
• Add a devtools_page field to your extension’s manifest, e.g:

{

"name": ...

"minimum_chrome_version": "14.0",

"devtools_page": "devtools.html",

"permissions": [ "experimental" ... ],

...

}

The developer tools extension pages get access to the chrome.experimental.devtools.* APIs which are described further in our docs. Be sure to check out the sample extensions, which include extensions for jQuery and FirePHP users and a simple audit extension that finds broken links.

For a richer example, you can also check out Page Speed for Chromium, which uses the extensions API to provide Page Speed suggestions right in the Chrome Devtools UI.

We’re looking forward to seeing your feedback on the APIs and, of course, cool extensions coming to life!

Posted by Andrey Kosyakov, Software Engineer

In Chrome 13, we added some new capabilities to content scripts and proxy management.

First, you can now make cross-origin XMLHttpRequest calls with the privileges of the extension directly from your content script. You will no longer need to relay these requests through a background page; this should simplify your code. In some cases, it may even eliminate your need to use a background page. Here’s a sample extension which demonstrates the old way a content script could make a cross domain request. As you can see, the extension required a background page to route the cross-origin calls through a chrome.extension.onRequest listener. Using the new content script cross-origin capabilities, we were able to successfully rewrite the extension to completely eliminate the background page requirement. This reduces the memory required to run the extension, and reduces code complexity as well. This also means that Greasemonkey scripts that use GM_xmlhttpRequest - such as the classic Book Burro - will now work in Chrome.

Second, we improved how match patterns work. Until this release you could specify a matches array for your content script - the URLs over which it should operate. In Chrome 13 you can now also specify an exclude_matches array, where you can indicate the pages in which your content scripts should not work. This should allow more precise targeting of your content script.

Finally, we added support for the @run-at command for imported Greasemonkey scripts, so you can control when your script is loaded in the same way you’ve been able to do for content scripts. Running scripts at different points in a page's lifecycle can enable additional functionality. For example, we've written a script which runs at "document-start" and lists all of the HTTP resources included in the current page.

In addition to these improvements to scripts, we’ve been working hard to allow extensions to manage Chrome’s proxy settings using different configuration options. With the Proxy Extension API, you can now configure proxy settings by choosing from several options including auto detection, the host OS’s system default, PAC scripts or fixed ProxyRules.

These new configuration options allow for more fine grained proxy controls, which we invite you to try out. There are already several 3rd party extensions available in the Chrome Web Store that showcase the API and its new capabilities, including Proxy Anywhere and Proxy SwitchyPlus.

Let us know what you think of these new features and what else you might like to see us do by joining the discussion at [email protected].

Posted by Tessa MacDuff and Mihai Parparita, Software Engineers

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

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

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

It’s hard to believe, but it’s already been a full year since we launched the Google Chrome extensions gallery.

It’s been a busy twelve months:

• The gallery has grown to over 8,500 extensions and 1,500 themes.
• A third of Chrome users have at least one extension installed.
• Over 70 million extensions and themes have been installed.

On the client side, we added features like:

• New APIs for things like context menus, history, and cookies.
• Integration between extensions and HTML5 features like notifications and geolocation.
• Extension sync, so your favorite extensions are always with you.
• Native support for Greasemonkey user scripts.

Looking forward, we’re very excited about the Chrome Web Store, where developers will be able to easily sell their apps, extensions, and themes.

And we’re not going to slow down on the features, either. The next Chrome release will add API support for the omnibox and pinned tabs. Beyond that, we’re hard at work on popular requests like network interception and download management APIs, as well as new experimental APIs for sidebars and development tools.

Thanks for all your support over the last year, from bug reports to testing new APIs. It’s been a bit frantic at times, but mostly it’s been fun.

Posted by Aaron Boodman, Software Engineer

Since we launched the Google Chrome extension system, one of the most frequent requests we’ve gotten is to add the ability to integrate with the context menu (the menu that pops up when you right-click on a link, image, or web page).

Now in Google Chrome Beta, developers can do just that. The new context menu API allows extension developers to register menu items for all pages or for a subset of pages. Developers can also register menu items for specific operations, like right-clicking on an image or movie. For example, you could create an extension that makes it easy for users to share interesting images from images.google.com with their friends on Google Buzz.

Some users have lots of extensions installed. To help these users avoid ending up with gigantic unwieldy context menus, Google Chrome automatically groups multiple menu items from the same extension into a sub-menu.

We’d also like to announce two new experimental APIs. These APIs aren’t quite ready for prime-time yet, but we’re really excited about them and couldn’t wait to get your feedback.

• The omnibox API allows extension developers to integrate with the browser’s omnibox. With this API, you can build custom search support for your favorite website, keyboard macros to automate tasks, or even a chat client right into the omnibox.
• The infobars API allows extension developers to display infobars across the top of a tab. These infobars are built using normal HTML, so they can be heavily customized and interactive.

For the complete list of new extension APIs in Google Chrome beta, see the docs. And let us know if you make something cool. If we like it, we’ll send you a free extensions hoodie and may even feature you in the gallery.

We look forward to seeing what you come up with!

Posted by Aaron Boodman, Software Engineer

Personalizing the web to match the needs and abilities of users is a big part of improving overall web accessibility. While we continue to work hard on making core Google Chrome more accessible, we're really excited about using browser extensions to improve the accessibility of the web for millions of users.

There are already some extensions among the more than 5,000 in the gallery that can benefit users with special needs. Some of these extensions use Chrome APIs and content scripts to alter the browser and manipulate the DOM of pages, offering users almost unlimited flexibility for viewing the web. Other extensions choose to implement altenative workflows, instead of adapting existing web page UIs, to give users faster access to content. These extensions benefit not just users of assistive technologies like screen readers but everyone who prefers access modes like keyboard shortcuts and captions.

If you are interested in making your extensions more accessible, we’ve created a new Accessibility implementation guide in the Chrome Extensions Developer's Guide that gives you an overview of accessibility best practices such as keyboard navigation, color contrast and text magnification. We’ve also open sourced the code behind ChromeVis, a new extension for users with low vision, so that you can use some of its code for manipulating text selection and magnification in your own extensions.



Already the NPR team has implemented some accessibility best practices in their extension. We hope to see more extensions adopting them. From our end, we're sponsoring a Summer of Code project to produce an extension that helps users produce custom style sheets and plan to create additional extensions that make navigating the web through Chrome easier.

We've also set up a Google Moderator topic where everyone can submit ideas for extensions that improve web accessibility. We hope these ideas will inspire extensions developers who are looking to create something useful for the community.

Stay tuned for future updates about Chrome Extensions and accessibility!

Posted by Rachel Shearer, Software Engineer

When we first released extension support in Chromium, we left out all support for running extensions in incognito mode. This meant I had to live without handy extensions like Mouse Stroke and PasswordMaker (shameless plug) whenever I opened an incognito window, and that made me sad. When your muscle memory is trained to expect certain features, it's pretty jarring to find them missing. So in the latest stable version of Google Chrome, I added support for running extensions while in incognito.

One of the main reasons we delayed adding incognito support was that Chrome has no way to ensure that extensions obey the incognito rules: in short, that your browsing data is not saved after you close the incognito window. After much debate, we finally decided to let users decide which extensions they were comfortable using in incognito. You should only enable extensions that you trust and that don't save sensitive information. For example, an extension named Save All Your History would probably not be a good idea to run in incognito, since it would defeat the entire purpose of opening an incognito window. (This is not always the case: if the extension is written with incognito support in mind, it could avoid saving sensitive information, but it is up to the extension developer.)

To allow an extension to run while incognito, open the Extensions management page (accessible from the Tool menu -> Extensions). Each extension has an option to "Allow in incognito". Turning this on will let the extension display page and browser actions in incognito windows, and give them access to browser information originating from an incognito tab. It's just as easy to remove this access any time by following the same steps and unchecking the "Allow in incognito" option.


Note to extension developers: Try to be a good citizen by only persisting browsing information collected from non-incognito windows. You can determine this by examining the incognito property on tab and window objects, or checking chrome.extension.inIncognitoTab from within a content script. For more information, see the extension documentation section on Saving data and incognito mode.

Posted by Matt Perry, Software Engineer

Google I/O recap

If you missed the Day 1 keynote this year, it was all about the open web. There were some amazing demos from Mugtug, TweetDeck, Adobe, and Sports Illustrated demonstrating the full potential of HTML5. There was a preview of WebM/VP8, a high-quality, open, and web-optimized video format. We saw the announcement of the Chrome Web Store, which later this year will provide a new and exciting channel for developers to distribute their web apps and reach new users. We also launched the Google Font API, which allows you to add high-quality web fonts to any web page. Lastly, there were all of the great Chrome sessions. Videos have been posted on the Google I/O website:

• Developing with HTML5
• Developing web apps for the Chrome Web Store
• Beyond JavaScript: programming the web with native code
• Chrome extensions - how-to
• Google Chrome's Developer Tools
• Using Google Chrome Frame
• HTML5 status update
• WebM Open Video Playback in HTML5

What's new for developers in Google Chrome?

The Google Chrome Dev channel is now up to 6.0.422.0. It includes a bunch of new features to think about when developing your apps:

• Desktop notifications (new since our last developer update)
• File API and FileReader API: Drag and drop files from the desktop to the browser!
• Native Client (NaCl) SDK and ports: Run with --enable-nacl.
• HTML5 sandbox attribute
• Integrated Flash Player plugin: Run dev channel with --enable-internal-flash.

In addition to the above, there are new experimental extension APIs:

• chrome.experimental.cookies
• chrome.experimental.clipboard
• chrome.experimental.omnibox

You can try out these features by launching a Dev-channel version of Google Chrome with the --enable-experimental-extension-apis flag and adding the ‘experimental’ permission in your manifest.json file. Please keep in mind that these features are still under development and are not 100% stable yet.

Upcoming developer events

For those of you based in New York, there’s an upcoming Chrome Extensions hackathon in our local office on June 10, 2010. We also have a five day DevFest starting June 28, 2010 in Sydney, Australia. Google Chrome will be featured on Wednesday, June 30. Stay tuned for more details!

For the latest news and upcoming developer events, subscribe to this blog and follow us on Twitter @ChromiumDev.

Posted by Eric Bidelman, Google Chrome Developer Relations

What's New in Google Chrome?

The Google Chrome Dev channel has been updated to 5.0.356.2 for all platforms since our last developer post. It includes a few new goodies for developers:

• Geolocation API: Run with the --enable-geolocation flag.
• Incognito extensions
• Unpacked extensions are now remembered across browser restarts.
• Favicons for extension pages (define with a 16x16 image in your manifest.json).
• setPopup() was added to browserAction and pageAction for dynamically changing which popup to show based on the selected tab.

Please keep in mind that these features are still under development and are not 100% stable yet. In addition to the above, there are a few new experimental features baking in /trunk. You can try them out with the --enable-experimental-extension-apis flag:

• chrome.experimental.infobars
• chrome.experimental.contextMenu

Samples and Tutorials

We’ve added a few new sample extensions tutorials to get you started:

• Sample and tutorial to demonstrate using Google Analytics in your extensions
• Extension to display, create, and update your Google Documents
• Tutorial to demonstrate using OAuth in your extensions

Remember to follow us on Twitter: @ChromiumDev!

Posted by Eric Bidelman, Developer Advocate

You might have already noticed this, but we now have some APIs that we’re referring to as experimental. The idea is that we can add new APIs to the platform that may not be ready for prime time. This allows you to play with these APIs and give us feedback before they’re final, which in turn helps us get them out to everybody more quickly.

Our first two experimental APIs — chrome.experimental.history and chrome.experimental.processes — are available on the dev channel. The history API lets you query and modify the user’s browsing history. When it’s finalized, we’ll also allow you to replace the history page with your own, just like you can replace the new tab page today. The processes API allows access to information about Google Chrome’s process model, including process IDs and the CPU usage of individual tabs. The processes API is incomplete, but you can see upcoming features in its design doc.

These APIs have a few major limitations. First, to use an experimental API you must add a command-line flag when you start Google Chrome (--enable-experimental-extension-apis). Second, you can’t upload extensions that use experimental APIs to the Google Chrome Extensions Gallery. Finally, these APIs will change in incompatible ways, so the code that you write today isn’t guaranteed to work tomorrow.

What this really means is that these APIs are only useful for you to play with. You won’t be able to share extensions that use these APIs with a lot of people. However, we’d really like you to try them out and give us feedback. Doing so will help us release the APIs more quickly and make sure they do everything you need. Playing with the experimental APIs is also a way for you to get experience with them before most other developers.

We expect to add more experimental APIs over time, so keep an eye out for future announcements.

Posted by Erik Kay, Software Engineer

At the end of 2009, we traveled around the world — to the Czech Republic, Russia, and Argentina — meeting with developers and talking to them about Google Chrome Extensions and HTML5.

In the first leg of our trip, we headed to Europe for Google Developer Day Prague and Google Developer Day Moscow on November 6th and 10th. Google Developer Days are one-day events featuring seminars and office hours about Google developer products like Android, Google App Engine, and of course Google Chrome! More than 800 developers were on hand in Prague and more than 1,500 in Moscow to learn, among lots of other things, how to develop extensions for Google Chrome. Below is video of the talk Brian gave about extensions in Moscow. You can also watch video of this talk translated into Russian or video of a similar talk from Prague and view slides from Prague or slides from Moscow.

Our next and last stop was Buenos Aires for Google DevFest Argentina. Google DevFests are more focused versions of Google Developer Days. On November 17th, another 800 or so developers attended this event. There, we covered the Google Chrome platform in a couple sessions — on HTML5 and extensions. Below are slides from the talk Mihai gave on HTML5. You can also view slides from the extension talk.

HTML5 and Google Chrome - DevFest09

View more documents from mihaiionescu.

For us, the best part of being at these events was seeing and hearing about all the interest in Google Chrome from developers everywhere and all the cool things those developers are building with the browser. If you'd like to get involved too, there are a bunch of community-organized Google Chrome events going on now. Check out the Google Technology User Group site to find a group or Meetup to find an event near you. And if there isn't a nearby group or event already, why not create your own! We have a collection of hackathon-in-a-box resources to help you do so.

Posted by Brian Kennish and Mihai Ionescu, Developer Advocates