Closed
Bug 58326
Opened 24 years ago
Closed 8 years ago
Don't compress prefs.js
Categories
(Core :: Preferences: Backend, defect, P3)
Core
Preferences: Backend
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: BenB, Unassigned)
References
Details
(Keywords: helpwanted)
Problem:
- Distributors may want to change defaults (e.g. Netscape 6' and Mozilla's
defaults differ).
- Mozilla deletes all prefs from the user's prefs.js that match the default.
-> For boolean user prefs are deleted after you run 2 Mozilla distros with
different defaults for them.
Proposed solution:
Do not delete "redundant" entries in prefs.js at shutdown.
This is probably XP, but I'm not sure.
One of Mozilla's problems (along with all previous netscape browsers) is that it
does not distinguish between the case where a factory default has never been
changed but the user and the case where the user's setting happens to be the
same as the factory default. Mozilla should remember all user settings. It
avoids surprises when the factory default changes.
Comment 3•24 years ago
|
||
changing the component and reassigning to the component owner.
Assignee: putterman → dveditz
Component: Profile Manager BackEnd → Preferences: Backend
QA Contact: gbush → sairuh
Comment 4•24 years ago
|
||
How do we distinguish between a user who specifically wants the value that is
the product default and a user who just wants to go back to the default setting
so that it might change in the future?
Currently our choices would be to do the stripping we currently do, or write
out everything. I guess we could add a flag to each and every pref indicating
whether the setting came from the user or not but I'm not sure the bloat would
be worth the result. And then we have to figure out how to decide the first
question.
This really only matters if you're sharing profiles between Mozilla
distributions that have different defaults. How common is that? well, not all
that common in the larger picture. But probably upwards of 90% of mozilla
developers will try Netscape 6 at least once, and Netscape employees will
obviously spend a lot of time in N6.
For the savvy there is 'user.js' -- you put your persistent prefs in there and
they will never be overwritten. But that's a solution very few will find
palatable, and it would be nice if you could use the prefs UI to change your
settings (user.js values override prefs.js values, and user.js is never written
to, only read).
There's already a flag value in the pref structure, so doing this change would
not contribute to bloat as I feared at first. Looks doable.
Comment 5•24 years ago
|
||
If someone else wants to play with this see the file
mozilla/modules/libpref/src/prefapi.c in the pref_HashPref() function,
specifically the "case PREF_SETUSER:" section around line 1779 and following.
Keywords: helpwanted
Reporter | ||
Comment 6•24 years ago
|
||
> This really only matters if you're sharing profiles between Mozilla
> distributions that have different defaults. How common is that? well, not all
> that common in the larger picture.
Agreed, but the purpose of mozilla.org is to encorage usage of Mozilla sources
(including in apps other than Netscape 6). Distributions "competing" with
Netscape 6 will most likely *all* face that problem. So, if you look from the
Netscape side, this problem occurs for a very small percentage of users. If you
look from the perspective of the alternate Mozilla distributor, nearly 100% of
the users will have that problem. Your positiono is understandable.
Thanks for the code hint.
> 1776 case PREF_SETUSER:
> 1777 /* If setting to the default value, then un-set the user value.
> 1778 Otherwise, set the user value only if it has changed */
Would this bug be fixed, if I just removed that first case and wrote the pref
(that is to the runtime-database, I guess) no matter what?
Comment 7•24 years ago
|
||
You chopped off my comment in your reply! Obviously the important part of what
I was saying is that even though this doesn't affect that many *end* users, it
affects a large portion of non-Netscape mozilla developers (those who also
run N6 just to try it) and *ALL* Netscape developers who constantly run both
trees.
As to the code hint, my first-impression guess was that you could axe the first
part of the if, but I'd want to play with it a bit. I'm only a default
caretaker for this code -- it's bounced around quite a lot and needs a real
owner.
Reporter | ||
Comment 8•24 years ago
|
||
dveditz, then I misunderstood your comment. Sorry.
> my first-impression guess was that you could axe the first
> part of the if, but I'd want to play with it a bit.
OK, I'll just try it out.
Comment 10•24 years ago
|
||
ooh, just the bug i was looking for.
so here's my suggestion:
add a preference indicating the prefs file that prefs.js was last compressed
against so that if the file isn't the same we can try loading prefs from it and
prefs.js and then taking new defaults from the current app.
when prefs are serialized again, either change or don't change the preference,
if you update the preference then of course compress against the update, if you
don't then compress against the current value.
If a user runs and the app can't find the referenced spec file, provide some
warning.
Comment 11•23 years ago
|
||
re: Comment #4
how to tell if user set pref to default in the prefs.js
intending it to be "sticky" vs intending it to return to
the factory std, and follow that std if it ever changed.
answer:
user should *delete* the pref line if they want it to
follow future changes to the factory standard, and modify
the pref line if they want their change to stick.
Also:
Can this bug be closed? Doesn't user.js address this whole
issue well enough?
-matt
Reporter | ||
Comment 12•23 years ago
|
||
> Doesn't user.js address this whole issue well enough?
No user.js is never touched by Mozilla, not even by the prefs panel. The problem
in this bug is that the user's prefs, probably sat via the prefs panel, are
resetted.
Updated•23 years ago
|
Blocks: profile-corrupt
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 13•22 years ago
|
||
Can someone explain how this works in greater detail? Does this have to do w/
"pref" vs. "user_pref"?
Updated•16 years ago
|
Assignee: dveditz → nobody
QA Contact: bugzilla → prefs
Updated•15 years ago
|
QA Contact: preferences → preferences-backend
Comment 14•15 years ago
|
||
This is a mass change. Every comment has "assigned-to-new" in it.
I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•