Browser Extensions for Web Hackers

Browser Extensions
for Web Hackers
JSConf EU 2010, Berlin, Germany
Mark Wubben

A talk about browser extensions in Chrome & Safari, why they’re so great for web hackers
and how to build them.

Given at JSConf EU on September 26th, 2010 in Berlin, Germany.

Licensed under Creative Commons Attribution-Share Alike 2.5
http://creativecommons.org/licenses/by-sa/2.5/dk/

Photo by Steve Peck, http://www.ﬂickr.com/photos/stevepeck/4615314670/. CC-BY-2.0.

I’m a Web Hacker
I’m a Web Hacker. That might scare some people, but I don’t hack highway signs or break
into computers. I (try to) build cool shit.

I think you’re web hackers as well, otherwise, why would you be here? But if you’re a web
hacker, why limit yourself to building websites? Why not hack other systems? Build, say,
browser extensions?

Photo by James Kim, http://www.ﬂickr.com/photos/underbiteman/2638246638/. CC-
BY-2.0.

Add-ons, Plugins, Extensions
My question to you is, have you ever build a browser extension? Did you try? Did you look
into it and got scared? That’s been my story—Firefox extension have always looked too
bewildering. You’d have to know about RDF, XUL, XPCOM. You had to restart your browser
every time you wanted to try something. Bah!

But luckily, times have changed. Chrome and Safari are showing a new way of building
extensions. Easy, based on Open Web Technology.

Photo by Jon Fife, http://www.ﬂickr.com/photos/good-karma/652486713/. CC-BY-SA-2.0.

Open Web Technology
See, these new extension platforms are based on JavaScript, mostly. But also HTML and CSS.
And the cool new HTML5ish APIs like localStorage or geo-location.

Let’s dive in.

Photo by Kevin Dooley, http://www.ﬂickr.com/photos/pagedooley/4126491780/. CC-
BY-2.0.

Diving in to… what?
We’ll have a look soon at the underlying concepts of these new extension platforms. But you
might wonder, I’ve mentioned Chrome & Safari, what about Mozilla?

The good news is that Mozilla is renewing its platform — through Jetpack. However the
current stage of development is focused on building out the fundamentals of its platform.
They also take a different approach that I can’t ﬁt into the 30 minute time slot. We therefore
won’t cover Jetpack much in this talk.

Photo by Justin De La Ornellas, http://www.ﬂickr.com/photos/ornellas/4380104720/. CC-BY
2.0.

We’re going to start off with Chrome. Later during this talk we’ll look at how the concepts
used in Chrome translate to Safari.

Photo by Matt Biddulph, http://www.ﬂickr.com/photos/mbiddulph/2924278682/. CC-BY-SA
2.0.

This is the Extensions page in Chrome. It shows you which extensions you have installed. You
can disable or uninstall them, see their web page, allow them to run in Incognito mode.

At the bottom is a link to the Google Chrome Extensions Gallery. At the top is an option to
enable Developer mode.

Developer mode lets you load a new extension from your local ﬁle system. You can also
package extensions for release or force the installed extensions to be updated. Normally this
is done automatically when the browser is restarted.

So, what is an extension?!

Now the obvious question is, what *is* an extension?!

An extension is a folder
with a manifest.json file

In essence, an extension isn’t much more than a folder that contains a manifest.json ﬁle.

Let’s try loading a few folders as an extension.

{
"name": "Chrome Extensions Rock!",
"version": "1.0"
}

manifest.json
And there’s the manifest for our very simple extension. These are the only two required
properties, a name for your extension and a version number.

Admittedly, this extension doesn’t do much.

For more about the manifest ﬁle, see http://code.google.com/chrome/extensions/
manifest.html.

Extensions can have
content scripts.

One of the things a Chrome Extension can do is to run scripts on the pages you visit. These
are content scripts and should be familiar, because its a concept from the Firefox-based
Greasemonkey add-on.

Photo by Brian Sawyer, http://www.ﬂickr.com/photos/olivepress/61618336/. CC-BY-SA 2.0.

Aaron Boodman / Greasemonkey
In fact, the guy who invented Greasemonkey, Aaron Boodman, has been at Google for a few
years now and is one of the guys behind the new Extensions platform. To put it differently,
Chrome Extensions is Greasemonkey on steroids.

Photo by Mark Wubben, http://www.ﬂickr.com/photos/novemberborn/230693761/. CC-BY-
SA-2.0.

Fixing Twitter opening
links in new windows

