33115 - Remove obsolete prefs from .js files in <app>/defaults/prefs dir

Status: RESOLVED INCOMPLETE

(Core :: Preferences: Backend, defect, P2)

Description

[Simon Fraser [no longer active]]

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

[Simon Fraser [no longer active]]

Adding perf keyword for startup time.

Comment 2

[Fergus Sullivan]

*** Bug 35403 has been marked as a duplicate of this bug. ***

Comment 3

[Fergus Sullivan]

Adding L10n folks to cclist.

Comment 4

[tao]

== defaults/pref/config.js 

If I am right, the only one would survive is 

     
config("startup.homepage_override_url","http://www.mozilla.org/mozorg.html");


All the following are dead now.

== BEGIN 

// Default configuration information for the client 
// 

 
config("autoadmin.append_emailaddr",false); 
config("autoadmin.failover_to_cached",true); 

config("toolbar.logo.url","http://home.netscape.com/"); 
config("toolbar.logo.win_small_file",""); 
config("toolbar.logo.win_large_file",""); 
config("toolbar.logo.frames",-1); 

config("toolbar.places.default_url","http://guide.netscape.com"); 

config("toolbar.places.item_0.label","The Internet"); 
config("toolbar.places.item_0.url","http://guide.netscape.com"); 
config("toolbar.places.item_1.label","People"); 
config("toolbar.places.item_1.url","http://guide.netscape.com/guide/people.html"); 
config("toolbar.places.item_2.label","Yellow Pages"); 
config("toolbar.places.item_2.url","http://guide.netscape.com/guide/yellow_pages.html"); 
config("toolbar.places.item_3.label","What's New"); 
config("toolbar.places.item_3.url","http://guide.netscape.com/guide/whats_new.html"); 
config("toolbar.places.item_4.label","What's Cool"); 
config("toolbar.places.item_4.url","http://guide.netscape.com/guide/whats_cool.html"); 

config("internal_url.net_search.url","http://home.netscape.com/home/internet-search.html");

config("internal_url.more_info_plugin.url","http://cgi.netscape.com/eng/mozilla/2.0/extensions/info.cgi");

config("internal_url.default_template.url","http://home.netscape.com/home/gold3.0_templates.html");

config("internal_url.page_from_wizard.url",
"http://home.netscape.com/home/gold4.0_wizard.html"); 

config("menu.places.item_0.label","The &Internet"); 
config("menu.places.item_0.url","http://guide.netscape.com"); 
config("menu.places.item_1.label","&People"); 
config("menu.places.item_1.url","http://guide.netscape.com/guide/people.html"); 
config("menu.places.item_2.label","&Yellow Pages"); 
config("menu.places.item_2.url","http://guide.netscape.com/guide/yellow_pages.html"); 
config("menu.places.item_3.label","What's &New"); 
config("menu.places.item_3.url","http://guide.netscape.com/guide/whats_new.html"); 
config("menu.places.item_4.label","What's &Cool"); 
config("menu.places.item_4.url","http://guide.netscape.com/guide/whats_cool.html"); 

config("menu.help.item_0.label","&Help Contents"); 
config("menu.help.item_0.url","nethelp:netscape/home:start_here"); 
config("menu.help.item_1.label","&Release Notes"); 
config("menu.help.item_1.url","http://home.netscape.com/eng/mozilla/4.0/relnotes/windows-4.02.html");

config("menu.help.item_2.label","&Product Information and Support"); 
config("menu.help.item_2.url","http://home.netscape.com/menu/prodsupp/client/"); 
config("menu.help.item_3.label","-"); 
config("menu.help.item_4.label","&Software Updates"); 
config("menu.help.item_4.url","http://home.netscape.com/home/update.html"); 
config("menu.help.item_5.label","Register No&w"); 
config("menu.help.item_5.url","http://home.netscape.com/home/register.html"); 
config("menu.help.item_6.label","&Member Services"); 
config("menu.help.item_6.url","http://home.netscape.com/home/services.html"); 
config("menu.help.item_7.label","-"); 
config("menu.help.item_8.label","&International Users"); 
config("menu.help.item_8.url","http://home.netscape.com/menu/intl/"); 
config("menu.help.item_9.label","S&ecurity"); 
config("menu.help.item_9.url","http://home.netscape.com/info/security-doc.html"); 
config("menu.help.item_10.label","Net Etiq&uette"); 
config("menu.help.item_10.url","http://home.netscape.com/menu/netet/"); 
config("menu.help.item_11.label","-"); 
config("menu.help.item_12.label","Abou&t Plug-ins"); 
config("menu.help.item_12.url","about:plugins"); 
config("menu.help.item_13.label","About Font &Displayers"); 
config("menu.help.item_13.url","about:fonts"); 

config("personal_toolbar.item_0.label","Internet"); 
config("personal_toolbar.item_0.url","http://guide.netscape.com/?t"); 
config("personal_toolbar.item_1.label","Lookup"); 
config("personal_toolbar.item_1.url","FOLDER"); 
config("personal_toolbar.item_1.item_0.label","People"); 
config("personal_toolbar.item_1.item_0.url","http://guide.netscape.com/guide/people.html?t"); 
config("personal_toolbar.item_1.item_1.label","Yellow Pages"); 
config("personal_toolbar.item_1.item_1.url","http://guide.netscape.com/guide/yellow_pages.html?t");

