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.
Running Linux in the browser · 2011-05-17 18:50 by Wladimir Palant
I haven’t seen it mentioned on Planet yet, could it be that nobody heard? I’ve seen lots of cool browser demos lately but this one really blows me away: jslinux by Fabrice Bellard. This is a real x86 emulator written in JavaScript and running Linux, not a fake Linux terminal. The emulated hardware is somewhat limited (e.g. no FPU) but this doesn’t make packing an emulator into less than 20 kB of JavaScript code less impressive. The emulator loads a bunch of binary Linux images and — voilà, Linux boots up.
Signing Firefox extensions with Python and M2Crypto · 2011-05-15 00:07 by Wladimir Palant
Sadly, signing Firefox extensions isn’t easy. I’ve seen people give up not having mastered even the very first step (install NSS). And after that you have to use its cryptic command line tools to set up a database, import your certificate into it as well as any intermediate or root certificates required, and then actually use signtool to sign your files. Java’s signtool is easier to handle but incompatible (though, I think the only real difference is that it doesn’t put zigbert.rsa first in the archive). So while rewriting my build scripts in Python I took it as a chance and implemented signing in Python using M2Crypto module. One of the advantages for me was that my build script can now package up the extension entirely in memory, without having to write out intermediate results for signing.
Do JavaScript proxies allow undetectable function wrappers? · 2011-04-15 18:13 by Wladimir Palant
I am looking into whether an extension can use JavaScript proxies to do something similar to the built-in pop-up blocker since the built-in pop-up blocker uses a fixed logic that cannot be extended. The goal is to wrap window.open method to verify that any calls are “legit”. Unfortunately, no matter what I try the webpage is able to detect that it is dealing with a proxy and not the real function.
Why you do not want to use the LOAD_ANONYMOUS flag · 2011-01-30 15:49 by Wladimir Palant
When you are creating a Firefox extension you don’t need to use browser’s default settings when downloading something, you can choose from a number of load flags defined on the nsIRequest interface instead. Some of them are really useful, e.g. the flags controlling caching. And then there is LOAD_ANONYMOUS flag that sounds like a good idea for downloads of public files — after all, why should you allow cookies and such? Making user tracking possible isn’t the point here.
How does one approach an "unusual" memory leak? · 2011-01-06 18:05 by Wladimir Palant
Firefox memory usage used to be very stable for me, it reached 200 MB and stayed there. However, some time ago this changed and now I see memory usage close to 1 GB after using Firefox for a few days. This only seems to affect my main Firefox profile which doesn’t see too many changes. So I can name the primary suspects: a minor Firefox release or Adblock Plus 1.3. And I clearly don’t like seeing my extension on the suspects list, so I did everything I could to ensure that it isn’t leaking memory. However, neither Leak Monitor, nor leak gauge, nor direct code inspection did bring up anything suspicious.