Preferences from netscape.cfg and autoconfig.jsc are being written to prefs.js

RESOLVED INCOMPLETE

Status

()

--
enhancement
RESOLVED INCOMPLETE
17 years ago
4 years ago

People

(Reporter: lrg, Assigned: ccarlen)

Tracking

(Blocks: 1 bug)

Trunk
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
I see this as a problem primarily because of a case in which the netscape.cfg is 
removed or modified (if a new netscape.cfg file is distributed for example).  
While preferences set in the netscape.cfg take presidence over those in the 
prefs.js, any preferences that were set inside of a previous .cfg but are no 
longer present, would be executed. 

Additionally there is some concern over allowing the values present inside of 
the netscape.cfg file to the average users.  While the hashing mechanism isn't 
very secure, having all of the values written to the prefs.js file is much less 
so.

Comment 1

17 years ago
I am not sure why does communicator writes the preferences set in netscape.cfg
back to prefs.js. Is there any way we can avoid writing the autoconfig
preferences  back to prefs.js ?

Updated

17 years ago
QA Contact: sairuh → rvelasco

Updated

17 years ago
Blocks: 113387

Comment 2

17 years ago
mitesh is no longer with us. reassigning to default module owner. bug 113387
tracks the original list of mitesh bugs
Assignee: mitesh → bnesse
QA Contact: rvelasco → sairuh

Comment 3

17 years ago
Is this a regression from Communicator 4.x? I suspect what might have happened
is that N6 writes in the in-memory prefs back to prefs.js. The in-memory prefs
values are filled with the overwritten settings from netscape.cfg. 

Comment 4

17 years ago
Yes, that is exactly what happens. When the preferences are written out any
preferences in memory, which are not default values, are written to prefs.js. I
do not believe this functionality is any different from that of 4.x.

Updated

17 years ago
Target Milestone: --- → Future

Updated

17 years ago
Blocks: 123929

Updated

17 years ago
QA Contact: sairuh → lrg

Comment 5

17 years ago
If I undersand this correctly: the pref values (from cfg) got written into 
user profile's prefs.js only when the values in the prefs.js are different from 
those in cfg. Am I right? Does it matter if the pref values are locked or not?

Could QA confirm how 4.x behaves? thx!
(Reporter)

Comment 6

17 years ago
Only locked prefs are being written into the prefs.js file, others are not. 
This is the same behavior as we see in netscape 4.79, so it isn't a regression.

Comment 7

17 years ago
Luke: thanks for the comment. looks like this is a RFE. Let's revisit it in the
future.
Summary: Preferences from netscape.cfg are being written to prefs.js → [RFE] Preferences from netscape.cfg are being written to prefs.js

Comment 8

16 years ago
removed jhooker from cc: list

Comment 9

16 years ago
*** Bug 171225 has been marked as a duplicate of this bug. ***

Comment 10

16 years ago
Please update the summary to include 'user.js' also, as that's what my duped bug
was about.

Updated

16 years ago
Summary: [RFE] Preferences from netscape.cfg are being written to prefs.js → [RFE] Preferences from user.js, netscape.cfg, and autoconfig.jsc are being written to prefs.js

Comment 11

16 years ago
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement

Updated

16 years ago
Summary: [RFE] Preferences from user.js, netscape.cfg, and autoconfig.jsc are being written to prefs.js → Preferences from user.js, netscape.cfg, and autoconfig.jsc are being written to prefs.js
(Assignee)

Comment 12

16 years ago
Taking some of Brain's bugs since he's no longer here.
Assignee: bnesse → ccarlen
*** Bug 252307 has been marked as a duplicate of this bug. ***
(In reply to comment #13)
> *** Bug 252307 has been marked as a duplicate of this bug. ***

Is there a solution for a user to fix this bug? maybe we've to delete manually 
the line with the general.useragent.override string in prefs.js?
There are a lot of people who change the UA ID for just a while, then delete it 
(some online banks refuse Firefox). I think it's a big bug, just for all the 
people who browse the www not knowing they're giving a wrong UA ID to the sites 
they visit. 

Comment 15

14 years ago
carlo@acfiorentina.net: in about:config you can right click and choose reset.

the right thing to do for this bug is sorta complicated, sorta simple, and 
almost entirely unrelated to your problem.

preferences need to remember who set them, if the user set them, then they need 
to be serialized <period>. otherwise you suffer from the problem where 
switching between apps will eventually set your prefs to match those of the app.
if the user did not set the pref, then it should not be serialized <period>.

Comment 16

14 years ago
IMO the user.js should be removed from the summary (the dupes are wrong). The
user.js issue was invalidated with Bug 50038.
Summary: Preferences from user.js, netscape.cfg, and autoconfig.jsc are being written to prefs.js → Preferences from netscape.cfg and autoconfig.jsc are being written to prefs.js
QA Contact: lrg → preferences-backend
This is so old, I'm going to mark it as incomplete.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.