Running a test with an existing profile and --pref=key:value does not seem to overwrite the pref. mozmill -b /Applications/FirefoxNightly.app/Contents/MacOS/firefox-bin --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.
Andrew, who from the ateam could mentor this bug?
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.