Hack 57. Handle Hangs and Other Bad Juju
Firefox is only nearly perfect.
Here's how to manage when it's
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
5.15.1. Separate Out Performance Problems from Hangs
A few things slow Firefox down, rather than causing it to die
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
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.
and CPU and bog down processing in a general way.
mess up the browser state.
5.15.2. Things You Can Do to Bust Firefox
There are plenty of things you can do to ruin
- Syntax errors
If you hack the chrome [Hack #77]
the browser window might not start up at all. It's
up to you to unwind your changes until you've
removed the error in your code. You did make a backup,
didn't you? As a last resort, use the
-safe-mode startup option.
- 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.
5.15.3. 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
On Windows, search and destroy Firefox processes using the Task
Manager (Ctrl-Alt-Del), or start Firefox again with the
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
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.