Adblock Plus and (a little) more
Thoughts on using asm.js for performance bottlenecks in browser extensions · 2013-06-26 13:55 by Wladimir Palant
asm.js is big news right now, and for a good reason. Firefox 22 can run some JavaScript code with performance similar to that of a compiled C/C++ application — this is huge. And it got me interested: maybe asm.js can be used to improve the performance of Adblock Plus? So I spent an evening looking into asm.js and Emscripten. This post merely summarizes my thoughts for far, it isn’t meant to be an extensive overview and some of my conclusions might be wrong.
Modularization in a restartless extension · 2012-07-12 17:21 by Wladimir Palant
A simple restartless extension can probably keep all its code in the bootstrap.js file. However, it gets crowded there very soon. Plus there is some code that is really only boilerplate and should probably kept separate from your actual code.
This sounds like a job for JavaScript code modules. It is mostly a matter of taste (I prefer CommonJS module syntax) but there is one really big disadvantage of JavaScript code modules: they have to be unloaded explicitly when your extension is shut down. Which means that you either have to keep a list of modules to unload in your bootstrap.js file or add cleanup code each time you load a module. I find neither approach very compelling.
Why you should make your next add-on restartless · 2012-07-12 14:18 by Wladimir Palant
Note: This article is not about extensions based on the Add-on SDK (Jetpack). You don’t have to use the SDK to create a restartless extension. Just wanted to point this out explicitly to avoid confusion.
An extension that will install without requiring a Firefox restart? This was a nightmare to develop not too long ago. Fortunately, things changed and the last showstopper bug was fixed in Firefox 8. Effort to create a restartless (or bootstrapped as it is called officially) extension is acceptable now. In fact, I have converted all my extensions and removed support for classic non-restartless extensions from my build tools — I am certain that I am not going back.
Preventing background tabs from wasting your computer's resources · 2012-05-12 13:27 by Wladimir Palant
Taras recently blogged on how websites manage to ruin Firefox performance by continuing to do something even though their tab is no longer active — they keep updating the view that you cannot see. He wondered whether it would be possible to suspend these tabs from an extension. I looked into this and there is a way to suspend all timeouts for a tab — something that an extension could use. Getting the details right wasn’t quite trivial but I think that my extension gets it right now: Suspend background tabs. Enjoy!
Using asynchronous file I/O in Gecko · 2012-04-05 20:38 by Wladimir Palant
I’ve finally decided to start using asynchronous file I/O in Adblock Plus (probably about time). I didn’t expect this to be too complicated, mostly messy because of all the callbacks. Well, I was mistaken. I will write down what I figured out, this might help somebody.
Faster extension development cycle: install changes automatically · 2012-01-13 16:33 by Wladimir Palant
The usual extension development cycle is less than optimal: change something, create a new extension build, install it in the browser (gonna love warnings), restart the browser, finally test it. I don’t like repeating this cycle all the time and so in the past years I’ve been using a test environment in which most extension files are loaded directly from my source code checkout (thanks to a manipulated chrome.manifest file). With this test environment many changes could be tested by simply reopening the extension window, for others you would restart the browser.
Raymond Chen quote of the day · 2012-01-05 19:59 by Wladimir Palant
I regularly use a program that doesn’t follow this rule. The program allocates a lot of memory during the course of its life, and when I exit the program, it just sits there for several minutes, sometimes spinning at 100% CPU, sometimes churning the hard drive (sometimes both). When I break in with the debugger to see what’s going on, I discover that the program isn’t doing anything productive. It’s just methodically freeing every last byte of memory it had allocated during its lifetime.
Measuring the memory use of an SDK (Jetpack) based add-on · 2012-01-04 11:37 by Wladimir Palant
Add-on SDK 1.2.1 added a nifty feature: starting with Firefox 9 the memory usage of add-ons built with the SDK is visible in about:memory. However, if you actually try to use this feature you get lost in the sheer amount of compartments. Each module gets its own compartment and the SDK has lots and lots of them. This even prompted a user to report “zombie compartments” caused by my only SDK-based add-on so far.
Binary XPCOM components are dead - js-ctypes is the way to go · 2011-07-12 13:19 by Wladimir Palant
Daniel Glazman is shocked to see how hard shipping binary XPCOM components with an extension became now. Fact is, we simply didn’t notice the hidden message of blog posts announcing dropping binary compatibility (meaning that your component needs to be recompiled for each new Firefox version, no matter how simple it is) and rapid releases — binary XPCOM components in extensions are deprecated. Theoretically, somebody could still continue using them but it requires so much effort that nobody can be expected to do that. Unfortunately, I haven’t seen it said like that anywhere, hence this blog post. There is still tons of documentation on binary XPCOM components on MDN and no deprecation warnings. Even XPCOM changes in Gecko 2.0 page lists all the important changes without making any conclusions.
Are undetectable changes to a native prototype possible? · 2011-07-11 14:27 by Wladimir Palant
This is a follow-up to Do JavaScript proxies allow undetectable function wrappers?. After that blog post I managed to solve the main problem: with Function.toString() and Function.toSource() being the only information leaks (bug 650299) one only needs to wrap these functions as well to get undetectable function proxies. However, the remaining problem is manipulating Window.prototype.open so that it actually returns my wrapper and the webpage can neither detect nor revert this manipulation.