58326 - Don't compress prefs.js

Status: RESOLVED INCOMPLETE

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

Description

[Ben Bucksch (:BenB)]

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.

Comment 1

[Henri Sivonen (:hsivonen)]

IIRC, this is XP.

Comment 2

[tenthumbs]

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

[scottputterman]

changing the component and reassigning to the component owner.

Comment 4

[Daniel Veditz [:dveditz]]

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

[Daniel Veditz [:dveditz]]

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.

Comment 6

[Ben Bucksch (:BenB)]

> 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

[Daniel Veditz [:dveditz]]

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.

Comment 8

[Ben Bucksch (:BenB)]

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 9

[Daniel Veditz [:dveditz]]

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

Comment 10

[timeless]

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

[m_mozilla]

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

Comment 12

[Ben Bucksch (:BenB)]

> 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.

Comment 13

[benc]

Can someone explain how this works in greater detail? Does this have to do w/
"pref" vs. "user_pref"?

Comment 14

[Michael Kohler [:mkohler]]

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.