Closed Bug 58326 Opened 24 years ago Closed 8 years ago

Don't compress prefs.js

Categories

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

defect

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.
IIRC, this is XP.
OS: Linux → All
Hardware: PC → All
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.
changing the component and reassigning to the component owner.
Assignee: putterman → dveditz
Component: Profile Manager BackEnd → Preferences: Backend
QA Contact: gbush → sairuh
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.
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
> 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?
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.
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.
*** Bug 47628 has been marked as a duplicate of this bug. ***
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.
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
> 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.
Status: NEW → ASSIGNED
Can someone explain how this works in greater detail? Does this have to do w/ "pref" vs. "user_pref"?
Assignee: dveditz → nobody
QA Contact: bugzilla → prefs
QA Contact: preferences → preferences-backend
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
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.