Firefox is my preferred browser. I'm a heavy user of browser tabs (and a couple of popular Firefox plugins that help manage them), and often have five or six tabs open to the Renderosity marketplace showing for new products or ones I'm contemplating buying. I'm one of those folks who uses open tabs as a kind of "to do" list.

Naturally that makes my browser a bit of a memory hog. But about 12 to 15 months ago, I started having a really aggressive memory leak. "Leak" as in FF would net more and more memory use over time even if I didn't net more open tabs (which was new behavior), and "aggressive" as in Firefox would consume more and more memory even when I wasn't using it. If I left it open all night while I was asleep I would sometimes wake up to it using several hundred more MB of memory than when I left it. Closing tabs would reclaim some memory, but not all of it, and eventually the browser would crash (for 32-bit versions) or just get so honking big (for 64-bit versions) I would need to recycle it to have room to run big memory users like Poser.

I chalked this all up to some kind of bug in the browser or possibly some plug-in I use. Which it may be, but keep reading.

Recently, I got my hands on a plugin that let me see FF's consumed memory more or less in real time, and I could see its memory use was at times growing an average of around a MB or more per second. This really motivated me to dig around an try to see what on earth was up. Thenm while working on something completely different, I was running a web debugging proxy (Fiddler2) and noticed that open Renderosity tabs were visiting renderosity.com from otherwise idle tabs. One URL was for checking Renderosity site mail and one for checking site events. If you have multiple tabs open with Renderosity pages (and you're logged in) then each Rendo tab will do this. They each call home pretty frequently.

I observed very unscientificially that there was a rough correlation between a single Renderosity tab calling home and small jumps in memory used by FF. To try and test that correlation, I closed or unloaded all my open Renderosity tabs, and sure enough, my memory would not grow the same way. More open tabs to other sites would use more memory, but closing them basically got me back where I started, even if I left them open for long periods.

Finally I got really adventurous. I grabbed the Greasemonkey plugin and found an example of how to use it to forcibly remove Javascript functions from a web page. After a bit of reverse engineering of the site pages I wrote a Greasemonkey script to strip the following two functions from pages loaded from renderosity.com: check_sitemail() and list_events(). This kills those automated calls back to the Rendo servers.

Sure enough, I can now leave my browser laying around for days at a time with 5-10 open Renderosity tabs and I suffer no meaningful growth in memory use. One or both of those two JavaScript functions I hacked out appears to be at the heart of the problem.

(I now don't get notifcation of Rendo site mail without refreshing or opening a new Rendo tab, but given how infrequently I personally get any communications here, that's a way acceptable tradeoff.)

As I mentioned earlier, that the invocation of these site-specific JavaScript functions seems to cause a memory leak in Firefox may indeed be a flaw in that browser rather than something wrong with the JavaScript code used by Renderosity. I upgrade Firefox pretty regularly, and this leak has been plaguing me for a good long time, so if it is on their side, it's not something that they broke briefly. I'm not sure how many Renderosity users are Firefox users, but I thought the Renderosity site admins/developers and possibly a few users might want to be aware of this. I'm not sure whether it's anything the site admins can do anything about, but I figured it couldn't hurt to post about it.

Note that this memory leak problem predates the new site template. Sadly I have no idea if the old site used the same JavaScript architecture to poll site mail and events, but I bet that it did.

Finally, I'll be cross posting this info (probably with a lot more technical details) over on the Firefox support forums as well. Even if it's not a specific bug on their side, they might benefit from awareness of a speciifc example of site code that can consume memory like that.

For the curious, I am currently using a beta version of Firefox roughly equivalent to version 24, but this problem was present for me in versions dating back to around Firefox 16 or so, both 32-bit and 64-bit (which you can only get for Windows by using beta versions). I only really visit here from a Windows desktop.

Thank you for the information (I'm not techy so it's a little beyond me lol) but I will pass this on tomorrow when the office reopens to the techs:)

Have a great Memorial Day!