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

VERIFIED FIXED

Status

Mozilla Labs Graveyard
Test Pilot Studies
VERIFIED FIXED
8 years ago
2 years ago

People

(Reporter: KWierso, Unassigned)

Tracking

Details

(Whiteboard: [Input])

(Reporter)

Description

8 years ago
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).
(Reporter)

Comment 2

8 years ago
(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

Comment 4

8 years ago
Even after another sync and upgrading to FF4, didn't fix.  Had to reset the homepage uri in the preferences pane.
(Reporter)

Comment 5

8 years ago
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.
(Reporter)

Comment 6

8 years ago
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?

Comment 10

8 years ago
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.

Comment 13

8 years ago
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

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

Comment 15

8 years ago
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: --- → --

Comment 16

8 years ago
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.

Updated

8 years ago
Summary: Sync is changing some preferences values to "Custom Value". → Test Pilot is changing some preferences values to "Custom Value".

Comment 17

8 years ago
(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?

Comment 20

8 years ago
Jono, do you have a list of the prefs that were affected?
(Reporter)

Comment 21

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

Updated

8 years ago
Duplicate of this bug: 594469

Comment 23

8 years ago
Wes's list is correct.

I will release an update implementing Ed's suggestion.

Comment 24

8 years ago
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

8 years ago
This is also breaking HTTPS web browsing for users who need proxies.
(Reporter)

Comment 26

7 years ago
Marking bug fixed to clear out my bug list.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
verified with recent build of TP running dev channel studies
Status: RESOLVED → VERIFIED

Updated

7 years ago
Duplicate of this bug: 594097
(Assignee)

Updated

2 years ago
Product: Mozilla Labs → Mozilla Labs Graveyard
You need to log in before you can comment on or make changes to this bug.