425764 - http://www.mozilla.org/catalog/end-user/customizing/briefprefs.html is horribly out of date

Status: RESOLVED DUPLICATE of bug 697655

(Developer Documentation Graveyard :: General, defect)

Description

[Adam Hauerwas]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

I created an <appdir>/defaults/pref/winpref.js to set two preferences:

pref("general.config.obscure_value", 0);                        
pref("general.config.filename", "providence.cfg");              

and then specified in the "providence.cfg" file the following lockPref:

lockPref("browser.startup.homepage_override.mstone", "ignore"); 

in order to suppress update notification.  Upon updating to 2.0.0.13, however, I saw the update page even though I had done the lockPref!

I went to about:config, and noticed that my lockPrefs had disappeared.  I did further investigation and learned that my <appdir>/defaults/pref/winpref.js had been deleted by update.exe!  To further confirm this, I ran SysInternals ProcessMonitor with a filter for "defaults/pref" and saw where update.exe seems to be making a backup [winpref.js.moz-backup] but then not correctly restoring the backup.  (I can send this information via email if someone contacts me directly.)

This bug seems pretty high; if a user has made site-specific customizations, updating the software then removes them.

Is this expected behavior?

Reproducible: Always

Steps to Reproduce:
1. Create an <appdir>/defaults/pref/winpref.js (with whatever you want in it) in a non-current install of Firefox.
2. Download product updates.
3. Restart Firefox and have updates apply.
4. Check the <appdir>/defaults/pref for your winpref.js.
Actual Results:  
See Summary.  :-P

Expected Results:  
Update.exe should have preserved my existing <appdir>/defaults/pref/winpref.js prior to launching Firefox.

This bug was introduced in an earlier build of the update (some months ago), though I cannot confirm exactly when.  We had had the browser.startup.homepage_override.mstone lockPref working correctly, and then it stopped.  I was surprised that I couldn't find another filed bug regarding this, though.

If there is an existing bug or this is "by design," appy poly logies!

Comment 1

[Adam Hauerwas]

Attachment: CSV of ProcessMonitor detailing access to <appdir>/defaults/pref

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

This is the list of files that are removed by the updater (it's preprocessed):
  http://mxr.mozilla.org/seamonkey/source/browser/installer/removed-files.in

You can see that defaults/pref/winpref.js is near the top of the list, because it's an old application file (probably from Firefox 1.5). If you use a filename not in the list then you won't have this problem. IIRC, every file in defaults/pref is read at startup.

Comment 3

[Adam Hauerwas]

Mr. Thomas,

Thank you for your comments.  I see in the article you referred to that winpref.js is in the defaults/pref list of files that are removed by the updater.  However, if that's the case then your documentation is wrong :-P  The following article:

http://www.mozilla.org/catalog/end-user/customizing/briefprefs.html

explicitly states what the platform-specific pref files are, including winpref.js -- so I'm surprised that the installer would remove that, given that people may have made customizations.  If there is newer documentation showing how to customize Firefox behavior, a pointer to that would be appreciated.

Also -- if every file in defaults/pref is read at startup, how does conflict resolution take place is a pref is configured in more than one file?

Thanks for your time and the quick response!

Comment 4

[Phil Ringnalda (:philor)]

Indeed, though finding an out-of-date page on www.mozilla.org isn't exactly difficult. There are good people hard at work at moving the tons of randomly scattered stuff that's accrued over ten years there to developer.mozilla.org, but not nearly enough of them, and it quite often needs rare and in-depth knowledge to tell totally out of date and worthless from needs a tweak from just fine.

In your case, you probably wanted to find http://developer.mozilla.org/en/docs/MCD%2C_Mission_Control_Desktop_AKA_AutoConfig instead, though that's not a direct enough replacement to just get a redirect from briefprefs.html. 

Comment 5

[Adam Hauerwas]

Thank you for your comments as well!  I agree that there are good people hard at work revising the documentation, and I appreciate the pointer to MCD.  I also agree that it's not a direct-enough replacement (since it deals with centralized config and is more tech-speak); the initial article was much more of a "how-to."  Since I'm learning this as I go along, it's hard for me to separate the wheat from the chaff (or the current from the historic) as I surf the web for AutoConfig.

Re: my location, I am not doing centralized config but instead *decentralized* config during user login on my public lab machines; I am setting the homepage based on the NETBIOS name of the computer.

I had not wanted to modify all.js, since a) I sometimes deinstall/reinstall [which likely would delete all.js], and b) during user login I would need to find out if all.js had already been modified prior to inserting my config lines.  I had known (or assumed) that winpref.js would not exist on the target machines, so using it (and clobbering it during user login) gave me a way to set the config location *without* modifying all.js.

The MCD article refs other docus about AutoConfig that also seem to refer to now-defunct files (e.g. mozilla-program-directory\defaults\pref\browser-custom.js).  Ah, such is the web.  For the time being, I will do the following in my login script:

find /i "providence.cfg" all.js > NUL: 2> NUL: || stuff to add the lines...

Have to say that I liked the "optional, platform-specific" .js files, though.  Not sure why the feature went away, but I was using it.

PS:  Found this:  https://bugzilla.mozilla.org/show_bug.cgi?id=222973 in the pages that were reffed by the article.  Seems to be exactly the problem I'm having re: currenct nature of documentation?

Comment 6

[Adam Hauerwas]

The first few responses were very speedy, but haven't seen action on this in a couple of days.  Let me boil it down:

I *liked* having platform-specific configurations and not having to mess with all.js.  Has this feature been deprecated?

Comment 7

[Adam Hauerwas]

Okay, one more time:  platform-specific configs have been deprecated?  And why?

Comment 8

[David Boswell]

In bug 453044 we're talking about migrating this document over to MDC.  I'm copying benc on this bug so he's aware of these comments about the page.

Comment 9

[benc]

I had written the original document because I needed to write preference-specific documentation. I was going to re-write it via a code review, but I won't have time to do that soon.

Probably it would be best to have a code contributor that understands that area better to explain if they changed it.

Comment 10

[David Boswell]

This page has now been migrated to MDC and can be found at:

http://developer.mozilla.org/En/A_Brief_Guide_to_Mozilla_Preferences

Changing product of bug to Mozilla Developer Center to continue discussion about updating the documentation.