Learnings from writing a Chrome extension

A couple of months back, I thought of writing a Chrome browser extension to:
- Make a small application on my own. I rarely get to do this in my day job, where I build small pieces in a huge and sometimes unnecessarily complicated code base.
- Understand better the http(s) protocol as it relates to the browser.
- Brush up on my rusty JavaScript in the context of the browser, with minimal use of libraries.

I thought I would build a simple http observer which sniffs http traffic and displays details of each request for one Chrome tab. This is one of the many features of the Chrome devtools network tab.

The extension can be installed on the Chrome browser here: http observer Chrome extension.While it does use several permissions on the browser, it contains no intentional malice and the source code is on github.

There is nothing the extension does that is not provided by Chrome devtools, and the extension is not as non-intrusive with respect to the page load as something like chrome devtools is. Really you should be using devtools network tab for working with the web page network requests. This sample extension just provides a way to visualize the requests and drill down into the details. I thought I would share what I learned while building the extension.

Building a Chrome extension

A good starting point is the sample Chrome extensions page. From the comment headers these samples seem to have been written a while back, but there is a relatively newer github repo with all the samples. In the repo, I found a sample which gave me a great start on what I wanted to make.

The Chrome extensions getting started page gives a tutorial on building extensions. The sample and links in that article should put you well on the way to writing useful extensions.
Some terms:
manifest.json: Has important information about your application. Some of these are:
Background page/script: Long running html page or script to manage state or tasks.
Content scripts: Scripts which execute in the context of a page.
Permissions: The list of resources your extension wants to use in the browser. Some of these permissions are displayed to the user during installation so they can take a call on whether they want to install the extension or not.
The Chrome debugger protocol: As the protocol viewer documentation says, this protocol allows for tools to instrument, inspect, debug and profile Chromium, Chrome and other Blink-based browsers. The protocol is used by Chrome devtools itself. For extensions, there is a higher level Javascript API which provides a convenient way to call the API from javascript.

Http observer design

I decided to make a table of the http requests and display details like headers, cookies and responses for each request. For that I made a simple 2 x 2 popup display. Found out sometime later that the maximum dimensions on startup was 800px wide and 600 px height. This is painful since the extension window has to be resized or maximized each time after startup to display content optimally. I don't have much of a clue when it comes to UI design.

Most of the application deals with some http request and response intercept events provided by the Chrome debugger API. It uses the data from these events to display information in tables.

The source code for the extension is on github, I admit it is bad code, which I might refactor if anyone but me uses it. I avoided using third party Javascript libraries. I did use a minimal and excellent css framework Milligram to help me with the display layout.

Some features

- Http requests are displayed as a table.
- For each request chosen, the details are displayed in other tables.
- All the http related tables are sortable.
- The full details for a request are display as json at the bottom of the popup.
- The browser cache can be disabled/enabled. This is a good way to see the effect of local browser caching on page load.
- Once the http requests have 'settled' for a page (a minute or so, depends on the busyness of the page), a summary is displayed which tries to display the overall way in which the page made http requests through its lifecycle. It is surprising to see the number of non-essential requests some pages make to analytics and other 'partners' these days. Below is a screenshot of a better behaved page.

Some caveats

- The extension will not work when Chrome dev tools is open.
- The extension only works against the tab that it was opened from.
- For more details and better performance, you should really be using Chrome devtools.

User options and configuration

While I have not added user options to the extension, settings provide a way for users to configure the extension based on their need. For example in the http observer it would be good to limit the number of http requests to be displayed per page. Here is a good example of how to implement options.

Publish an extension

Once you have written an extension, you can release it on the Chrome developer store. You need a google account and can follow publish instructions. There is a one time 5$ signup fee to publish apps.