You might have noticed how external links on Twitter always open in a new window. I find
this annoying, so I figured I’d write an extension to fix it.

{
"name": "Twitter Fixer",
"version": "1.0.0",
"description": "Fix the external links…",
"content_scripts": [{
"matches": ["http://*.twitter.com/*",
"https://*.twitter.com/*"],
"js": ["fixer.js"]
}]
}

manifest.json
The manifest for our new extension, dubbed Twitter Fixer.

{
"version": "1.0.0",
"js": ["fixer.js"]
}]
}

manifest.json
Note how I’ve added a description.

{
"version": "1.0.0",
"js": ["fixer.js"]
}]
}

manifest.json
You can specify multiple content scripts per extension.

{
"version": "1.0.0",
"js": ["fixer.js"]
}]
}

manifest.json
A content scripts needs to match a page. This is done through match patterns. Here we
specify our extension will run on any page or subdomain on twitter.com, over HTTP as well as
HTTPS.

Keep in mind that the user is warned about the sites you might match. The more restrictive
your match pattern, the better.

To learn more, see http://code.google.com/chrome/extensions/match_patterns.html.

{
"version": "1.0.0",
"js": ["fixer.js"]
}]
}

manifest.json
A content script itself can exist of any number of JavaScript ﬁles. They’re loaded in the same
order as you specify in the manifest.

You can also specify CSS ﬁles that need to be added to the page your content script runs on.

To learn more, see http://code.google.com/chrome/extensions/content_scripts.html.

var links = document.querySelectorAll(
"a[target=_blank]");

Array.prototype.slice.call(links).forEach(
function(a){
a.removeAttribute("target");
});

fixer.js
And the actual content script.

{
"version": "1.0.0",
"js": ["vapor.js", "fixer.js"]
}]
}

manifest.json

Isolated Worlds
Chrome has learned from the security problems that existed with Greasemonkey, and even
with Firefox add-ons as a whole. Each extension lives in a so-called “isolated world”,
meaning it’s isolated from other extensions save for a few tightly controlled communication
bridges.

Photo by F.H. Mira, http://www.ﬂickr.com/photos/fhmira/3204656258/sizes/o/. CC-BY-
SA-2.0.

Content scripts run in
separate contexts

For example, the JavaScript inside your content scripts is evaluated in a separate context
from the page JavaScript. This means your code won’t affect the page code, and vice versa.
You can’t directly call page code, and it can’t directly call your code.

Shared DOM

Luckily the page document is shared between the various content scripts that might be
running on it. That way, you can change it!

Communicating with page
JavaScript

But with these isolated worlds, how can your content scripts talk to the page JavaScript? Well,
you’ve got access to the DOM, so you can insert your own JavaScript into the page! And, you
can use DOM events so the inserted JavaScript can talk back to you.

document.documentElement.addEventListener(
"ExtensionNotify",
function(){ alert("Notified!"); },
false
);

var s = document.createElement("script");
s.textContent = 'function notifyContentScript(){
var evt = document.createEvent("Event");
evt.initEvent("ExtensionNotify", false, false);
document.documentElement.dispatchEvent(evt);
}';
document.body.appendChild(s);

communication.js
This sets up a content script that insert the `notifyContentScript` method into the page.
When this method is called, a custom DOM event is dispatched on the document element,
which is used to notify the content script.

While you can’t send data along with the event, you can store it in the DOM. The content
script can then look it up.

Content scripts are limited.
Background pages!

Content scripts are fairly limited though. They exist only as long as the page they run on
exists. They don’t have access to any permanent storage, so you can’t conﬁgure them. Nor
can they talk to other websites, so you can’t look up anything through an API.

Luckily, Chrome Extensions let you build background pages. These are normal HTML pages,
except that they’re not rendered. They’re loaded when the browser starts, and won’t be
unloaded until it’s closed.

Let’s build a more complicated extension.

Expanding bit.ly URLs on
Twitter

Due to character constraints URLs in Tweets are often shortened. But, I’d like to see where
I’m going! Let’s write Chrome Extension that can expand bit.ly URLs.

{
"version": "1.1.0",
"description": "Expands shortened URLs…",
"permissions": ["http://api.bit.ly/*"],
"background_page": "background.html",
"run_at": "document_end",
"js": ["fixer.js"]
}]
}

manifest.json

{
"version": "1.1.0",
"js": ["fixer.js"]
}]
}

