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)
Core
Preferences: Backend
Tracking
()
RESOLVED
INCOMPLETE
Future
People
(Reporter: sfraser_bugs, Unassigned)
References
Details
(Keywords: helpwanted, memory-footprint, perf, Whiteboard: [nav+perf])
Attachments
(6 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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 3•25 years ago
|
||
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
Comment 5•25 years ago
|
||
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.
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-]
Comment 10•24 years ago
|
||
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so
the queries don't get all screwed up.
Keywords: nsbeta3
Comment 11•24 years ago
|
||
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: nsbeta2 → helpwanted
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta3-]
Comment 12•24 years ago
|
||
*** Bug 55519 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Keywords: mozilla1.0
OS: Mac System 8.5 → All
Reporter | ||
Comment 13•24 years ago
|
||
Nominate for RTM. This will help startup performance.
Keywords: rtm
Whiteboard: [nsbeta3-]
Comment 14•24 years ago
|
||
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•24 years ago
|
||
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-]
Comment 16•24 years ago
|
||
> 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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
no need to do this for rtm.
Comment 22•24 years ago
|
||
*** Bug 64693 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
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-]
Comment 24•24 years ago
|
||
Dan, if you don't have the time to do this, I can take it...
Updated•24 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → mozilla0.8
Comment 26•24 years ago
|
||
Comment 27•24 years ago
|
||
r=dveditz for the first patch. The custtoolbar prefs appear unused, and were
added long ago.
Comment 28•24 years ago
|
||
alec, sr?
Comment 29•24 years ago
|
||
sr=alecf
Comment 30•24 years ago
|
||
Comment 31•24 years ago
|
||
r=valeski on 01/17/01 13:45 patch. get 'em outta here! :-)
Comment 32•24 years ago
|
||
more great work! thanks blake!
Comment 33•24 years ago
|
||
Comment 34•24 years ago
|
||
Comment 35•24 years ago
|
||
r=timeless
Comment 36•24 years ago
|
||
nice. sr=alecf
Comment 37•24 years ago
|
||
Comment 38•24 years ago
|
||
Comment 39•24 years ago
|
||
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•24 years ago
|
||
double check with bienvenu before removing the offline prefs.
(I sent a private email to blake about this.)
Comment 41•24 years ago
|
||
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•24 years ago
|
||
thanks for the feedback, david.
r=sspitzer, too. thanks for doing the cleanup, blake.
Comment 43•24 years ago
|
||
> 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•24 years ago
|
||
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•24 years ago
|
||
> 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•24 years ago
|
||
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•24 years ago
|
||
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.
Updated•24 years ago
|
Target Milestone: mozilla0.8 → mozilla0.9
Updated•24 years ago
|
Keywords: mozilla0.8.1
Updated•24 years ago
|
Keywords: mozilla0.8
Comment 48•24 years ago
|
||
Mass-change: Do not remove nominations (even if Milestone passed). Readding
mozilla0.8 nomination.
Keywords: mozilla0.8
Updated•24 years ago
|
Keywords: mozilla0.8,
mozilla0.8.1
Target Milestone: mozilla0.9 → mozilla0.9.2
Comment 49•24 years ago
|
||
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
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Updated•23 years ago
|
Whiteboard: [nav+perf]
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Updated•23 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.7
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla1.0
Updated•23 years ago
|
Target Milestone: mozilla1.0 → Future
Comment 50•23 years ago
|
||
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•23 years ago
|
||
Why don't we take the beginning of 0.9.8 as an opporunity to start removing some
of this stuff?
Comment 52•23 years ago
|
||
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•23 years ago
|
||
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
Comment 54•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
*** Bug 113020 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Assignee: bross2 → prefs
Status: ASSIGNED → NEW
QA Contact: bugzilla
Comment 57•16 years ago
|
||
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
Updated•15 years ago
|
QA Contact: preferences → preferences-backend
Updated•12 years ago
|
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.
Description
•