Closed Bug 33115 Opened 25 years ago Closed 12 years ago

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

Categories

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

defect

Tracking

()

RESOLVED INCOMPLETE
Future

People

(Reporter: sfraser_bugs, Unassigned)

References

Details

(Keywords: helpwanted, memory-footprint, perf, Whiteboard: [nav+perf])

Attachments

(6 files)

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.
Adding perf keyword for startup time.
Keywords: perf
*** Bug 35403 has been marked as a duplicate of this bug. ***
Adding L10n folks to cclist.
== 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
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.
M17 (or later).
Target Milestone: --- → M17
Move to M20 target milestone.
Target Milestone: M17 → M21
Keywords: nsbeta2
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.
Whiteboard: [nsbeta2-]
Nav triage team: [nsbeta3-]
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.
Keywords: nsbeta3
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.)
Assignee: matt → dveditz
Component: Preferences → Preferences: Backend
Keywords: nsbeta2helpwanted
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta3-]
*** Bug 55519 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0
OS: Mac System 8.5 → All
Nominate for RTM. This will help startup performance.
Keywords: rtm
Whiteboard: [nsbeta3-]
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.
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.
Whiteboard: [rtm-]
> 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.
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.
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.
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.
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.
no need to do this for rtm.
*** Bug 64693 has been marked as a duplicate of this bug. ***
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
Whiteboard: [rtm-]
Dan, if you don't have the time to do this, I can take it...
-> blake. thanks blake!
Assignee: dveditz → blakeross
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → mozilla0.8
r=dveditz for the first patch. The custtoolbar prefs appear unused, and were added long ago.
alec, sr?
sr=alecf
r=valeski on 01/17/01 13:45 patch. get 'em outta here! :-)
more great work! thanks blake!
r=timeless
nice. sr=alecf
Attached patch [patch][4a] forgot this, sorry (deleted) — Splinter Review
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>
double check with bienvenu before removing the offline prefs. (I sent a private email to blake about this.)
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
thanks for the feedback, david. r=sspitzer, too. thanks for doing the cleanup, blake.
> 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.
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...?
> 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".
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.
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.
Target Milestone: mozilla0.8 → mozilla0.9
Keywords: mozilla0.8.1
Keywords: mozilla0.8
Mass-change: Do not remove nominations (even if Milestone passed). Readding mozilla0.8 nomination.
Keywords: mozilla0.8
Target Milestone: mozilla0.9 → mozilla0.9.2
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.
Keywords: mozilla1.0
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Whiteboard: [nav+perf]
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla1.0
Target Milestone: mozilla1.0 → Future
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.
Why don't we take the beginning of 0.9.8 as an opporunity to start removing some of this stuff?
the patches here are almost a year old, but someone (mcafee?) might be able to go back through and see what was being removed.
tweaked summary (before it read too much like "prefs.js")
Summary: Remove obsolete prefs from default prefs .js files → Remove obsolete prefs from .js files in <app>/defaults/prefs dir
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
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?
*** Bug 113020 has been marked as a duplicate of this bug. ***
Depends on: 205077
Assignee: bross2 → prefs
Status: ASSIGNED → NEW
QA Contact: bugzilla
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
QA Contact: preferences → preferences-backend
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: