tut_content_scripts.html

---
layout: default-withsidebar
title: Content scripts
copyright: opera-google-ccby
originalsource: http://developer.chrome.com/trunk/extensions/content_scripts.html
---

			<div id="gc-pagecontent">
				<div id="toc">
					<h2>Contents</h2>
					<ol>
						<li>
							<a href=#registration>Manifest</a>
							<ol>
								<li><a href=#match-patterns-globs>Match patterns and globs</a></li>
							</ol>
						</li>
						<li>
							<a href=#pi>Programmatic injection</a>
						</li>
						<li>
							<a href=#execution-environment>Execution environment</a>
						</li>
						<li>
							<a href=#host-page-communication>Communication with the embedding page</a>
						</li>
						<li>
							<a href=#security-considerations>Security considerations</a>
						</li>
						<li>
							<a href=#extension-files>Referring to extension files</a>
						</li>
						<li>
							<a href=#examples> Examples </a>
						</li>
						<li>
							<a href=#videos> Videos </a>
						</li>
					</ol>
				</div>




<p>
Content scripts are JavaScript files that run in the context of web pages.
By using the standard
<a href="http://www.w3.org/TR/DOM-Level-2-HTML/">Document
Object Model</a> (DOM),
they can read details of the web pages the browser visits,
or make changes to them.
</p>

<p>
Here are some examples of what content scripts can do:
</p>

<ul>
	<li>Find unlinked URLs in web pages and convert them into hyperlinks
	<li>Increase the font size to make text more legible
	<li>Find and process <a href="http://microformats.org/">microformat</a> data in the DOM
</ul>

<p>
However, content scripts have some limitations.
They <b>cannot</b>:
</p>

<ul>
	<li>
		Use chrome.* APIs
		(except for parts of
		<a href="https://developer.chrome.com/extensions/extension"><code>chrome.extension</code></a>)
	</li>
	<li>
		Use variables or functions defined by their extension's pages
	</li>
	<li>
		Use variables or functions defined by web pages or by other content scripts
	</li>
</ul>

<p>
These limitations aren't as bad as they sound.
Content scripts can <em>indirectly</em> use the chrome.* APIs,
get access to extension data,
and request extension actions
by exchanging <a href="tut_message_passing.html">messages</a>
with their parent extension.
Content scripts can also
make cross-site XMLHttpRequests
to the same sites as their parent extensions,
and they can
<a href="#host-page-communication">communicate with web pages</a>
using the shared DOM.
For more insight into what content scripts can and can't do,
learn about the
<a href="#execution-environment">execution environment</a>.
</p>

<h2 id="registration">Manifest</h2>

<p>If your content script's code should always be injected,
register it in the
<a href="manifest.html">extension manifest</a>
using the <code>content_scripts</code> field,
as in the following example.
</p>

<pre class="prettyprint">{
	"name": "My extension",
	...
	<b>"content_scripts": [
		{
			"matches": ["http://www.google.com/*"],
			"css": ["mystyles.css"],
			"js": ["jquery.js", "myscript.js"]
		}
	]</b>,
	...
}</pre>

<p>
If you want to inject the code only sometimes,
use the
<a href="manifest.html#permissions"><code>permissions</code></a> field instead,
as described in <a href="#pi">Programmatic injection</a>.
</p>

<pre class="prettyprint">{
	"name": "My extension",
	...
	<b>"permissions": [
		"tabs", "http://www.google.com/*"
	]</b>,
	...
}</pre>

<p>
Using the <code>content_scripts</code> field,
an extension can insert multiple content scripts into a page;
each of these content scripts can have multiple JavaScript and CSS files.
Each item in the <code>content_scripts</code> array
can have the following properties:</p>