manifest.json
I’ve made two major modiﬁcations to the manifest.json we used previously. First is loading
the background page, this is done using the background_page property whose value is the
relative path (from the manifest.json ﬁle) to the background page. By convention this is
named background.html, but you can name it whatever you like.

The other change is that I’m now requesting permission to talk to the Bit.ly API. Chrome
forces the extension developer to request permission for almost anything. When the user
installs your extension he’s made aware of what you’re extension will have permission to,
therefore making it harder for nefarious Extension developers to sneak bad stuff into their
extensions without the users knowing about it.

{
"version": "1.1.0",
"js": ["fixer.js"]
}]
}

manifest.json
Another change I made is to specify the `run_at` property for the content script. This way I
can make sure it runs right after the page document has ﬁnished parsing, so we don’t have
to wait too long before we can expand the bit.ly URLs.

parsed.hashes,
function(mapping){
});
}
}
);

fixer.js
The content script needs to talk to the background page to expand the hashes. This is done
through the `chrome.extension.sendRequest` API.

parsed.hashes,
function(mapping){
});
}
}
);

fixer.js
Also note how I can use forEach on an array. Chrome has a fully up-to-date JavaScript engine
so native forEach is available.

Same for using textContent to set the link text value.

<!doctype html>

<script src="dojo.js"></script>
<script>
chrome.extension.onRequest.addListener(
function(hashes, sender, sendResponse){
// …
sendResponse(mapping);
}
);
</script>

background.html
I won’t go into the speciﬁcs of how to talk to bit.ly and get the expanded URLs.

<!doctype html>

<script>
// …
}
);
</script>

background.html
Note how I can pull other code into the background page. It’s a web page, after all.

<!doctype html>

<script>
// …
}
);
</script>

background.html
The important bit is how you register a handler for requests from the content script. You get
the request object, a reference to the tab from which the request was sent, and a callback
function to call once you have a response.

This communication mechanism is completely asynchronous.

Debugging
Web Inspector

You can easily debug your extension using the Web Inspector you would normally use to
debug your web pages. You can set break points or use the debugger keyword. An inspector
for the background page can be opened by clicking on the “background.html” link in the
Extensions page (if you have Developer mode enabled).

You may also notice how the background page is actually at “chrome-extension://some-
unique-identiﬁer/background.html”. This is the domain it runs in, so the extension can
piggyback on the normal same-origin restrictions!

Quick Recap

To recap:

* Chrome extensions are folders containing a manifest.json ﬁle
* You can have Greasemonkey-like content scripts that act on the page
* You can have HTML-driven background pages for generic/shared logic, talking to other
sites
* You can easily communicate between content scripts and background pages

So, how do these principles translate to Safari?

Photo by William Warby, http://www.ﬂickr.com/photos/wwarby/2405490902/. CC-BY 2.0.

Here’s Safari’s Extensions preference pane. It lists the extensions you have installed.

In order to start developing extensions, make sure to enable the Develop menu. Then, under
the Develop menu, you’ll ﬁnd an “Extension Builder” item.

This then is the Extension Builder, which initially is really quite barren. Let’s make a very
simple extension by clicking the “+” icon in the bottom left.

Safari lets you manage your extension configuration through a nice enough UI, whereas
Chrome makes you edit a JSON file. Another difference is that Apple requires you to register
with their Safari developer program (for free). This then gives you access to your own Safari
Developer Certificate. Without the certificate, you can’t even *test* your extension locally.

developer.apple.com

Just go to developer.apple.com/safari and follow the steps to obtain your certiﬁcate.

And once you’ve done so, the Install button becomes active. Click Install and your extension
is installed!

Content scripts?

Yes, Safari also has content scripts, although it’s called “Injected Extension Content”. You
conﬁgure them through the Extension Builder. Let’s see about implementing the Twitter Fixer
extension in Safari.

First we set the permissions for our extension. It can access some domains, namely
twitter.com and subdomains, including secure pages.

Then we add the content script, setting it to run when the document has loaded.

Info.plist is Safari’s manifest.json. It’s a typical Apple ﬁle, that isn’t nice to edit manually. Yay
for Extension Builder!

ﬁxer.js is of course our content script. In fact, it’s the exact same script we used for Chrome!

Background pages?

Safari has background pages too, except that they’re called “global pages”.

You specify the global page ﬁle in the Extension Builder as well.

You specify the global page ﬁle in the Extension Builder as well.

Note that we also need to request permission to connect to the bit.ly API.

Demo time

Let’s have a look at the Twitter Fixer in Safari.

Differences…

Of course the Chrome extension didn’t *just* work in Safari. The extension APIs are different!

