-
Notifications
You must be signed in to change notification settings - Fork 278
How to minimize conditions to reproduce a problem
Before reporting a new issue to the issue tracker, please narrow down conditions to reproduce the problem you saw. Too less information report like Tabs are not restored
will not help debugging, and such a report often steals our time to investigate. There is a description about methods to start Firefox safely without any data loss, but sometimes it can be hard to investigate minimum conditions to reproduce the problem from scratch.
This page describes how I (the original author of TST) ordinarily investigate when a problem happens.
In short there are two steps:
- Prepare a testing environment which don't affect to your ordinal environment.
- Bisect contents of the profile to narrow down conditions.
Let's describe details.
- Create a new clean profile. Assume that you've prepared a testing environment with another installation: for example, assume that the ordinal installation is
C:\Program Files\Mozilla Firefox
and the testing installation isC:\Program Files\Mozilla Firefox Debug
. Now we refer them as "default" and "debug". - Go to the "debug" profile folder. Starting the "debug" firefox, open
about:support
(Help => More Troubleshooting Information) and click the button "Open Folder" in a row with the label "Profile Folder", and quit the Firefox. - A folder is opened: we refer it as the "debug" profile for now.
- Delete all files in the "debug" profile.
- Go to the "default" profile folder. Starting the "default" firefox, open
about:support
(Help => More Troubleshooting Information) and click the button "Open Folder" in a row with the label "Profile Folder", and quit the Firefox. - A folder is opened: we refer it as the "default" profile for now.
Now you have two profiles:
- "default" profile
- "debug" profile (it is blank)
and you are ready to do a bisection with the "debug" profile.
Bisection is a well-known method to find out the real cause from a list of suspects. The basic strategy of a bisection is:
- Separate the suspects to two groups: A and B. A is a half of the suspects, B is the rest.
- Remove A or B. Assume that we remove A.
- Try to reproduce the problem.
- Does the problem successfully reproduces?
- If "yes" - when the problem still reproduces - , the real cause exists in the rest suspects (B). Let's separate B to new two groups A2 and B2, and back to the step 2.
- If "no" - when the problem doesn't reproduce anymore - , the real cause exists in the removed suspects (A). Let's revert the last removal and remove the group you previously left (B). After that, let's separate A to new two groups A2 and B2, and back to the step 2.
- Repeat steps from 2 to 4 until there are only one or some few essential suspects are left.
- Confirm that the problem reproduces successfully when the last suspect or all of last suspects exist, and it doesn't reproduces when the last suspect or any of last essential suspects is removed. Congratulations, you've find out the real cause of the problem!
So, let's apply this method to find out the real cause from your Firefox profile. There are too many possible suspects, so you need to prepare lists of suspects in multiple levels like:
-
Find out the real cause file(s) from all files and folders.
- Remove all files from the debug profile and confirm that the problem doesn't reproduce.
- Copy prefs.js and other half of files from the default profile, and start bisection.
- Do more bisections though copying and deleting files.
- On every bisection steps, you should remove all files from the debug profile and copy prefs.js and other suspects from the default profile, before testing.
- Please remind that prefs.js should be copied from the default profile always, because it contains very essential information around registered addons.
- Finally you'll find out some essential suspect files.
In most cases essential suspects are:
- extensions (folder): contains packages of addons.
- prefs.js: contains configs of Firefox itself.
- storage (folder): contains settings of addons.
Thus I (the original author of this add on) usually leave these files in the debugging profile without testing, and start a bisection from the next step.
-
If there are multiple addons in the suspects, bisect them to find out the real cause addon(s).
- Disable all addons and confirm that the problem doesn't reproduce.
- Activate a half of addons, and start bisection.
- Do more bisections through enabling and disabling addons.
- Finally you'll find out some essential suspect addons.
-
If "prefs.js" is in suspect files, bisect its contents to find out the real cause config(s). It is a plain text file, but unexpected change of encoding and line endings will break things, so you need to edit it with a text editor for programmers, like Visual Sudio Code.
- Remove all lines and confirm that the problem doesn't reproduce.
- Copy the following four and other half of lines from the prefs.js in the default profile, and start bisection.
user_pref("extensions.lastAppBuildId", "..."); user_pref("extensions.lastAppVersion", "..."); user_pref("extensions.lastPlatformVersion", "..."); user_pref("extensions.webextensions.uuids", "...");
- Do more bisections through copying and deleting lines.
- On every bisection steps, you should remove all lines from the prefs.js in the debug profile and copy suspect lines from the prefs.js in the default profile, before testing.
- Please remind that four lines above should be copied from the default profile always, because removal of them will cleans up all extensions information, and such an cleaning up sometimes "solve"s the problem unexpectedly.
- Finally you'll find out some essential suspect lines.
Certain minimum conditions to reproduce the problem with 100% probability, extremely helps us developers to investigate and fix the problem. If it doesn't include any serious privacy data (cookies, passwords, or bookmarks), packing the debug profile and send it to the developer is more better - then the developer can try to reproduce the problem with less investigation cost.