Closed Bug 594178 Opened 10 years ago Closed 10 years ago

Test Pilot is changing some preferences values to "Custom Value".

Categories

(Mozilla Labs Graveyard :: Test Pilot Studies, defect)

x86
Windows 7
defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: KWierso, Unassigned)

References

Details

(Whiteboard: [Input])

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre
Build Identifier: 

Using a recent hourly, I noticed that I got an error prompt whenever I clicked the Home button, saying that the URL is not valid, and can't be opened.

Looking in the Options pane, I saw that my homepage was set to "Custom Value".

Searching in about:config for "Custom", I see a handful of preferences with values set to "Custom Value": 
browser.startup.homepage, browser.startup.homepage_override.buildID, browser.startup.homepage_override.mstone, and print.printer_*.print_to_filename (where * is the name of the printer, I had two of these prefs)

I reset the homepage prefs to the proper URL, and restarted the browser, and the pref had returned to "Custom Value".

On IRC, Gavin suggested disabling Sync. I did that, reset the prefs again, and restarted the browser.
The correct prefs stayed.

Reproducible: Always

Steps to Reproduce:
1. Set up Sync to sync prefs.
2. Try to access your homepage (maybe need a non-default homepage set?)
3. See the problem.
These preferences were probably synced over from one of your other machines. You can stop Sync from applying them by setting the services.sync.prefs.sync.<pref> preferences to false (where <pref> is the preference you don't want to have applied).

I suspect this could be one of the problems we might avoid by only syncing changes from the default prefs (bug 582536).
(In reply to comment #1)
> These preferences were probably synced over from one of your other machines.
> You can stop Sync from applying them by setting the
> services.sync.prefs.sync.<pref> preferences to false (where <pref> is the
> preference you don't want to have applied).
> 
> I suspect this could be one of the problems we might avoid by only syncing
> changes from the default prefs (bug 582536).

I only have the one machine (Sync is more of a backup tool for me), and it worked fine for me up until sometime today.
Justin saw this too on a computer using Firefox 3.6.10pre, so maybe something that's landed recently there?

We need to understand if it's affecting shipping versions of Firefox, PDQ. Resetting the homepage URI is pretty noticable.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Even after another sync and upgrading to FF4, didn't fix.  Had to reset the homepage uri in the preferences pane.
I just unchecked "Sync preferences" in the Options pane, and reset my homepage again, then restarted Firefox. Upon restarting, about:config showed the correct homepage value, but then it switched to "Custom Value" after a few seconds.
Hit Save Changes too soon...


Plus, I'm not even connected to Sync, so unless it does something before even trying to sync, maybe this isn't because of Sync?
Can you copy/paste from about:support (there's a link).  Please feel free to email if you don't want it in the bug.
Also, the actual _value_ of the prefs is "Custom Value" ?
Yes, the actual value is "Custom Value". Comment 6 implies that this might not be related to Sync at all, though.

Wes: do you have the Sync Add-On installed, as well?
fwiw, browser.startup.homepage_override.mstone is set to "Custom Value" for me. 
browser.startup.homepage is set to the default value. 

This is on Fx 4 Beta 4. 

Other add-ons I have installed:
BarTab
Feedback
Feedly
Rapportive

The Firefox Sync add-on (and other add-ons) are installed, but disabled.
Connor asked me if we changed any .js pref bundles recently; on hourlies we did, see bug 592127
Looks like test pilot is probably in play here:

http://mxr.mozilla.org/labs-central/source/testpilotweb/testcases/a-week-life/about_firefox.js#59 suspiciously similar set of prefs
http://mxr.mozilla.org/labs-central/source/testpilotweb/testcases/a-week-life/about_firefox.js#130 where the pref gets set to "Custom Value" if I remember fuel right.
I did have test pilot installed both in 3.6.x and 4, so I can confirm that it was there and enabled when the issue happened.
I've pointed Jono at this bug to see if Test Pilot is doing something here.
I'm not using sync, and this "custom value" stuff happened to me just as a new test pilot study started. The study is collecting prefs, and hiding personalised data in those prefs. So I guess it's setting the prefs to "custom value" when it should just be recording "custom value" for the study.
Component: Firefox Sync: Backend → Test Pilot Studies
Product: Mozilla Services → Mozilla Labs
QA Contact: sync-backend → test-pilot-studies
Target Milestone: --- → --
Verified, this is a Test Pilot bug, not a Sync bug.

Totally my fault; I was trying to protect potentially personal information from getting into the test pilot study results, so I was recording "Custom Value" for modified prefs that match the blacklist.  Thought that since I wasn't calling prefs.set(), I wasn't changing the value of the actual pref, but it looks like using the FUEL interface means this is a live object and setting its .value actually changes the underlying pref.

I just fixed it by copying the value from the pref to a new object and using that.  The fix is in http://hg.mozilla.org/labs/testpilotweb/rev/bf292fe32cf5 and has now been released to Test Pilot / Feedback users.  Unfortunately there is no way to reset the prefs to their original values, but at least we can stop this from affecting anyone else.
Summary: Sync is changing some preferences values to "Custom Value". → Test Pilot is changing some preferences values to "Custom Value".
(In reply to comment #16)
> Unfortunately there
> is no way to reset the prefs to their original values, but at least we can stop
> this from affecting anyone else.
We could just set it to the default value if not the original one when detecting that the value is "Custom Value"
Yes, we should do as Ed suggests in Comment 17; not great, but better than a broken value.

Jono: I think we might want to start requiring review for Test Pilot studies. Any way to know how many beta users this affects?
Jono, do you have a list of the prefs that were affected?
(In reply to comment #20)
> Jono, do you have a list of the prefs that were affected?

Looking at mxr, looks like this code defines the pref blacklist:
const PREFS_BLACKLIST = [
   /^network[.]proxy[.]/,
   /[.]print_to_filename$/,
   /browser.startup.homepage/
 ];
Duplicate of this bug: 594469
Wes's list is correct.

I will release an update implementing Ed's suggestion.
Ed's suggestion done in http://hg.mozilla.org/labs/testpilotweb/rev/beb230e1fa65 and released.

I don't know if we can accurately measure how many beta4 users this affected, unfortunately.  It would have affected anyone who has user studies turned on and who had a modified value for any of the blacklisted prefs; those users may or may not submit their data, though, so we'll never know the exact number.  When the data comes in we can give a rough estimate.
This is also breaking HTTPS web browsing for users who need proxies.
Marking bug fixed to clear out my bug list.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
verified with recent build of TP running dev channel studies
Status: RESOLVED → VERIFIED
Duplicate of this bug: 594097
Product: Mozilla Labs → Mozilla Labs Graveyard
You need to log in before you can comment on or make changes to this bug.