Open Bug 1049939 Opened 5 years ago Updated 5 years ago

[mozprofile] --prefs CLI option causes duplicated pref entries in user.js


(Testing :: Mozbase, defect)

Not set


(Not tracked)


(Reporter: mmc, Unassigned)


Running a test with an existing profile and --pref=key:value does not seem to overwrite the pref.

mozmill -b /Applications/ --pref=privacy.trackingprotection.enabled:true --profile=/Users/mchew/Library/Application Support/Firefox/Profiles/7fwv2ryx.test-defaults -t mytests/mytest.js

test code is

  dump("- INFO: privacy.trackingprotection.enabled " + (prefs.preferences.getPref("privacy.trackingprotection.enabled", false)) + "\n");

Output is
- INFO: privacy.trackingprotection.enabled false
whimboo says this is a mozrunner issue, but I couldn't find a component for that.
Actually this is not mozrunner but mozprofile. I quick look showed me that we do some bad stuff when using an existing profile:

$ cat /tmp/tmpJqQM5h.mozrunner/user.js 

#MozRunner Prefs Start 1407365876.52 cb546fb1-6fd2-4525-85a9-05e771bfddda
user_pref("abc", true);
#MozRunner Prefs End 1407365876.52 cb546fb1-6fd2-4525-85a9-05e771bfddda

#MozRunner Prefs Start 1407366001.82 8db4ba6f-9f9d-4834-891e-4195b3a1b15c
user_pref("abc", false);
#MozRunner Prefs End 1407366001.82 8db4ba6f-9f9d-4834-891e-4195b3a1b15c

As you can see we duplicate entries instead of replacing them. So Firefox only cares about the first entry found.
OS: Mac OS X → All
Hardware: x86 → All
Summary: mozmill --prefs does not seem to work → [mozprofile] --prefs CLI option causes duplicated pref entries in user.js
Andrew, who from the ateam could mentor this bug?
Flags: needinfo?(ahalberstadt)
I can mentor if someone really wants to tackle it, but I don't think this is a good first bug. Fixing this properly will require some fundamental changes to mozprofile, and I also think there is a high risk of causing bustage along the way.
Flags: needinfo?(ahalberstadt)
You need to log in before you can comment on or make changes to this bug.