<table class="simple">
	<tr>
		<th>Name</th>
		<th>Type</th>
		<th>Description</th>
	</tr>
	<tr>
		<td><code>matches</code></td>
		<td>array of strings</td>
		<td><em>Required.</em>
		Specifies which pages this content script will be injected into.
		See <a href="tut_match_patterns.html">Match Patterns</a>
		for more details on the syntax of these strings
		and <a href="#match-patterns-globs">Match patterns and globs</a>
		for information on how to exclude URLs.</td>
	</tr>
	<tr>
		<td><code>exclude_matches</code></td>
		<td>array of strings</td>
		<td><em>Optional.</em>
		Excludes pages that this content script would otherwise be
		injected into.
		See <a href="tut_match_patterns.html">Match Patterns</a>
		for more details on the syntax of these strings
		and <a href="#match-patterns-globs">Match patterns and globs</a>
		for information on how to exclude URLs.</td>
	</tr>
	<tr>
		<td><code>css<code></td>
		<td>array of strings</td>
		<td><em>Optional.</em>
		The list of CSS files to be injected into matching pages. These are injected in the order they appear in this array, before any DOM is constructed or displayed for the page.</td>
	</tr>
	<tr>
		<td><code>js<code></td>
		<td><nobr>array of strings</nobr></td>
		<td><em>Optional.</em>
		The list of JavaScript files to be injected into matching pages. These are injected in the order they appear in this array.</td>
	</tr>
	<tr id="run_at">
		<td><code>run_at<code></td>
		<td>string</td>
		<td><em>Optional.</em>
		Controls when the files in <code>js</code> are injected. Can be "document_start", "document_end", or "document_idle". Defaults to "document_idle".

		<br><br>

		In the case of "document_start", the files are injected after any files from <code>css</code>, but before any other DOM is constructed or any other script is run.

		<br><br>

		In the case of "document_end", the files are injected immediately after the DOM is complete, but before subresources like images and frames have loaded.

		<br><br>

		In the case of "document_idle", the browser chooses a time to inject scripts between "document_end" and immediately after the <code><a href="http://www.whatwg.org/specs/web-apps/current-work/#handler-onload">window.onload</a></code> event fires. The exact moment of injection depends on how complex the document is and how long it is taking to load, and is optimized for page load speed.

		<br><br>

		<b>Note:</b> With "document_idle", content scripts may not necessarily receive the <code>window.onload</code> event, because they may run after it has
		already fired. In most cases, listening for the <code>onload</code> event is unnecessary for content scripts running at "document_idle" because they are guaranteed to run after the DOM is complete. If your script definitely needs to run after <code>window.onload</code>, you can check if <code>onload</code> has already fired by using the <code><a href="http://www.whatwg.org/specs/web-apps/current-work/#dom-document-readystate">document.readyState</a></code> property.</td>
	</tr>
	<tr>
		<td><code>all_frames<code></td>
		<td>boolean</td>
		<td><em>Optional.</em>
		Controls whether the content script runs in all frames of the matching page, or only the top frame.
		<br><br>
		Defaults to <code>false</code>, meaning that only the top frame is matched.</td>
	</tr>
	<tr>
		<td><code>include_globs</code></td>
		<td>array of string</td>
		<td><em>Optional.</em>
		Applied after <code>matches</code> to include only those URLs that also match this glob. Intended to emulate the <a href="http://wiki.greasespot.net/Metadata_Block#.40include"><code>@include</code></a> Greasemonkey keyword.
		See <a href="#match-patterns-globs">Match patterns and globs</a> below for more details.</td>
	</tr>
	<tr>
		<td><code>exclude_globs</code></td>
		<td>array of string</td>
		<td><em>Optional.</em>
		Applied after <code>matches</code> to exclude URLs that match this glob.
		Intended to emulate the <a href="http://wiki.greasespot.net/Metadata_Block#.40include"><code>@exclude</code></a> Greasemonkey keyword.
		See <a href="#match-patterns-globs">Match patterns and globs</a> below for more details.</td>
	</tr>
</table>

<h3 id="match-patterns-globs">Match patterns and globs</h3>

<p>
The content script will be injected into a page if its URL matches any <code>matches</code> pattern and any <code>include_globs</code> pattern, as long as the URL doesn't also match an <code>exclude_matches</code> or <code>exclude_globs</code> pattern.

Because the <code>matches</code> property is required, <code>exclude_matches</code>, <code>include_globs</code>, and <code>exclude_globs</code> can only be used to limit which pages will be affected.
</p>

