Feb. 9, 2011, 3:23 p.m.
posted by redcraft
Handle Hangs and Other Bad Juju
Firefox is only nearly perfect. Here's how to manage when it's not.
All software has defects. Firefox benefits from five years of poking and tweaking aimed at making it as robust as possible. It probably has fewer defects than Windows, although that's hard to say, since the Windows bug database isn't available to public scrutiny. This hack describes what to do if you happen to get stuck with a problem. If you do manage to make Firefox hang, then that's a significant achievement. You should be proud of yourself for pushing the limits and thus proving your skills.
Separate Out Performance Problems from Hangs
A few things slow Firefox down, rather than causing it to die completely:
If the download manager has a very, very long list of downloaded (or downloading) files, that can slow down the saving of web pages to local disk. Press the Clean Up button in the Download Manager to fix this.
If the DNS system used to turn domain names into IP addresses is performing poorly or, worse, is offline, then Firefox can't complete any web page retrieval actions.
Things You Can Do to Bust Firefox
There are plenty of things you can do to ruin Firefox's day:
- Syntax errors
- Command-line combinations
If you make heavy use of the Firefox command line, perhaps in a DOS box on Windows or from the shell, sooner or later you might find a URL string and command-line switch combination that upsets the browser. Take care to quote URLs with the right quotation marks, and use legal URLs only. The file: scheme requires three forward slashes (file:///) when referring to a file on local disk.
- A zero-by-zero window
Under Linux, you can't yet create an XUL window (in fact, any window) that's zero-by-zero (0 0) pixels in size. Each window must be at least one pixel in each direction.
- Mixing builds on Windows
The debug and nightly build of Firefox sometimes stress out Windows's little mind. Take care to clean up completely (shutdown and reboot in the worst case) if strange things occur when you're experimenting with an unofficial build. The oddities you see in test-only builds can sometimes confuse the running Windows instance, and afterward, even official Firefox releases can have a hard time getting Windows to cooperate. If in doubt, reboot cleanly.
Things You Can Do to Recover
Most importantly, understand the hidden window issue. In order to decorate the application menu bar on Mac OS X, Mozilla must maintain a separate window structure in addition to those that are normally visible as browser windows or as dialog boxes. If Firefox hangs or has other problems, this hidden window can remain when other windows are dismissed. This is true on all platforms. The upshot is that Firefox is still running, even though it looks like it's gone. In this case, it's important to kill all Firefox tasks before restarting it:
On Windows, search and destroy Firefox processes using the Task Manager (Ctrl-Alt-Del), or start Firefox again with the -kill option.
On Unix/Linux, just use kill(1) or Ctrl-C.
On the Mac OS X 10.3 and higher, use the Activity Monitor. It's found on the application toolbar under ApplicationsUtilities, or you can select Force Quit (Command-Option-Escape) from the Apple menu.
Another obscure issue is corruption of files in the profile area. This has been extensively discussed in the past, but the number of incidents seems to have subsided in recent times. In theory, such corruption could badly affect Firefox. If you suspect profile file corruption, then create a fresh new profile, prove that that much works, and then test any suspect files in there.
If you are running a Talkback-enabled build, a crashing or hanging Firefox may invite you to deliver a crash report. You should do so, as well as log a bug with Bugzilla, for these reasons:
If you don't bother to deliver it, the problem you've had might never be identified by anyone able to fix it. It will keep happening.
If you do submit a Talkback report but take no other action, it will just sit anonymously on a server, where it theoretically might get attention. In practical terms, it will just become another crash incident in a vast field of test data.
If you also log a bug with Bugzilla (http://bugzilla.mozilla.org) describing the conditions under which the crash occurred [Hack #96], then at least the problem is exposed to view. If you add reproducibility information and help the bug owner narrow down the problem, it will get fixed more quickly. The chances of it inconveniencing you again are then very low.
There are lots of places where you can collaborate with others [Hack #97] . In summary, when it comes to unexpected crashes and other vexatious behavior, the more you participate, the better off you are.