config("personal_toolbar.item_2.label","New&Cool"); 
config("personal_toolbar.item_2.url","FOLDER"); 
config("personal_toolbar.item_2.item_0.label","What's New"); 
config("personal_toolbar.item_2.item_0.url","http://guide.netscape.com/guide/whats_new.html?t");

config("personal_toolbar.item_2.item_1.label","What's Cool"); 
config("personal_toolbar.item_2.item_1.url","http://guide.netscape.com/guide/whats_cool.html?t");

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

== END 

Comment 5

[(not reading, please use [e-mail] instead)]

if tao is right (which I believe he is), we should move
"startup.homepage_override_url"
 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

[don]

M17 (or later).

Comment 7

[don]

Move to M20 target milestone.

Comment 8

[leger]

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

[verah (gone)]

Nav triage team: [nsbeta3-]

Comment 10

[Daniel Veditz [:dveditz]]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.

Comment 11

[sairuh (rarely reading bugmail)]

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

[sairuh (rarely reading bugmail)]

*** Bug 55519 has been marked as a duplicate of this bug. ***

Comment 13

[Simon Fraser [no longer active]]

Nominate for RTM. This will help startup performance.

Comment 14

[Ben Bucksch (:BenB)]

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

[Daniel Veditz [:dveditz]]

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

[Ben Bucksch (:BenB)]

> 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

[Ben Bucksch (:BenB)]

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

[Simon Lucy]

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

[Ben Bucksch (:BenB)]

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

[Ben Bucksch (:BenB)]

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

[(not reading, please use [e-mail] instead)]

no need to do this for rtm.

Comment 22

[sairuh (rarely reading bugmail)]

*** Bug 64693 has been marked as a duplicate of this bug. ***

Comment 23

[sairuh (rarely reading bugmail)]

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.

examples:

browser.display_while_loading
browser.delay_images 

Comment 24

[Blake Ross]

Dan, if you don't have the time to do this, I can take it...

Comment 25

[Judson Valeski]

-> blake. thanks blake!

Comment 26

[Blake Ross]

Attachment: [patch][1] remove some unused toolbar prefs

Comment 27

[Daniel Veditz [:dveditz]]

r=dveditz for the first patch. The custtoolbar prefs appear unused, and were
added long ago.

Comment 28

[Blake Ross]

alec, sr?

Comment 29

[Alec Flett]

sr=alecf

Comment 30

[Blake Ross]

Attachment: [patch][2] more random pref removal...

Comment 31

[Judson Valeski]

r=valeski on 01/17/01 13:45 patch. get 'em outta here! :-)

Comment 32

[Alec Flett]

more great work! thanks blake!

Comment 33

[Blake Ross]

Attachment: [patch] more random removal...not complete by any means

Comment 34

[Blake Ross]

Attachment: [patch][3a] forgot to remove something else

Comment 35

[timeless]

r=timeless

Comment 36

[Alec Flett]

nice. sr=alecf

Comment 37

[Blake Ross]

Attachment: [patch][4] remove mailnews prefs

Comment 38

[Blake Ross]

Attachment: [patch][4a] forgot this, sorry

Comment 39

[timeless]

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

[(not reading, please use [e-mail] instead)]

double check with bienvenu before removing the offline prefs.

(I sent a private email to blake about this.)

Comment 41

[David :Bienvenu]

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

[(not reading, please use [e-mail] instead)]

thanks for the feedback, david.

r=sspitzer, too.  thanks for doing the cleanup, blake.

Comment 43

[Ben Bucksch (:BenB)]

> 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

[Blake Ross]

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

[Ben Bucksch (:BenB)]

> 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

[Alec Flett]

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

[Blake Ross]

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

[Ben Bucksch (:BenB)]

Mass-change: Do not remove nominations (even if Milestone passed). Readding
mozilla0.8 nomination.

Comment 49

[Ben Bucksch (:BenB)]

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

[Steve Meredith (gone)]

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

[benc]

Why don't we take the beginning of 0.9.8 as an opporunity to start removing some
of this stuff?

Comment 52

[Alec Flett]

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

[benc]

tweaked summary (before it read too much like "prefs.js")

Comment 54

[Steve Meredith (gone)]

Looks like the following could be removed from mailnews.js:
mail.server_type
mail.default_fcc
mail.use_fcc
mail.check_new_mail
mail.check_time
mail.pop_name
mail.remember_password
mail.identity.organization
mail.identity.reply_to
mail.identity.username
mail.identity.useremail
mail.cc_self

Comment 55

[Alec Flett]

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

[Brian Ryner (not reading)]

*** Bug 113020 has been marked as a duplicate of this bug. ***

Comment 57

[Serge Gautherie (:sgautherie)]

(Filter "spam" on 'prefs-nobody-20080612'.)