<p>
For example, assume <code>matches</code> is <code>["http://*.nytimes.com/*"]</code>:
</p>
<ul>
<li>If <code>exclude_matches</code> is <code>["*://*/*business*"]</code>, then the content script would be injected into "http://www.nytimes.com/health" but not into "http://www.nytimes.com/business".</li>
<li>If <code>include_globs</code> is <code>["*nytimes.com/???s/*"]</code>, then the content script would be injected into "http:/www.nytimes.com/arts/index.html" and "http://www.nytimes.com/jobs/index.html" but not into "http://www.nytimes.com/sports/index.html".</li>
<li>If <code>exclude_globs</code> is <code>["*science*"]</code>, then the content script would be injected into "http://www.nytimes.com" but not into "http://science.nytimes.com" or "http://www.nytimes.com/science".</li>
</ul>
<p>

<p>
Glob properties follow a different, more flexible syntax than <a href="tut_match_patterns.html">match patterns</a>.  Acceptable glob strings are URLs that may contain "wildcard" asterisks and question marks. The asterisk (*) matches any string of any length (including the empty string); the question mark (?) matches any single character.
</p>

<p>
For example, the glob "http://???.example.com/foo/*" matches any of the following:
</p>
<ul>
	<li>"http://www.example.com/foo/bar"</li>
	<li>"http://the.example.com/foo/"</li>
</ul>
<p>
However, it does <em>not</em> match the following:
</p>
<ul>
	<li>"http://my.example.com/foo/bar"</li>
	<li>"http://example.com/foo/"</li>
	<li>"http://www.example.com/foo"</li>
</ul>

<h2 id="pi">Programmatic injection</h2>

<p>
Inserting code into a page programmatically is useful
when your JavaScript or CSS code
shouldn't be injected into every single page
that matches the pattern &mdash;
for example, if you want a script to run
only when the user clicks a browser action's icon.
</p>

<p>
To insert code into a page,
your extension must have
cross-origin permissions
for the page.
It also must be able to use the <code>chrome.tabs</code> module.
You can get both kinds of permission
using the manifest file's
<a href="manifest.html#permissions">permissions</a> field.
</p>

<p>
Once you have permissions set up,
you can inject JavaScript into a page by calling
<a href="https://developer.chrome.com/extensions/tabs#method-executeScript">tabs.executeScript</a>.
To inject CSS, use
<a href="https://developer.chrome.com/extensions/tabs#method-insertCSS">tabs.insertCSS</a>.
</p>

<p>
The following code
(from the
<a href="http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/examples/api/browserAction/make_page_red/">make_page_red</a> example)
reacts to a user click
by inserting JavaScript into the current tab's page
and executing the script.
</p>

<pre class="prettyprint">
<em>/* in background.html */</em>
chrome.browserAction.onClicked.addListener(function(tab) {
	chrome.tabs.executeScript(null,
													 {code:"document.body.bgColor='red'"});
});

<em>/* in manifest.json */</em>
"permissions": [
	"tabs", "http://*/*"
],
</pre>

<p>
When the browser is displaying an HTTP page
and the user clicks this extension's browser action,
the extension sets the page's <code>bgcolor</code> property to 'red'.
The result,
unless the page has CSS that sets the background color,
is that the page turns red.
</p>

<p>
Usually, instead of inserting code directly (as in the previous sample),
you put the code in a file.
You inject the file's contents like this:
</p>

<pre class="prettyprint">chrome.tabs.executeScript(null, {file: "content_script.js"});</pre>


<h2 id="execution-environment">Execution environment</h2>

<p>Content scripts execute in a special environment called an <em>isolated world</em>. They have access to the DOM of the page they are injected into, but not to any JavaScript variables or functions created by the page. It looks to each content script as if there is no other JavaScript executing on the page it is running on. The same is true in reverse: JavaScript running on the page cannot call any functions or access any variables defined by content scripts.

<p>For example, consider this simple page:

<pre class="prettyprint">hello.html
==========
&lt;html&gt;
	&lt;button id="mybutton"&gt;click me&lt;/button&gt;
	&lt;script&gt;
		var greeting = "hello, ";
		var button = document.getElementById("mybutton");
		button.person_name = "Bob";
		button.addEventListener("click", function() {
			alert(greeting + button.person_name + ".");
		}, false);
	&lt;/script&gt;
&lt;/html&gt;</pre>

<p>Now, suppose this content script was injected into hello.html:

