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

Status: VERIFIED FIXED

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

Description

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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.

Comment 1

[Philipp von Weitershausen [:philikon]]

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).

Comment 2

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(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.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 4

[Justin Fitzhugh]

Even after another sync and upgrading to FF4, didn't fix.  Had to reset the homepage uri in the preferences pane.

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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.

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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?

Comment 7

[Mike Connor [:mconnor]]

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.

Comment 8

[Mike Connor [:mconnor]]

Also, the actual _value_ of the prefs is "Custom Value" ?

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 10

[Ragavan S [:rags]]

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.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Connor asked me if we changed any .js pref bundles recently; on hourlies we did, see bug 592127

Comment 12

[Mike Connor [:mconnor]]

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.

Comment 13

[Justin Fitzhugh]

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.

Comment 14

[Ragavan S [:rags]]

I've pointed Jono at this bug to see if Test Pilot is doing something here.

Comment 15

[Michael Lefevre]

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.

Comment 16

[Jono Xia]

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.

Comment 17

[Ed Lee :Mardak]

(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"

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 19

[Aakash Desai [:aakashd]]

I'm not sure how useful this is, but http://input.mozilla.com/en-US/search/?product=firefox&date_start=&date_end=&version=4.0b5&q=home+custom+value

Comment 20

[[:Cww]]

Jono, do you have a list of the prefs that were affected?

Comment 21

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(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/
 ];

Comment 23

[Jono Xia]

Wes's list is correct.

I will release an update implementing Ed's suggestion.

Comment 24

[Jono Xia]

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.

Comment 25

[[:Cww]]

This is also breaking HTTPS web browsing for users who need proxies.

Comment 26

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Marking bug fixed to clear out my bug list.

Comment 27

[Tracy Walker [:tracy]]

verified with recent build of TP running dev channel studies