I wrote a Chrome extension recently called Chrome Nanny – For more details see Instructions For Chrome Nanny – A Leech Block like extension for Chrome . This post is primarily about sharing some the tips I learnt during the process of developing the extension.
One of the most important way to debug the extension is using logs. Sprinkle console.log liberally in your code during development. If you want to view these logs, then go to extensions page (Wrench -> Extensions) , select your extension and click on the appropriate page. Most of the time the primary logic will be in your background html page. Hence you need to select this page in the extensions page to get the developer tools. The last tab there is the console tab which will show your logs. Of course, if the console.log is in some other html page (say options page) , then you want to click on appropriate html file in the extensions page. Each active page of the extension starts its own developer tools window and hence the logs dumped in one is not visible in the other.
Usually, this is the behavior you want. But some times, you may want to redirect all the logs to BackGround html’s console. I don’t recommend it although it is pretty convenient. To achieve this write a wrapper function in your BackGround js which takes a string as input and writes it to console. A sample function might look like this.
writeToConsole : function(stuff)
In the code for other html files , you can invoke it . In my case , my BackGround js had an object called BackGroundManager. Hence, I invoke the function as
Note that to get access to the BackGround, you need to use getBackgroundPage function. I get BackGroundManager object within it and invoke its writeToConsole function. Of course , it can be much simpler in your code. Once you do this , you can watch all the logs in a single place.
If you are lazy to type the whole expression then write another helper function which can return the background page. This might look like
You can invoke your object using bg().BackGroundManager using chaining.
A Catch in Tab Update
Chrome has a function to make a tab go to a different URL – chrome.tabs.update . This function has two arguments : A tab id and an updateProperties object. updateProperties has a property called URL which accepts a valid URL.
A sample invocation looks like this :
The behavior of this API is this : If the URL does not have a protocol, then it assumes that you are trying to load some file from your extension folder. This is useful , for example, when you want to show your help file in a tab. A common mistake (which I did) is giving the url as http://www.test.com . Here the url does not have a protocol and hence it tries to open a file called http://www.test.com in my extension folder. The lesson is that , you should always remember to have a protocol in the URL to show unless you want to show a file from your extension.
What this means is :
Does not work :
Profiling Extension’s CPU And Memory Usage
When I was developing the extension , I did not want it to hog lot of memory. Chrome is best know for its blazing speed and I would not want to spoil that experience. Chrome has lot of tools to analyze the extension memory.
Method 1 :
Use this method, if you want an overall extension memory consumption and you do not really care to drill down deep. The easiest way is to press Shift+Esc keys. You can also click on the icon near the Wrench icon , select Developer option and select Task Manager. This will show how much memory each tab and extensions are using. This will give you an approximate value of the memory consumed by your extension.
Method 2 :
If you want to dig deep and figure out which parts of the extension contribute to the memory, then you are in luck. Chrome has some great tools. Go to the extensions page and select the background html page. This will open the Developer tools for the extension. You can select the "Profiles" tab. By default this will not contain any information.
Click on the black dot on the status bar and continue using the extension as usual. After some time, click the same icon and stop the profiling. For best results , I would suggest you do some set of actions which exercise most of the functionality of your extension. Now you can see the CPU profile of the extension so far. It will show all the functions which take a long time to run. You can use this information to fine tune your function.
If you are more worried about memory, then the Heap profile can help. Click on the icon which looks like an Eye to start heap profiling. This will give you a break down of all the objects which take up memory. I find this information to be too much for me to process and I usually ignore it.
Disable Selecting Of Text
Now add this class to your textbox. This will prevent them from selecting text !
Lot of things happen asynchronously in Chrome. Almost all of Chrome APIs accept a callback function. Also a typical extension registers event listeners for the events it is interested in . The downside is that many of them can fired simultaneously and if you are not careful, you internal data structures can become inconsistent.
A more common problem is to know that callback functions need not be called immediately. A bad code is this :
tabId = tab.id
if(tabId == blah)
This assumes that Chrome will set tabId inside the callback function before coming to the if. The correct way is to bring the logic inside the callback function (or atleast not make the incorrect assumption). A common way to fix it is
tabId = tab.id
if(tabId == blah)
I will talk about more stuff in the next part !
If you liked this post , please subscribe to the RSS feed.