Ubuntu Wiki

Introduction

firefox, as the default web browser, is a highly-visible application in Ubuntu; this means it attracts many bug reports. It is also extremely large and complex, which makes tracking down and identifying bugs difficult.

Here we give some hints and tips on the approach we take to handling bug reports against Ubuntu's firefox.

Which tactics to apply to each bug depend on the details of the bug, but here are some suggestions:

Eliminating plugins, extensions and non-default themes

Many reported firefox problems, and the vast majority of crashes, are caused by buggy addons. In particular, a browser that crashes with the Flash plugin installed is not surprising and there is nothing we can do about it. So, unless it's clearly stated that Flash is not involved, any crash report should be closed with something like the form letter MozillaTeam/Deprecated/FirefoxCrashFormLetterRePlugins.

Looking for the bug upstream

Often a bug seems like it might well appear upstream. (It is also possible to test this directly by installing the upstream binaries on Ubuntu.) In this case it can be worth looking upstream to find more information about a bug.

The upstream bug system is the Mozilla Bugzilla, https://bugzilla.mozilla.org/.

The Mozilla Project is very large and it is difficult, without being very familiar with it, to know exactly where and how a bug might be reported. For this reason it's usually best to use the full text searches and to try several keywords. Be sure, when using the advanced search, to include resolved bugs (as they might be resolved in upstream CVS but not in Ubuntu).

If you find information upstream, you should record the connection between the bugs in Launchpad. It is often worthwhile to leave a comment in the upstream bug system describing how the bug manifests in Ubuntu and giving a reference to the Ubuntu bug.

Trying to reproduce and clearly document the problem

The first approach to an unconfirmed bug in firefox is to try to reproduce the problem in a test installation. If this is successful, the bug can be marked as confirmed.

It is usually helpful to provide an extensive and clear description of the bug in this case, including an explicit statement of exactly which sequence of user actions are needed to reproduce the bug, starting with "start firefox from a terminal window".

It is always a good idea when hunting firefox problems (or indeed, problems in any program) to start the program from a terminal window. This will allow you to see any error and warning messages.

Ask the user to try a fresh profile

Many crashes and misbehaviours in firefox go away with a 'fresh profile' - ie, when firefox is restored to default settings and without plugins and extensions.

So, if a bug cannot be reproduced, ask the user to move the directory ~/.mozilla aside and then try again. Note that this directory contains their bookmarks, saved passwords, etc. If the user wants to keep these then the profile must be restored after the test, by replacing the freshly-created ~/.mozilla with the old one.

Rationale: Profiles, extensions and plugins

Many of the bugs reported against the firefox package are in fact caused by one of the many third-party 'extensions' and 'plugins' which are available. These are generally not included by upstream by default because their quality and stability are not considered adequate, or because they are not Free Software.

For example, many users install the proprietary Flash plugin from Macromedia so that they can view Flash animations. Unfortunately, the Flash plugin is known to be buggy and to cause firefox to crash sometimes. Without the source code, and the right to debug and fix it, we cannot help with these problems.

Crashing bugs

If firefox can be made to crash, when running without third-party plugins and extensions, this is usually worth investigating more fully. If the bug can be reproduced in controlled conditions, then a programmer should investigate it directly.

The first stage would be to obtain a stacktrace from the corefile, using gdb; a programmer may be able to spot the problem given only the line-number-less stacktrace and a description of the circumstances.

If not, then the user should be supplied with a debug build (DEB_BUILD_OPTIONS=noopt,debug) and asked to provide the corefile. (Note that the corefile will contain much private information belonging to the user so it should not usually be attached to the bug report or otherwise published. It will also probably be quite large.)

Adding Debug Symbols to a crash report

If your crash report is missing debug symbols please run

apport-retrace -d /var/crash/*.crash

to add the symbols before uploading.

Obtaining a Backtrace

For Firefox, the procedure for obtaining a backtrace varies slightly from the usual gdb program method. This is because firefox is actually a shell script that starts the Firefox browser's binary.

The first step is to install the debugging symbols for firefox from the main repository.

sudo aptitude install firefox-dbg

• Then after closing all instances of Firefox, start Firefox from the terminal with the following command:

   firefox -g 2>&1 | tee gdb-firefox.log

• Alternatively, you can also connect gdb to an already running Firefox process. First, you will need to obtain the PID for the running Firefox process as well as the full path to Firefox's binary:

   ps -o pid,command -C firefox-bin

  Then, connect gdb to the running Firefox process. For example, if the above command outputted:

   PID COMMAND
   15018 /usr/lib/firefox/firefox-bin -a firefox

  you would ignore the arguments passed to the command and run:

   gdb /usr/lib/firefox/firefox-bin 15018 2>&1 | tee gdb-firefox.log

After this, you should be in gdb. You can then set the break points you need, cause firefox to crash, and obtain a backtrace. The output would all be stored in gdb-firefox.log.

Specific issues

XML errors and broken UI after upgrade

After each release, some users report bugs a bit like this:

• XML Parsing Error: error in processing external entity reference

  Location: jar:file:///usr/lib/firefox/chrome/toolkit.jar!/content/global/netError.xhtml Line Number 10, Column 3: %netErrorDTD;

--^

Other symptoms include missing UI elements after an upgrade or other kinds of XML errors in dialogue boxes or on firefox's stderr.

A good standard response to reports of this form is:

• This is one of the things that typically happens if you don't restart your firefox after an upgrade. We think it's a bug that you have to restart it but sadly it's beyond our resources to fix for Ubuntu (or even to produce a better error message) and no doubt would involve significant effort even to convince upstream that it was a necessary fix. So, with regret, I am closing this bug report without action.

If the user reports that they did restart firefox then there is some different problem which should be investigated as usual.

CategoryMozillaTeam, CategoryDebugging