198464 - XUL Profile Troubleshooting Utility

Status: RESOLVED WONTFIX

(Core :: Preferences: Backend, enhancement)

Description

[Eric Liga]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

NOTE:  This is not a dupe of Bug 63918, Bug 22689, or Bug 123027 (although it
has the potential to duplicate or subsume some of their suggested functionality).


Because uninstalling and reinstalling doesn't touch the prefs.js and user.js
files, a lot of cruft tends to build up in them over time.  This is especially
true as structural changes occur in Moz and deprecated (but still supported)
prefs hang around and bite the user in hard-to-troubleshoot ways down the road
(see the resolution to Bug 176274 for an example).

Timeless ([e-mail]) suggested building an XUL utility that could,
with appropriate data, troubleshoot a profile to help detect and fix these sorts
of problems.  Eventually it would be nice to have these adjustments to the
profile happen automagically on upgrade, but for the short term this app would
help with the problem and allow us to compile the required data and test out the
logistics of doing this.

We'd need to compile (and maintain) a list of potentially problematic prefs and
settings as they (or the way they are used) have changed across the milestones.
 I'm not sure how best to obtain this information... suggestions?

The troubleshooting util should start by backing up the profile and allowing the
user to restore it if the suggested changes break things. (Vaguely similar to
Bug 22689.)  

It should then bring up a list of prefs.js and user.js lines that pose potential
problems, each flagged to indicate whether the information is a hint, a warning,
or an error.  

Clicking on a line would give an explanation of the associated issue (for
example:  "Cookie permissions are now being handled in the network.cookie and
dom.disable_cookie* prefs.  The presence of this pref prevents you from
effectively managing cookie behavior through the Edit Preferences GUI.  This
pref should be removed and replaced with one or more of the following
suggestions...").  The user could select an action for each "problem item" and
then commit the changes.  If the troubleshooting attempt causes more harm than
good, they can revert and try again.

Assumedly the app would need data files that included a list of preferences
divided into 6 categories:

1. Prefs that are no longer supported-- won't cause problems but should be
scrubbed from pref.js / user.js for clarity.  

2. Prefs that are deprecated but still supported and really ought to be
deleted-- give user option to delete.

3. Prefs that are deprecated but still supported that should be translated into
one or more newer prefs-- give user option to translate.  (For an example, see
resolution to Bug 176274.)

4. Prefs that are no longer used for a user-configurable purpose but may stick
around for secondary / internal uses-- provide a text explanation and generate a
warning.  (These may end up being the most important ones.)

5. Prefs that are validly useful but potentially dangerous-- generate a hint.

6. Unrecognized, mangled, or broken prefs-- flag with an error.  Offer to fix or
eliminate.  (This would provide similar functionality to Bug 63918.)

The util should also give options to scrub out default prefs-- these are easy to
see with an about:config so there's no point in cluttering up the profile with
them.  And they can end up burning the user if those defaults end up changing. 
But the user should have the option to leave them alone.

If we can find a way to generate and maintain the required data, whipping
together a GUI should be easy.  I'm willing to handle that step if others can
help me with the data files.

Incorporation of profile maintenance into Moz itself, if it ever does happen,
should be handled in a separate bug.

Feedback?

Reproducible: Always

Steps to Reproduce:

Comment 1

[R.K.Aa.]

I would like to hear exactly which outdated js settings you refer to. I think
your premises here are wrong:

"Because uninstalling and reinstalling doesn't touch the prefs.js and user.js
files, a lot of cruft tends to build up in them over time."

As I see it, that is not the problem. I can't think of a single .js setting that
have caused me problems. My profile is from mar 21  2002 - that's over a year
old - and i haven't had to change one single line in my .js files, even if i
test several builds per day.

The problem areas have been corrupted cache files, corruption of XUL.mfl,
localstore.rdf, and not least a plethora of installed addons - themes and other
- no longer compatible with the version a user normally installs on top of an
old build, against all advice.

Comment 2

[Eric Liga]

user_pref("capability.policy.default.HTMLDocument.cookie.set", "noAccess");
is one example.  In fact, it's the one I referenced in Point #3.  

I'm not sure at what point in Moz's history this value was able to be set
through the Prefs GUI (I know I didn't hand-set it), but you can no longer
toggle this value there.  Adjusting the cookie behavior on the cookie page
adjusts "network.cookie.cookiebehavior".  Playing with the javascript cookie
permissions generates a "dom.disable_cookie_set" (and get, etc) pref.  But if
the pref referenced above is present and set to noAccess, it (at least
partially) masks the effects of the newer prefs.  Many pages seemed to be able
to set cookies, but with this pref set, the E-Music download manager page
couldn't.  And Lord knows I pulled my hair out validating every GUI-accessible
cookie-related setting trying to figure out why.

But point taken-- I need to dig through bugzilla to see how often this happens.
  I know I've been burned by oddball prefs more than once, but some of my
profiles date back to the M-milestones and I've installed many an odd extension.  

Determining the frequency of this type of problem is going to take a fair bit of
bugzilla research, unfortunately.  If it turns out that only a handful of prefs
are able to cause problems of this nature, we may be able to convince folks to
do some pref cleanup in the installer.  If there are quite a few, we may need to
toy with a troubleshooting app.

Comment 3

[benc]

-> NEW
This probably is not as badly needed now that about:config allows you to hack
you prefs interactively.

Still, a utility would be nice, we have no tools for addressing legacy prefs
problems right now.

BTW, if you need info on prefs that I QA, see:
http://www.mozilla.org/quality/networking/docs/netprefs.html

You can see an (incomplete) list of useless prefs at the bottom of the document
as well.

Comment 4

[Eric Liga]

Got burned by a legacy pref again-- this time causing trouble with skin
registration in extensions.  No GUI-togglable prefs resolved the issue, but a
new profile did.  Probably need to hunt down the diffs between the old profile
and the new one to find the offending pref.

I don't think this would be a difficult tool to construct, it's maintaining a
list of deprecated but still active prefs that would be hard.  Unless I'm
missing out on a page that tracks them.  Anyone?

Comment 5

[Benjamin Smedberg]

We've chosen to use profile reset instead of a repair utility. WONTFIX.