Useful Resources when Developing Chrome Extensions

I’ve built a handful of Chrome extensions this year, and I wrote up some of what I learned in a post back in March. Since then, I’ve found two more tricks that have proved useful.

First, the Chrome Canary channel includes a handy extension error console to quickly expose extension errors.

Simply open the chrome://extensions page and an Errors link will be available for side-loaded extensions (“Load Unpacked Extension”):

Errors link on Chrome://extensions

Error console

This error console can be enabled in other channels (dev/beta/stable) by launching with the --error-console command line argument.

Next, you’ll often end up with both a public version of your extension and a side-loaded developer build installed at the same time. If their Action icons are the same, it’s easy to get confused about which version is which.

To help clarify which is the development version, you can easily add a Dev badge to the icon of the developer build:
Dev badge

 

 

The code to add to your background.js file is straightforward and works even if the background page is not persistent:

 // Our background page isn't persistent, so subscribe to events.
 chrome.runtime.onStartup.addListener(()=> { init(); });
 // onInstalled fires when user uses chrome://extensions page to reload
 chrome.runtime.onInstalled.addListener(() => { init(); });

 function init()
 {
   // Add Badge notification if this is a dev-install
   chrome.management.getSelf( (o)=>{
     if (o.installType === "development") {
       chrome.browserAction.setBadgeText( {text: "dev"} );
     }
   });
 }

Finally, as mentioned in my last post, the Chrome Extension Source Viewer remains invaluable for quickly peeking at the code of existing extensions in the store.

I’ve had more fun writing Chrome extensions than anything else I’ve built this year. If you haven’t tried building an extension yet, I encourage you to try it out. Best of all, your new Chrome extension development skills will readily transfer to building extensions to Opera, Firefox, and Microsoft Edge.

-Eric

Useful Resources when Developing Chrome Extensions

5 thoughts on “Useful Resources when Developing Chrome Extensions

  1. Eric, I’m alarmed by this passage in the Chrome Extensions docs:

    “Incognito mode promises that the window will leave no tracks. When dealing with data from incognito windows, do your best to honor this promise. For example, if your extension normally saves browsing history to the cloud, don’t save history from incognito windows.”

    (https://developer.chrome.com/extensions/overview)

    Do your best?? Is this really left to the discretion of extension developers? What good is incognito mode if it’s not enforced? Is there some kind of architectural challenge here that I’m missing?

    Like

      1. I’m not sure. Your comment tells me I’m missing something obvious. Is it not possible for incognito mode to wall off the data that is normally available to extensions in standard mode?

        For one thing, I imagine that it would be easy for Chrome to simply disable extensions in incognito mode by default. After all, it’s a fairly explicit API. In fact, didn’t Chrome do this already? I think I have to explicitly choose to enable individual extensions in incognito mode. So the docs are even more confusing in light of that fact – extensions are disabled by default.

        Like

      2. Yes, Chrome extensions are disabled by default in Incognito mode, but the user may approve them. Any extension that permits itself to run in Incognito mode should be aware of the mode and behave accordingly.

        The point of most browser extensions is to interact with the web pages the user visits. If the browser were to “wall off” that access, the extensions could not do anything useful.

        Like

  2. I think there are a few things extensions can do without interacting with the currently open (or any) page. All kinds of little tools, Wunderlist, calculators, games, and the even an ad blocker doesn’t need to phone home to do its job. I think controlling outgoing traffic is a straightforward task that we might reasonably expect a browser to do. It’s amazing what some of these extensions do behind the scenes, and what they send out – I think it’s almost assured that some innocuous extensions are going to be co-opted by APTs or even created by them.

    Long-term, it would be great to have a browser extension API that was not based on JavaScript and didn’t expose the extension to attacker-controlled pages. I’m think of what Ormandy discovered about LastPass. That needs to be taken completely out of the DOM, completely away from whatever arbitrary website the user is on. It would be neat if we had a C#, golang, Python, Ruby, or Lua API that could do things like autofill a password without exposing itself to the site via JS. I dream a smart, well-architected language-agnostic extension API that funneled the aforementioned languages into a specially designed IR or bytecode (WebAssembly? Maybe too LISPy.) JavaScript is really not something we should accept long-term, and we need a boxed back-end API.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s