For this extension, the only platform speciﬁc APIs we used were for communicating between
the content script and the background page. Let’s compare Chrome to Safari.

parsed.hashes,
function(mapping){
});
}
}
);

fixer.js
This is the original content script as used in Chrome.

parsed.hashes,
function(mapping){
});
}
}
);

fixer.js
Let’s focus on the communication to the background page. We send a payload to the
background page and provide a callback that can be called by the background page when it
has a response.

safari.self.tab.dispatchMessage("expandHashes",
parsed.hashes);

safari.self.addEventListener("message",
function(evt){
if(evt.name == "mappingComplete"){
var mapping = evt.message;
// …
}
}, false);

fixer.js
Safari takes a different approach. It has a special message event that content scripts and
global pages (etc) can listen to. The event has a name and a message property which contains
the original message object. `dispatchMessage()` is used to send these events.

This example is for content scripts. The messages arrive at different objects for global pages.

safari.self.tab.dispatchMessage("expandHashes",
parsed.hashes);

safari.self.addEventListener("message",
function(evt){
if(evt.name == "mappingComplete"){
var mapping = evt.message;
// …
}
}, false);

fixer.js
Safari takes a different approach. It has a special message event that content scripts and
global pages (etc) can listen to. The event has a name and a message property which contains
the original message object. `dispatchMessage()` is used to send these events.

<!doctype html>

<script>
// …
}
);
</script>

background.html
Here then the original background page script as used in Chrome.

<!doctype html>

<script>
safari.application.addEventListener("message",
function(evt){
if(evt.name != "expandHashes"){ return; }
// …
evt.target.page.dispatchMessage(
"mappingComplete", mapping);
},
false);
</script>

background.html
For the background page, we listen to the message event on `safari.application`. We can
send a response by dispatching a message to the content script the message event originates
from.

Extension Settings

Now for something more advanced: can we provide settings for our extension?

Yes we can! There’s a nice UI for it in the Extension Builder, even.

safari.extension.settings

You can read the settings from `safari.extension.settings`, though not in content scripts.
You’ll have to use the communication APIs to retrieve the settings from the background page.

Can we do this in Chrome, too? Well, yes, except that Chrome doesn’t have a nice UI and API
for managing settings. You’ll have to do it yourself, with the help of a special background
page and localStorage.

Photo by Matt Biddulph, http://www.ﬂickr.com/photos/mbiddulph/2924278682/. CC-BY-SA
2.0.

{
"version": "1.2.0",
"options_page": "options.html",
"js": ["fixer.js"]
}]
}

manifest.json
Chrome supports Options pages, which are just like background pages except that they can
be opened directly.

So, about Jetpack…

The approach taken by both Chrome and Safari is one of content scripts and background
pages, in essence normal HTML. Jetpack is taking a CommonJS approach where your
extension consists of a main script that adds the UI elsewhere. I do encourage you to check it
out.

Bonus!
Safari/Chrome hybrid extension

Given that both Chrome and Safari use folders for their extensions, it’s quite possible to build
a hybrid extension that can be loaded into both Chrome *and* Safari.

(Of course, once compiled for release, this would no longer be the case).

I’ve combined the latest version of Twitter Fixer so it works in both browsers. This is done by
abstracting the communication and settings logic. For Chrome, the Options page is built
dynamically based on the Settings conﬁgured for Safari.

Thank you

Mark Wubben

supercollider.dk & novemberborn.net
twitter.com/novemberborn

Slides: 11born.net/jsconfeu/slides
Code: 11born.net/jsconfeu/code

Licensed under Creative Commons Attribution-Share Alike 2.5
http://creativecommons.org/licenses/by-sa/2.5/dk/

And that concludes this talk. Thank you for your attention.

Steve Peck
James Kim
Jon Fife
Kevin Dooley F H Mira
Justin De La Ornellas William Warby
Matt Biddulph Jeff Kubina
Brian Sawyer Matt Jones

Many, many thanks to the wonderful people on Flickr who licensed their photos under
Creative Commons.

Photo by Jeff Kubina, http://ﬂickr.com/photos/kubina/903033693/. CC-BY-SA 2.0.

Now, as Matt Jones would put it, GET EXCITED and MAKE THINGS!

Illustration by Matt Jones, CC-BY-SA-NC, http://www.ﬂickr.com/photos/blackbeltjones/
3365682994/.

Browser Extensions for Web Hackers

More Related Content

Browser Extensions for Web Hackers