repacks cannot override sticky prefs

RESOLVED INVALID

Status

()

Firefox
Preferences
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: mixedpuppy, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox41 affected, firefox42 unaffected, firefox43 unaffected, firefox44 unaffected)

Details

(Reporter)

Description

3 years ago
repacks (e.g. partner builds, EME-free, funnelcake) are not be able to override any pref that is set with sticky_pref.  This limits testing or disabling of features.

Comment 1

3 years ago
Letting funnelcake builds override these prefs means they may in some cases override active user choices. That doesn't seem like a good idea.

As I noted on IRC, I don't think the pref you want to override in bug 1208658 should be sticky, and I think the way to enable bug 1208658 to happen would be to stop having it be a sticky pref.
(Reporter)

Comment 2

3 years ago
(In reply to :Gijs Kruitbosch from comment #1)
> Letting funnelcake builds override these prefs means they may in some cases
> override active user choices. That doesn't seem like a good idea.

Can you clarify how this would override an active user choice?  sticky prefs prevent modification of that pref by a repack on new profiles, that is a problem.

> As I noted on IRC, I don't think the pref you want to override in bug
> 1208658 should be sticky, and I think the way to enable bug 1208658 to
> happen would be to stop having it be a sticky pref.

And that is a fine approach for this one situation.  IMO there needs to be a general solution.

Comment 3

3 years ago
(In reply to Shane Caraveo (:mixedpuppy) from comment #2)
> (In reply to :Gijs Kruitbosch from comment #1)
> > Letting funnelcake builds override these prefs means they may in some cases
> > override active user choices. That doesn't seem like a good idea.
> 
> Can you clarify how this would override an active user choice?  sticky prefs
> prevent modification of that pref by a repack on new profiles, that is a
> problem.

The explicit point of a funnelcake build is to change the default behaviour. If I have changed a pref, changing the default does not change what I am seeing on my copy of Firefox, because the pref was changed and the user-branch value overrides the (changed) default-branch value.

Your problem is that we are always saving the user-branch of sticky prefs, even if it matches the default, and therefore you could change the default value until kingdom come, it would never override the user's value.

Fundamentally, there is no way to fix this except by overriding the user-set value, which in some cases will be the result of explicit user choice. That is bad.
(Reporter)

Comment 4

3 years ago
(In reply to :Gijs Kruitbosch from comment #3)
> (In reply to Shane Caraveo (:mixedpuppy) from comment #2)
> > (In reply to :Gijs Kruitbosch from comment #1)
> > > Letting funnelcake builds override these prefs means they may in some cases
> > > override active user choices. That doesn't seem like a good idea.
> > 
> > Can you clarify how this would override an active user choice?  sticky prefs
> > prevent modification of that pref by a repack on new profiles, that is a
> > problem.
> 
> The explicit point of a funnelcake build is to change the default behaviour.
> If I have changed a pref, changing the default does not change what I am
> seeing on my copy of Firefox, because the pref was changed and the
> user-branch value overrides the (changed) default-branch value.

Funnelcakes cannot change the default of a sticky pref on a new profile.  The user has not changed anything at that point.
If funnelcake builds are repacks, why not just modify the prefs file, in which case you can just change any kind of pref ?
(Reporter)

Comment 6

3 years ago
This appears to be a bug in Fx 41.  Unable to reproduce in Fx42b4 or nightly/dev build.
status-firefox41: --- → affected
status-firefox42: --- → unaffected
status-firefox43: --- → unaffected
status-firefox44: affected → unaffected
(Reporter)

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.