Thoughts on using asm.js for performance bottlenecks in browser extensions · 2013-06-26 13:55 by Wladimir Palant
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.
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
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.