Last Comment Bug 33115 - Remove obsolete prefs from .js files in <app>/defaults/prefs dir
: Remove obsolete prefs from .js files in <app>/defaults/prefs dir
: footprint, helpwanted, perf
Product: Core
Classification: Components
Component: Preferences: Backend (show other bugs)
: Trunk
: All All
P2 normal with 1 vote (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
: Benjamin Smedberg [:bsmedberg]
: 35403 55519 64693 113020 (view as bug list)
Depends on: 205077
  Show dependency treegraph
Reported: 2000-03-23 16:42 PST by Simon Fraser
Modified: 2014-04-26 03:10 PDT (History)
16 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

[patch][1] remove some unused toolbar prefs (3.03 KB, patch)
2001-01-10 19:06 PST, Blake Ross
no flags Details | Diff | Splinter Review
[patch][2] more random pref removal... (4.46 KB, patch)
2001-01-17 13:45 PST, Blake Ross
no flags Details | Diff | Splinter Review
[patch] more random removal...not complete by any means (28.50 KB, patch)
2001-01-18 21:16 PST, Blake Ross
no flags Details | Diff | Splinter Review
[patch][3a] forgot to remove something else (28.75 KB, patch)
2001-01-18 21:19 PST, Blake Ross
no flags Details | Diff | Splinter Review
[patch][4] remove mailnews prefs (13.89 KB, patch)
2001-01-21 18:53 PST, Blake Ross
no flags Details | Diff | Splinter Review
[patch][4a] forgot this, sorry (658 bytes, patch)
2001-01-21 18:55 PST, Blake Ross
no flags Details | Diff | Splinter Review

Description User image Simon Fraser 2000-03-23 16:42:38 PST
The default prefs files, which live in Defaults/pref after installation, need to 
have all their hundreds of obsolete prefs removed, for two reasons:

1. we don't want pref space cluttered with lots of obsolete prefs.
2. reading in these default prefs files takes nearly a second of startup time.

For example, all.js contains 40 lines of prefs for toolbar state. All this info 
is now stored using rdf persistence, not prefs.
Comment 1 User image Simon Fraser 2000-03-23 16:43:03 PST
Adding perf keyword for startup time.
Comment 2 User image Fergus Sullivan 2000-04-10 17:31:16 PDT
*** Bug 35403 has been marked as a duplicate of this bug. ***
Comment 3 User image Fergus Sullivan 2000-04-10 17:32:00 PDT
Adding L10n folks to cclist.
Comment 4 User image tao 2000-04-17 11:28:07 PDT
== defaults/pref/config.js 

If I am right, the only one would survive is 


All the following are dead now.


// Default configuration information for the client 




config("toolbar.places.item_0.label","The Internet"); 
config("toolbar.places.item_2.label","Yellow Pages"); 
config("toolbar.places.item_3.label","What's New"); 
config("toolbar.places.item_4.label","What's Cool"); 





config("menu.places.item_0.label","The &Internet"); 
config("menu.places.item_2.label","&Yellow Pages"); 
config("menu.places.item_3.label","What's &New"); 
config("menu.places.item_4.label","What's &Cool"); 

config("","&Help Contents"); 
config("","&Release Notes"); 

config("","&Product Information and Support"); 
config("","&Software Updates"); 
config("","Register No&w"); 
config("","&Member Services"); 
config("","&International Users"); 
config("","Net Etiq&uette"); 
config("","Abou&t Plug-ins"); 
config("","About Font &Displayers"); 

config("personal_toolbar.item_1.item_1.label","Yellow Pages"); 

config("personal_toolbar.item_2.item_0.label","What's New"); 

config("personal_toolbar.item_2.item_1.label","What's Cool"); 

config("personal_toolbar.CreateNewToolbar", false); 
config("personal_toolbar.NewToolbarFolderName", ""); 
config("personal_toolbar.ToolbarFolderVersion", ""); 

== END 
Comment 5 User image (not reading, please use instead) 2000-04-18 09:54:13 PDT
if tao is right (which I believe he is), we should move
 from config.js (and config-ns.js) to all.js (and all-ns.js)

there is no need to have a special config.js file, and having two fewer files
helps the start up time (especially on mac)

adding selmer and varada to the cc list, as this change would probably affect CCK.
Comment 6 User image don 2000-04-24 17:30:40 PDT
M17 (or later).
Comment 7 User image don 2000-05-25 17:24:14 PDT
Move to M20 target milestone.
Comment 8 User image leger 2000-06-01 17:13:53 PDT
Putting on [nsbeta2-] radar. Tell us how much time this is delaying startupto 
process.  Need a big win to fix in PR3, but not needed for beta2.
Comment 9 User image verah (gone) 2000-07-25 13:53:33 PDT
Nav triage team: [nsbeta3-]
Comment 10 User image Daniel Veditz [:dveditz] 2000-08-09 13:07:16 PDT
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.
Comment 11 User image sairuh (rarely reading bugmail) 2000-08-30 22:13:40 PDT
alecf, adding you to cc list if you might be able to provide any input here. 
(but feel free to remove yourself if you don't wanna hear about this. :)

matt, should this go over to dan? reassigning to dveditz/backend prefs. (but 
reassign as needed.)
Comment 12 User image sairuh (rarely reading bugmail) 2000-10-06 12:11:40 PDT
*** Bug 55519 has been marked as a duplicate of this bug. ***
Comment 13 User image Simon Fraser 2000-10-06 12:17:16 PDT
Nominate for RTM. This will help startup performance.
Comment 14 User image Ben Bucksch (:BenB) 2000-10-06 12:24:32 PDT
See dup bug for additional reasons why to fix this bug.

This would be a nice bug for somebody starting with Mozilla. You just need to
use lxr to check, if the pref is ever used.
Comment 15 User image Daniel Veditz [:dveditz] 2000-10-06 13:06:54 PDT
Be EXTREMELY careful using lxr to check if these prefs are used! Many spots in
the code compose prefs out of #define fragments. The entire pref string may
never appear in the code at all.

Looks like someone already seriously trimmed out config.js, but didn't move the
few remaining prefs into all.js -- why?

This bug is pretty amorphous to consider for rtm. It will take lots of tedious
detective work, and I personally don't have the time. Then there's the risk of
removing something necessary by mistake, with little time to discover the
runtime problems it might cause. Giving [rtm-] but anyone else is welcome to
take this one over.
Comment 16 User image Ben Bucksch (:BenB) 2000-10-06 14:36:08 PDT
> Many spots in
> the code compose prefs out of #define fragments. The entire pref string may
> never appear in the code at all.

You're right. I usually use the last part (before the last dot).

I agree that this bug has some risk.
Comment 17 User image Ben Bucksch (:BenB) 2000-10-07 12:05:18 PDT
One more reason to fix this bug: It is a headache for distributors (who might
want to alter prefs). So, IMO, this is a MUSTFIX for Mozilla 1.0.
Comment 18 User image Simon Lucy 2000-10-27 08:56:34 PDT
Agreed it needs to be fixed for distributors, it might be worth documenting to 
distributors as well that any .js file in defaults will be read for prefs, so 
overlayed vendor specific preferences should go in their own files and not in 
all.js  And yes its a pain that config.js exists at all.

The grief of testing this inline could be mitigated by branching just on the 
candidate all.js and having that as a test binary and ask for testers generally.

Comment 19 User image Ben Bucksch (:BenB) 2000-10-30 00:49:29 PST
We have a lot of LDAP-prefs (starting with "ldap.") in mailnews.js. It would be
resonably save to remove them, considering that we have no (enabled-by-default)
LDAP support at all.
Comment 20 User image Ben Bucksch (:BenB) 2000-10-30 00:51:25 PST
If anybody at Netscape (you should know best what has a chance to go in) feels
like this should be done for rtm, please trigger the reevaluation.
Comment 21 User image (not reading, please use instead) 2000-10-30 08:50:41 PST
no need to do this for rtm.
Comment 22 User image sairuh (rarely reading bugmail) 2001-01-08 15:39:41 PST
*** Bug 64693 has been marked as a duplicate of this bug. ***
Comment 23 User image sairuh (rarely reading bugmail) 2001-01-08 15:41:49 PST
adding info/keywords from bug 64693:

[quoting valeski:]
There are prefs in the prefs files that were copied over from 4.x which are
never used. These are a waste of space and confusing.


Comment 24 User image Blake Ross 2001-01-08 19:21:16 PST
Dan, if you don't have the time to do this, I can take it...
Comment 25 User image Judson Valeski 2001-01-09 09:04:36 PST
-> blake. thanks blake!
Comment 26 User image Blake Ross 2001-01-10 19:06:02 PST
Created attachment 22321 [details] [diff] [review]
[patch][1] remove some unused toolbar prefs
Comment 27 User image Daniel Veditz [:dveditz] 2001-01-10 20:25:45 PST
r=dveditz for the first patch. The custtoolbar prefs appear unused, and were
added long ago.
Comment 28 User image Blake Ross 2001-01-12 13:49:04 PST
alec, sr?
Comment 29 User image Alec Flett 2001-01-16 16:03:40 PST
Comment 30 User image Blake Ross 2001-01-17 13:45:23 PST
Created attachment 22805 [details] [diff] [review]
[patch][2] more random pref removal...
Comment 31 User image Judson Valeski 2001-01-17 13:50:44 PST
r=valeski on 01/17/01 13:45 patch. get 'em outta here! :-)
Comment 32 User image Alec Flett 2001-01-17 13:54:35 PST
more great work! thanks blake!
Comment 33 User image Blake Ross 2001-01-18 21:16:41 PST
Created attachment 22946 [details] [diff] [review]
[patch] more random removal...not complete by any means
Comment 34 User image Blake Ross 2001-01-18 21:19:58 PST
Created attachment 22948 [details] [diff] [review]
[patch][3a] forgot to remove something else
Comment 35 User image timeless 2001-01-18 21:27:23 PST
Comment 36 User image Alec Flett 2001-01-19 10:35:49 PST
nice. sr=alecf
Comment 37 User image Blake Ross 2001-01-21 18:53:35 PST
Created attachment 23122 [details] [diff] [review]
[patch][4] remove mailnews prefs
Comment 38 User image Blake Ross 2001-01-21 18:55:51 PST
Created attachment 23123 [details] [diff] [review]
[patch][4a] forgot this, sorry
Comment 39 User image timeless 2001-01-22 02:06:16 PST
r=timeless for 4,4a w/ request [and instant r=] for minor whitespace issue:
+pref("mail.thread_without_re",             true);
you killed one too many spaces

<q class="asside">it doesn't look like we really need _any_ of the 
ldap_2* prefs.</q>
Comment 40 User image (not reading, please use instead) 2001-01-22 10:10:30 PST
double check with bienvenu before removing the offline prefs.

(I sent a private email to blake about this.)
Comment 41 User image David :Bienvenu 2001-01-22 10:14:56 PST
I'm not sure about the offline ones - I think many of those prefs will be
per-server, but the Issues Team isn't sure. There are a lot of other ones that
aren't obsolete, just not implemented yet (e.g., remember last selected
message). But, you might was well remove them all - we can always put them back
if and when things get re-implemented. sr=bienvenu
Comment 42 User image (not reading, please use instead) 2001-01-22 10:32:23 PST
thanks for the feedback, david.

r=sspitzer, too.  thanks for doing the cleanup, blake.
Comment 43 User image Ben Bucksch (:BenB) 2001-01-22 11:36:56 PST
> it doesn't look like we really need _any_ of the ldap_2* prefs.

Note that local address books are also "ldap" in prefs, IIRC. I removed all LDAP
prefs and ran into problems.
Comment 44 User image Blake Ross 2001-01-22 21:44:05 PST
While getting rid of config.js, I noticed Seth's 4/18 comment regarding config-
ns.js and all-ns.js.  Does this mean the comm tree has its own versions of 
these (or of all the pref) files?  If so, anyone willing to sync my moz changes 
with those files...?
Comment 45 User image Ben Bucksch (:BenB) 2001-01-23 00:53:08 PST
> Does this mean the comm tree has its own versions of these (or of all the
pref) > files?

No, the content of all-ns.js, ... overwrites the content of all.js, .... So,
they contain just the "diff".
Comment 46 User image Alec Flett 2001-01-23 11:57:02 PST
also note that stuff like the addressbook dynamically constructs the "ldap"
prefs - i.e. make sure that the names of the ones you are removing aren't being
dynamically constructed by the code in mozilla/mailnews/addrbook/

I'm not going to sr= the mailnews prefs diffs specifically because I'd rather
leave that to a mail guy.
Comment 47 User image Blake Ross 2001-01-23 12:39:32 PST
Yeah, I'm not going to touch most of the ldap ones now because it's hard to see 
which ones are unused, due to the way they're referenced and constructed.

bienvenu already sr='d the mail stuff, it's in.  New patches coming later.
Comment 48 User image Ben Bucksch (:BenB) 2001-03-03 17:12:02 PST
Mass-change: Do not remove nominations (even if Milestone passed). Readding
mozilla0.8 nomination.
Comment 49 User image Ben Bucksch (:BenB) 2001-04-17 16:29:00 PDT
Nominating for mozilla1.0. Rationale: This is an important place to tweak for
people who use Mozilla code, but don't know the internals too well. They'll get
lost in the 4.x prefs.
Comment 50 User image Steve Meredith (gone) 2001-12-17 08:47:30 PST
I am working on CCK and trying to understand which prefs are being used by the
app, and have been frustrated by the all the bogus prefs laying around. I urge
for work on this bug to continue, or at least for somebody to check in the work
that has been done so far.
Comment 51 User image benc 2001-12-17 08:59:33 PST
Why don't we take the beginning of 0.9.8 as an opporunity to start removing some
of this stuff?
Comment 52 User image Alec Flett 2001-12-17 09:14:10 PST
the patches here are almost a year old, but someone (mcafee?) might be able to
go back through and see what was being removed.
Comment 53 User image benc 2001-12-17 10:10:27 PST
tweaked summary (before it read too much like "prefs.js")
Comment 54 User image Steve Meredith (gone) 2001-12-18 11:37:42 PST
Looks like the following could be removed from mailnews.js:
Comment 55 User image Alec Flett 2001-12-18 11:40:23 PST
we need to make sure removing those doesn't break 4.x migration as well. cc'ing
sspitzer for his input on how 4.x profile migration works. oh wait, he's already
cc'ed. seth?
Comment 56 User image Brian Ryner (not reading) 2002-01-15 20:33:21 PST
*** Bug 113020 has been marked as a duplicate of this bug. ***
Comment 57 User image Serge Gautherie (:sgautherie) 2008-06-11 15:01:55 PDT
(Filter "spam" on 'prefs-nobody-20080612'.)

Note You need to log in before you can comment on or make changes to this bug.