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 (email@example.com) 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:
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.
Summary: RFE: XUL Profile Troubleshooting Utility → XUL Profile Troubleshooting Utility
-> 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
We've chosen to use profile reset instead of a repair utility. WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.