Please read this page; it has vital information about the extension architecture. If you get bored or restless, take a break! We suggest bouncing between this page and tutorials such as Getting Started and Debugging.

The basics

An extension is a zipped bundle of files — HTML, CSS, JavaScript, images, and anything else you need — that adds functionality to the Google Chrome browser. Because an extension is just a special kind of web page, it can use all the APIs that the browser provides to web pages and apps, from XMLHttpRequest to JSON to localStorage.

Extensions can add UI to Google Chrome, in the form of toolstrips (toolbar additions) and page actions (clickable badges in the address bar). Extensions can also interact programmatically with browser features such as bookmarks and tabs.

To find a complete list of extension features, with implementation details for each one, see the Developer's Guide.

Files

Each extension has the following files:

• A manifest file
• One or more HTML files (unless the extension is a theme)
• Optional: One or more JavaScript files
• Optional: Any other files your extension needs — for example, image files

While you're working on your extension, you put all these files into a single folder. When you distribute your extension, the contents of the folder are packaged into a special zipfile that has a .crx suffix, as described in Packaging.

Referring to files

You can put any file you like into an extension, but how do you use it? Usually, you can refer to the file using a relative URL, just as you would in an ordinary HTML page. Here's an example of referring to a file named myimage.png that's in a subdirectory named images.

<img src="images/myimage.png" style="width:auto; height:auto">

As you might notice while you use the Google Chrome debugger, every file in an extension is also accessible by an absolute URL like this:

chrome-extension://<extensionID>/<pathToFile>

In that URL, the <extensionID> is a unique identifier that the extension system generates for each extension. You can see the IDs for all your loaded extensions by going to the URL chrome://extensions/. The <pathToFile> is the location of the file under the extension's top directory; it's the same as the relative URL.

[QUESTION TO REVIEWERS: Is this section too big/detailed? It seems a little weird to mention absolute URLs with mentioning getURL and when you'd need it. What's the motivation for covering absolute URLs? Is the debugger the place you're most likely to see them?]

For example, assume your extension has the ID aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa and the files shown in the following figure:

[PENDING: convert this into a figure]
toolstrip.html
styles.css
images:
  myimage.png
  ...
other:
  more.html
  morestyles.css
  ...

Here's a table that shows the relative and absolute URLs of these files. Keep in mind that the relative URL is the same no matter where you're using it — the relative URL of myimage.png is images/myimage.png, no matter whether it's being used by toolstrip.html or other/more.html.

[PENDING: Mention/reflect/link to internationalization]

The manifest file

The manifest file, called manifest.json, gives information about the extension, such as the most important files and the capabilities that the extension might use. Here's a typical manifest file for a toolstrip that uses information from google.com:

{
  "name": "My Extension",
  "version": "2.1",
  "description": "Gets information from Google.",
  "update_url": "http://example.com/mytestextension/updates.xml",
  "permissions": ["http://*.google.com/", "https://*.google.com/"],
  "toolstrips": ["my_toolstrip.html"]
}

For details, see Manifest Files.

Architecture

The following pictures shows the web pages associated with a typical extension (in this case, a simple toolstrip). The first figure shows what an extension might look like when there's a single browser window.

[PENDING: image goes here]

The next figure shows that all the code in the extension's main HTML file is duplicated each time you create a new window. In other words, each window has its own widgets for the extension, which means each window adds another web page for that extension.

[PENDING: image goes here]

To more easily coordinate all these web pages and to avoid duplication, you should design your extension so that most of the code — especially the state of the extension — is in a background page, as shown in the following figure.

[PENDING: image goes here.]

The background page

Any non-trivial extension can (and probably should) have a background page. The background page is an invisible page where you put the main logic of the extension. The extension's other pages should have only the code that's necessary to show the state of the extension and to get input from the user.

An extension's background page exists before any of the extension's other pages exist. It continues to exist as long as the browser is running and the extension is installed, even if other pages and windows go away.

Your extension's UI — its toolstrips, page actions, and so on — should be dumb views. When the view needs some state, it should request it from the background page. When the background page notices some state change, it should update all the views.

For more information, see Background Pages.

Content scripts

If you want your extension to interact with web pages, you need a content script. Content scripts are JavaScript files that run in the context of web pages. By using the standard Document Object Model (DOM), they can read details of the web pages the browser visits, and they can make changes to the pages.

[PENDING: add an architectural figure here, showing the extension's pages, a web page, and the content script interacting with the web page. explain the figure.]

For more information, see Content Scripts.

Communication

Two kinds of communication happen within an extension:

• Communication between pages in the extension.
  For example, sometimes the background page needs to update all the UI pages to reflect a change in the extension's state.
• Communication between content scripts and the extension.
  For example, [PENDING: example goes here]. See Content Scripts for information about this type of communication.

Here are some keys to communication between an extension's pages:

• All the extension's pages execute in same process, on the same thread.
• Extension pages can use chrome.extension methods such as getViews(), getBackgroundPage(), and getToolstrips() to get access to the extension's pages.
• Once you have references to an extension's pages, you can manipulate the DOM for each page.
• You can also make direct function calls to the pages, as shown in the following example.

Here's an example of communication between toolstrips and the background page.

//In background_page.html:
function updateUI(checked) {
  var toolstrips = chrome.extension.getToolstrips();
  for (var i in toolstrips) {
    if (toolstrips[i].enableCheckbox)
      toolstrips[i].enableCheckbox(checked);
  }
}

//In toolstrip.html:
function enableCheckbox(checked) {
  var cb = document.getElementById('checkbox');
  cb.checked = checked;
}

A good summary of communication mechanisms is at http://www.chromeplugins.org/google/plugins-development/communication-7883.html.

Summary

[ PENDING: wrap it up. suggest where to go next. Probably: Getting Started, Debugging, Developer's Guide. ]