<pre class="prettyprint">contentscript.js
================
var greeting = "hola, ";
var button = document.getElementById("mybutton");
button.person_name = "Roberto";
button.addEventListener("click", function() {
	alert(greeting + button.person_name + ".");
}, false);
</pre>

<p>Now, if the button is pressed, you will see both greetings.

<p>Isolated worlds allow each content script to make changes to its JavaScript environment without worrying about conflicting with the page or with other content scripts. For example, a content script could include JQuery v1 and the page could include JQuery v2, and they wouldn't conflict with each other.

<p>Another important benefit of isolated worlds is that they completely separate the JavaScript on the page from the JavaScript in extensions. This allows us to offer extra functionality to content scripts that should not be accessible from web pages without worrying about web pages accessing it.


<h2 id="host-page-communication">Communication with the embedding page</h2>

<p>Although the execution environments of content scripts and the pages that host them are isolated from each other, they share access to the page's DOM. If the page wishes to communicate with the content script (or with the extension via the content script), it must do so through the shared DOM.</p>
<p>An example can be accomplished using window.postMessage (or window.webkitPostMessage for Transferable objects):</p>
<pre class="prettyprint">contentscript.js
================
var port = chrome.runtime.connect();

window.addEventListener("message", function(event) {
		// We only accept messages from ourselves
		if (event.source != window)
			return;

		if (event.data.type &amp;&amp; (event.data.type == "FROM_PAGE")) {
			console.log("Content script received: " + event.data.text);
			port.postMessage(event.data.text);
		}
}, false);</pre>
<pre class="prettyprint">http://foo.com/example.html
===========================
document.getElementById("theButton").addEventListener("click", function() {
		window.postMessage({ type: "FROM_PAGE", text: "Hello from the webpage!" }, "*");
}, false);</pre>
<p>In the above example, example.html (which is not a part of the extension) posts messages to itself, which are intercepted and inspected by the content script, and then posted to the extension process. In this way, the page establishes a line of communication to the extension process. The reverse is possible through similar means.</p>

<h2 id="security-considerations">Security considerations</h2>

<p>When writing a content script, you should be aware of two security issues.
First, be careful not to introduce security vulnerabilities into the web site
your content script is injected into.  For example, if your content script
receives content from another web site (for example, by making an XMLHttpRequest),
be careful to filter that content for <a
href="http://en.wikipedia.org/wiki/Cross-site_scripting">cross-site
scripting</a> attacks before injecting the content into the current page.
For example, prefer to inject content via innerText rather than innerHTML.
Be especially careful when retrieving HTTP content on an HTTPS page because
the HTTP content might have been corrupted by a network <a
href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">"man-in-the-middle"</a>
if the user is on a hostile network.</p>

<p>Second, although running your content script in an isolated world provides
some protection from the web page, a malicious web page might still be able
to attack your content script if you use content from the web page
indiscriminately.  For example, the following patterns are dangerous:
<pre class="prettyprint">contentscript.js
================
var data = document.getElementById("json-data")
// WARNING! Might be evaluating an evil script!
var parsed = eval("(" + data + ")")

contentscript.js
================
var elmt_id = ...
// WARNING! elmt_id might be "); ... evil script ... //"!
window.setTimeout("animate(" + elmt_id + ")", 200);
</pre>
<p>Instead, prefer safer APIs that do not run scripts:</p>
<pre class="prettyprint">contentscript.js
================
var data = document.getElementById("json-data")
// JSON.parse does not evaluate the attacker's scripts.
var parsed = JSON.parse(data)

contentscript.js
================
var elmt_id = ...
// The closure form of setTimeout does not evaluate scripts.
window.setTimeout(function() {
	animate(elmt_id);
}, 200);
</pre>

<h2 id="extension-files">Referring to extension files</h2>

<p>
Get the URL of an extension's file using
<code>chrome.extension.getURL()</code>.
You can use the result
just like you would any other URL,
as the following code shows.
</p>


<pre class="prettyprint">
<em>//Code for displaying &lt;extensionDir>/images/myimage.png:</em>
var imgURL = <b>chrome.extension.getURL("images/myimage.png")</b>;
document.getElementById("someImage").src = imgURL;
</pre>

			</div>