Read this page! It has vital information about the extension architecture. Once you've finished this page and the Getting Started tutorial, you'll be all set to start writing extensions.
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. Extensions are essentially web pages, and they can use all the APIs that the browser provides to web pages, from XMLHttpRequest to JSON to HTML5 local storage.
Many extensions add UI to Google Chrome, in the form of toolstrips (toolbar additions), browser actions, or page actions (clickable badges in the address bar). Extensions can also interact programmatically with browser features such as bookmarks and tabs. To interact with web pages or servers, extensions can use content scripts or cross-origin XMLHttpRequests.
See the Developer's Guide for a complete list of extension features, with implementation details for each one.
Each extension has the following 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 ZIP file
that has a .crx suffix,
as described in Packaging.
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 subfolder named images.
<img src="images/myimage.png">
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 folder; it's the same as the relative URL.
[PENDING: Should mention/reflect/link to internationalization when it's ready.]
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.
Remember that extensions are essentially web pages.
The following figure shows what
a simple extension with a toolstrip
might look like
when there's a single browser window.
The toolstrip (T1) is at the bottom of the window.
The HTML and JavaScript code for T1
is in a web page
(toolstrip.html).
Each time the user creates a new window,
the browser creates new toolstrips, page actions, and so on.
Each new bit of UI gets its own web page,
which means that toolstrips (for example)
that are in different windows can have different states.
In the following figure,
the two toolstrips (T1 and T2)
are associated with two separate web pages,
both of which contain code from toolstrip.html.
This means that although both toolstrips use the same code,
one can be blue while the other is green.
If your extension's web pages need to communicate
or otherwise share information —
for example, if a browser event
can affect more than just one window's toolstrip —
the extension can use a background page.
The following figure shows a background page
(background.html)
that controls
the toolstrips in an extension.
The background page is an invisible page where you can 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.
For more information, see Background Pages.
If your extension needs to interact with web pages, then it needs a content script. Content scripts are JavaScript files that run in the context of web pages. Using the standard Document Object Model (DOM), content scripts can read details of the web pages the browser visits, and they can make changes to the pages.
In the following figure, the content script can read and modify the DOM for the web page displayed in Window 1. If the toolstrip's UI needs to change to reflect the web page's contents, the content script can request that change by sending a message to the parent extension.
[PENDING: Add overview of message passing.]
For more information, see Content Scripts.
The HTML pages within an extension often need to communicate. An example is when the background page tells UI pages (such as toolstrips) to update their appearance. Because all of an extension's pages execute in same process on the same thread, the pages can make direct function calls to each other.
To find pages in the extension, use
chrome.extension
methods such as
getViews(),
getBackgroundPage(),
and getToolstrips().
Once a page has a reference to other pages within the extension,
the first page can invoke functions on the other pages.
It can even manipulate their DOMs.
Here's an example of communication between toolstrips and the background page.
//In background.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.
Now that you've been introduced to extensions, you should be ready to write your own. Here are some ideas for where to go next: