Closed
Bug 1212509
Opened 9 years ago
Closed 9 years ago
repacks cannot override sticky prefs
Categories
(Firefox :: Settings UI, defect)
Firefox
Settings UI
Tracking
()
RESOLVED
INVALID
Tracking | Status | |
---|---|---|
firefox41 | --- | affected |
firefox42 | --- | unaffected |
firefox43 | --- | unaffected |
firefox44 | --- | unaffected |
People
(Reporter: mixedpuppy, Unassigned)
References
Details
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•9 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•9 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•9 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•9 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.
Comment 5•9 years ago
|
||
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•9 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
Reporter | ||
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•