If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

regression: user.js no longer overrides prefs.js

VERIFIED FIXED in mozilla0.9.2

Status

()

Core
Preferences: Backend
P2
normal
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: Akkana Peck, Assigned: Brian Nesse (gone))

Tracking

({regression})

Trunk
mozilla0.9.2
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [r][sr][a] trunk only)

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
If I change a pref in my user.js, the change is ignored.  The old value is still
stored in prefs.js, and user.js, which is supposed to override prefs.js, no
longer does as of a recent change to prefs.
(Reporter)

Updated

17 years ago
Keywords: regression
(Assignee)

Comment 1

17 years ago
I take it that this is a file you've added? I don't seem to have one.
Status: NEW → ASSIGNED
(Reporter)

Comment 2

17 years ago
User.js is a place where users can store their own prefs, safe from overwriting
by mozilla.  It lives in the profile directory next to prefs.js.
brian: a user would create the user.js by hand and place it in the same
directory as the prefs.js.

Comment 4

17 years ago
Should useUserPrefFile() in nsPrefService.cpp use
  openPrefFile(aFile, PR_FALSE, PR_FALSE, PR_FALSE, PR_TRUE)
instead of
  openPrefFile(mCurrentFile, PR_FALSE, PR_FALSE, PR_FALSE, PR_TRUE)
?
(Assignee)

Comment 5

17 years ago
Yes, that would probably make a big difference.
(Assignee)

Comment 6

17 years ago
Created attachment 32781 [details] [diff] [review]
Fix to properly load user.js
(Assignee)

Comment 7

17 years ago
cc'ing srilatha for an r and alecf for an sr on the patch.

Comment 8

17 years ago
r=srilatha

Comment 9

17 years ago
sr=alecf
(Assignee)

Comment 10

17 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
reopening, since user.js still appears to be ignored. tested using 2001.05.29.08
comm bits on linux.

to test this, i created a user.js that simply overrode the default homepage. its
contents are simply:

  user_pref("browser.startup.homepage", "http://www.snopes.com/");

the default homepage that's in my prefs.js is http://bugzilla.mozilla.org/
--however, when i restart the browser, the default page is still the Bugzilla
page, not the one at Snopes.com.

i think whatever's in the user.js is currently being ignored --i tried another
test where i have a pref that's not explicitly mentioned in my prefs.js: in
user.js i put:

  user_pref("ui.key.menuAccessKeyFocuses", true);

[this allows hitting the menu access key, Alt in my case, to focus on the
menubar; by default this is off (false).]

after i restart the browser, however, this pref isn't activated --as if
menuAccessKeyFocuses is still false.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 12

17 years ago
Hmm, this is actually a different bug, but I'm willing to fix it here :)

The problem is that openPrefFile is being called with the "skipFirstLine" flag
set to TRUE. I'm surprised that this hasn't shown up before now. It's been in
the code since the first revision of user.js support was integrated into Mozilla
back in '99. I went back to 4.x and verified that the first line is NOT supposed
to be skipped for user.js.
(Assignee)

Comment 13

17 years ago
Created attachment 36556 [details] [diff] [review]
Patch to not skip the first line of user.js

Comment 14

17 years ago
In my opinion, this should go into 0.9.1. It seams to be a safe fix, and to many
this is an important feature. Do people agree with me?

Comment 15

17 years ago
Since all versions of N6 have never read in the first line of user.js, people
using this feature will not experience any loss of functionality even without
this fix.

Moving to 0.9.2, P2.
Keywords: nsbeta1
Priority: -- → P2
Target Milestone: --- → mozilla0.9.2

Comment 16

17 years ago
sr=alecf
the fix is VERY simple, and only affects the reading of user.js, if the user
even has it...I think this is incredibly safe for 0.9.1.

Comment 17

17 years ago
r=chipc
This ONLY changes the reading of user.js... and even then only allows the
reading of the first line.   I agree, a very safe (simple) fix.
(Assignee)

Updated

17 years ago
Whiteboard: [r][sr][need drivers approval]

Updated

17 years ago
Blocks: 83989
a=dbaron for trunk checkin (on behalf of drivers)
Whiteboard: [r][sr][need drivers approval] → [r][sr][a]
(Assignee)

Comment 19

17 years ago
Fix checked in.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
Whiteboard: [r][sr][a] → [r][sr][a] trunk only
excellent, works now.

tested using 2001.06.19.08 comm bits on linux. as in my 2001-05-29 17:09
comments, i just had a user.js which contained:

  user_pref("browser.startup.homepage", "http://www.snopes.com/");

upon restarting the app, the default home page went to the Snopes site.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.