There's a number of keyboard shortcuts in the Firefox browser, I already knew (and used) a bunch of them. While looking for something else, I found this nice, convenient page describing all the shortcuts (for all platforms and versions): http://support.mozilla.com/en-US/kb/Keyboard+shortcuts

Glancing through this, I actually discovered a few that I didn't know about, like, -j (or k) will move focus to the search text area, and highlights the old text. Or that I can have Firefox "autocomplete" a .com address by hitting - while typing a URL.

I've compiled the latest Firefox source (nightly) with various gcc compiler optimization options, compared to the "default" moz build options on my platform. This is not a comprehensive test, but merely gives some ideas of where the "best bang for the buck" is. I ran the Sunspider benchmarks three times for each build instance. My box is a single CPU core2 system with 4GB RAM. The compiler options used were as follow:

-Os -march=core2 -mtune=core2
-O2 -march=core2 -mtune=core2
-O3 -march=core2 -mtune=core2
-O2

The last is the default optimization options on my platform, which is what I call the "Moz" build. The "core2" options turns out to have little effect (1.01x - 1.03x at the most), but "-O3" vs "-O2" has significant impact ("-O3" always generates the fastest browser on my platform). And of course, the new JIT compiler is very fast. For now, all I have is this little screen shot of a table I made with the results, I'll convert this to a proper HTML table in my copious spare time.

The way to read this table is a little bit complicated, but pick a row (e.g. "O3 + JIT") and follow it to the column you wish to compare it to (e.g. Moz + JIT), and you see that the "O3 + JIT" build is 1.10x faster. The conclusions I can make is that it's always best to optimize as much as possible, optimizing for size doesn't makes sense on these modern CPUs (core2), for the Firefox code base. And JIT is always vastly superior.

As a side note, the build with the "-Os" options (optimize for size) was incredibly unstable with the JIT compiler enabled. It took me many, many runs to get it to complete three benchmarks without hanging.

As of a few Firefox updates ago, and/or my update to Fedora Core 6, I've had all sorts of stability problems with Firefox on my Linux system. I'm fairly certain it's related to Flash Player (v9). I've tried reinstalling everything (including Firefox and Flash), as well as completely nuking my FF profiles. Neither has helped.... I am using the proprietary nVidia drivers for my X11 server.

Looking around for something different, I ran into something that sounded similar to what my problem is. I honestly don't know what it does, but adding the following to my Firefox startup script seems to help:

export XLIB_SKIP_ARGB_VISUALS=1

Another option is to disable the "Composite" feature in your X11 (Xorg) configuration.

Recently I've been having this problem, where on my Linux box, I'd get errors like this:

Xlib: Maximum number of clients reached

Looking in /proc/<PID of Xorg process>/fd shows that I'm at 257 open file descriptors. Poking around using various tools, lsof, xrestop etc., I tracked this down to my Firefox browser process. Killing it, cleans up about 220 file descriptors. This can't be right ... So, more debugging.

I've had problems with Firefox crashing frequently, particularly on some Flash enabled sites (and ads), so I recently installed the Flashblock extension. I used to run my Firefox with at least 4-5 extension, but since it's so incredibly unstable, I now run FF with a minimal number of extensions (which helps a lot). So, it was pretty obvious that Flashblock was causing this, and disabling this extension definitely solves the problem.

I haven't had a chance to examine the code in Flashblock, to see if it is responsible for leaking these file descriptors, or if it's some interaction with the Flash player plugin.