Allow .js preference files to set locked prefs

RESOLVED FIXED in Firefox 60

Status

()

defect
RESOLVED FIXED
11 years ago
2 months ago

People

(Reporter: glandium, Assigned: njn)

Tracking

(Blocks 1 bug)

Trunk
mozilla60
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox60 fixed)

Details

Attachments

(3 attachments, 7 obsolete attachments)

Posted patch patch (obsolete) — Splinter Review
The attached patch allows to use lockPref() in any .js preference file (prefs.js, files in default/preferences...)
Attachment #326060 - Flags: review?(darin.moz)
Posted patch patch (obsolete) — Splinter Review
Obviously, neither the debian changelog nor the fprintf should be in the patch. The first patch doesn't exist. You haven't seen it. The only patch existing is this one.
Assignee: nobody → mh+mozilla
Attachment #326060 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #326061 - Flags: review?(darin.moz)
Attachment #326060 - Flags: review?(darin.moz)
Attachment #326061 - Flags: review?(darin.moz) → review?(benjamin)
Because I apparently inherited ownership of this code by default, I'm going to need some more summary here:

* what is the motivation for this change?
* where did lockPref use to work? In what new cases are we making it work?
* I'm going to need tests. I think writing an xpcshell test for this shouldn't be too hard.
Comment on attachment 326061 [details] [diff] [review]
patch

canceling review request until questions are answered
Attachment #326061 - Flags: review?(benjamin)
(In reply to comment #2)
> Because I apparently inherited ownership of this code by default, I'm going to
> need some more summary here:
> 
> * what is the motivation for this change?
> * where did lockPref use to work? In what new cases are we making it work?

lockPref is an exclusive feature of the autoconfig stuff right now. Autoconfig uses a single file, located in the application directory, and which name is given by the general.config.filename preference, with pseudo security featured by a general.config.obscure_value preference.

Autoconfig also allows to use javascript constructs, contrary to standard pref files that are limited to pref() and user_pref().

The problem we had in debian is that we need to lock some preferences, to avoid users to harm themselves with bad preferences. app.update.enable, for instance. The first solution was to use the general.config.filename/obscure_value pair to just do that. The problem is that this file being provided by the package, it is also overwritten on any package upgrade, which means admins needing to use autoconfig just can't.

I found it a convenient way to solve this by allowing standard preferences to lock preferences.

I'm pretty sure you can find some other uses to this feature.

> * I'm going to need tests. I think writing an xpcshell test for this shouldn't
> be too hard.

Can you still review the patch without the tests ? 
Attachment #326061 - Flags: review?(benjamin)
Frankly, to solve the specific case of Debian users trying to enable updates, I think the best course of action is to get rid of the app.update.url pref from the Debian builds: then even if the user were to turn updates on, nothing bad could happen.

I'm trying to find somebody to help walk through the twisted jungle here; this is not likely to make it for FF3.1 because it touches something close to PAC, which is some of our most fragile code.
This has nothing to do with app.update.url, but with admins wanting to lock some prefs to their users without fidling with general.config.filename.
Which may be a worthwhile use case, but I'm pretty sure we don't want extensions to be able to lock preferences (for example), and it's not clear to me that we distinguish between admins and extensions very well.
Actually, AFAIK, an extension can already lock preferences...
Comment on attachment 326061 [details] [diff] [review]
patch

At least extensions should not be allowed to set locked prefs, so r-. I'm not sure what the right design is.
Attachment #326061 - Flags: review?(benjamin) → review-
As I said, extensions can already lock preferences...
Comment on attachment 326061 [details] [diff] [review]
patch

Re-requesting review due to glandium's overlooked comment.
Attachment #326061 - Flags: review- → review?(benjamin)
How can an extension lock preferences?
Posted file extension locking a pref (obsolete) —
This is one way i was thinking of for an extension to lock a preference. There are, I guess, many others.
Duplicate of this bug: 467738
Comment on attachment 326061 [details] [diff] [review]
patch

ok, yes, extensions can do anything. I don't think we want them doing this, and this will be an attractive nuisance.
Attachment #326061 - Flags: review?(benjamin) → review-
QA Contact: preferences → preferences-backend
The point is, extensions already can lock prefs, so why not allow this patch, which doesn't change that, and file another bug to prevent extensions from locking prefs ?
Comment on attachment 326061 [details] [diff] [review]
patch

Re-requesting review per comment #16
Attachment #326061 - Flags: review- → review?(benjamin)
Comment on attachment 326061 [details] [diff] [review]
patch

I cannot review this without spending boatloads of time understanding the use cases and code, which I don't think is worth my time at this point. Sorry :-(
Attachment #326061 - Flags: review?(benjamin)
Just voted for this bug. We are locking certain prefs in the default installation (for example browser and extension updates are done via packages, so we diable eg "app.update.enabled").

Debian is shipping a patch in their packages, Ubuntu isn't (see https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/623844).
Refreshed after the PRBool/bool change.

Now, as bsmedberg won't review it, and dwitte is essentially not around anymore, who can review this?
Sorry for the noise, just testing "hg bzexport". I'm still interested to know who could review this, though.
Attachment #572068 - Attachment is obsolete: true
This is a fly by night review.

I don't think it should be "lockPref" like autoconfig. With autoconfig, it's a function call.

With the default pref files, you're specifying a preference.

so:

locked_pref("foo", "bar")

makes more sense it that context (the same as user_pref)

Looking through the code, it looks like you've assumed that if a pref is locked, it becomes a default as well, is that correct?

The code looks good to me, but I'm not the right person to do this.

I think this is a good solution to the problem you are seeing and makes it a lot easier for enterprises to lock prefs, so this would be a good thing to have.
Duplicate of this bug: 788481
(In reply to Benjamin Smedberg  [:bsmedberg] (Away 24-25 October) from comment #18)
> Comment on attachment 326061 [details] [diff] [review]
> patch
> 
> I cannot review this without spending boatloads of time understanding the
> use cases and code, which I don't think is worth my time at this point.
> Sorry :-(

In that case, can you suggest someone that could review it?
Flags: needinfo?(benjamin)
No, at this point I don't think there is anyone who can own and review this.
Flags: needinfo?(benjamin)
seems like there is some interest in this bug over in 

	https://bugzilla.mozilla.org/show_bug.cgi?id=984012#c15
	https://bugzilla.mozilla.org/show_bug.cgi?id=984012#c17

to help protect international users from getting phished into changing the pref named security.turn_off_all_security_so_that_viruses_can_take_over_this_computer

and not necessarily understanding the ramifications of that action if they don't understand English.
See Also: → 984012
Refreshed after bug 1098343. Benjamin, would you like to review this, this time, considering comment 26?
Attachment #576542 - Attachment is obsolete: true
Attachment #8613433 - Flags: review?(benjamin)
You didn't address my comments.

I really don't want it being called lockPref. That will confuse it with the autoconfig "lockPref" function.

There is already enough confusion with pref()
(In reply to Mike Kaply [:mkaply] from comment #28)
> I really don't want it being called lockPref. That will confuse it with the
> autoconfig "lockPref" function.

What is confusing? It's the same syntax. The only difference aiui, is the execution environment, which means autoconf can do more javascript-y things, which, as you point out, is already a source of confusion. I'd argue that having two different names is what would be confusing.
It's not the same syntax, that's my point.

pref() in a prefs.js file is NOT the same as pref() in an AutoConfig.js file.

pref() in prefs.js sets the default pref, defaultPref() in an Autoconfig sets a default pref.

user_pref() in prefs.js sets a user pref, pref() in an AutoConfig file sets a user preference.

So what you're doing is making it look like autoconfig.js and prefs.js use the same syntax, when they do not.
(In reply to Mike Kaply [:mkaply] from comment #30)
> It's not the same syntax, that's my point.

I tend to agree here.  I think this could be a useful patch (I'd use it instead of doing autoconfig stuff) but it's kind of silly to be hung up on naming...

I do think that "lockPref" sticks out relative to the calls for "default_pref", and "sticky_pref".  I'm a +1 for calling it "locked_pref".
The syntax is a triviality of the patch. The core problem here is that there's no one to review the patch so that it possibly lands.
:(

Ideally, I'd like to favor this patch over the one I proposed at https://bugzilla.mozilla.org/show_bug.cgi?id=976334 - since it has been tried and tested for so long...and that just adds another use case for this: ease of locking preferences for android distributions (which aren't as straightforward when it comes to specifying the autoconfig file in the install directory)

Is it just a matter of having someone sign off on it, or were there outstanding concerns outside of the syntax?  It seemed like it kind of just got dropped due to time constraints 2+ years ago, but that there now are actually some compelling use cases for it. 

Can't the fact that it's been needed and used by Debian for so long be an indication of the stability and/or utility of the patch?  just an appeal to *someone* to perhaps move this along...

Aside from that, :glandium - how often does this patch "break"...that is, how many times have you had to rework it because of changes in the upstream code?  I ask because I actually would consider applying this patch and using it in my own distribution - even if it never lands.
From a quick glance at the history of the patch in Debian, in the past 5 years, I had to do actual but trivial code changes twice, and adapt to context changes twice (one of them having been the change from PRBool to bool)
(In reply to Mike Hommey [:glandium] (VAC: 31 Dec - 11 Jan) from comment #32)
> The syntax is a triviality of the patch. The core problem here is that
> there's no one to review the patch so that it possibly lands.

Can I help review?
Comment on attachment 8613433 [details] [diff] [review]
Allow .js preference files to set locked prefs with lockPref()

Because this came up on the mailing list, I'll try to be explicit about the decision here. I don't think we should allow extensions to lock preferences, and we don't even have a clear description (other than this code) of what it means to "lock" a preference: whether changes to the default value are still allowed, or the user value, etc.

The code is the incidental part of this; it's the basic problem and solution space that's totally unclear.
Attachment #8613433 - Flags: review?(benjamin) → review-
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #36)
> Because this came up on the mailing list

Which mailing list is that? (just so I can make sure I'm following the right one)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #36)
> Comment on attachment 8613433 [details] [diff] [review]
> Allow .js preference files to set locked prefs with lockPref()
> 
> Because this came up on the mailing list, I'll try to be explicit about the
> decision here. I don't think we should allow extensions to lock preferences,

As mentioned in the long history of this bug, extensions can already lock preferences. See the attached xpi.
To expound on what :glandium said:

Extensions can lock preferences with:

  Components.classes["@mozilla.org/preferences-service;1"]
            .getService(Components.interfaces.nsIPrefService)
            .getBranch(null)
            .lockPref("name_of_pref");

Locking a preference doesn't affect the value, it just locks the preference to the user. Obviously any extension could unlock a preference and do what they want with that value.

Locking preferences is not for the benefit of preventing other extensions from messing with things, it's to keep users from messing with things.

Oddly, this document:

https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/A_brief_guide_to_Mozilla_preferences

Says we already support lockPref in JS files?
(In reply to Mike Kaply [:mkaply] from comment #39)
> Oddly, this document:
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/
> A_brief_guide_to_Mozilla_preferences
> 
> Says we already support lockPref in JS files?

It says: "All preferences files may call pref(), user_pref() and sticky_pref(), while the config file in addition may call lockPref()."
which is about autoconf.
(In reply to Mike Hommey (VAC: 31 Dec - 11 Jan) [:glandium] from comment #40)
> (In reply to Mike Kaply [:mkaply] from comment #39)
> > Oddly, this document:
> > 
> > https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/
> > A_brief_guide_to_Mozilla_preferences
> > 
> > Says we already support lockPref in JS files?
> 
> It says: "All preferences files may call pref(), user_pref() and
> sticky_pref(), while the config file in addition may call lockPref()."
> which is about autoconf.

You'd think I would have noticed that. I really don't like a document that combines the two. pref behaves differently on both, user_pref doesn't work in autoconfig and sticky_pref doesn't work in autoconfig. This shouldn't reference autoconfig at all.
Comment on attachment 8613433 [details] [diff] [review]
Allow .js preference files to set locked prefs with lockPref()

>From b8015e0754742650a4877de9ebe7d6db2671970d Mon Sep 17 00:00:00 2001
>From: Mike Hommey <glandium@debian.org>
>Date: Sat, 21 Jun 2008 02:48:46 +0200
>Subject: [PATCH] Allow .js preference files to set locked prefs with
> lockPref()
>
>---
> modules/libpref/prefapi.cpp  |  5 ++++-
> modules/libpref/prefapi.h    |  3 ++-
> modules/libpref/prefread.cpp | 12 +++++++++---
> modules/libpref/prefread.h   |  4 +++-
> 4 files changed, 18 insertions(+), 6 deletions(-)
>
>diff --git a/modules/libpref/prefapi.cpp b/modules/libpref/prefapi.cpp
>index e898433..081c922 100644
>--- a/modules/libpref/prefapi.cpp
>+++ b/modules/libpref/prefapi.cpp
>@@ -1002,16 +1002,19 @@ static nsresult pref_DoCallback(const char* changed_pref)
>     return rv;
> }
> 
> void PREF_ReaderCallback(void       *closure,
>                          const char *pref,
>                          PrefValue   value,
>                          PrefType    type,
>                          bool        isDefault,
>-                         bool        isStickyDefault)
>+                         bool        isStickyDefault,
>+                         bool        isLocked)
> {
>     uint32_t flags = isDefault ? kPrefSetDefault : kPrefForceSet;
>     if (isDefault && isStickyDefault) {
>         flags |= kPrefStickyDefault;
>     }
>     pref_HashPref(pref, value, type, flags);
>+    if (isLocked)
>+        PREF_LockPref(pref, true);
> }
>diff --git a/modules/libpref/prefapi.h b/modules/libpref/prefapi.h
>index f1e412a..24618a7 100644
>--- a/modules/libpref/prefapi.h
>+++ b/modules/libpref/prefapi.h
>@@ -181,14 +181,15 @@ nsresult PREF_UnregisterCallback( const char* domain,
> /*
>  * Used by nsPrefService as the callback function of the 'pref' parser
>  */
> void PREF_ReaderCallback( void *closure,
>                           const char *pref,
>                           PrefValue   value,
>                           PrefType    type,
>                           bool        isDefault,
>-                          bool        isStickyDefault);
>+                          bool        isStickyDefault,
>+                          bool        isLocked);
> 
> #ifdef __cplusplus
> }
> #endif
> #endif
>diff --git a/modules/libpref/prefread.cpp b/modules/libpref/prefread.cpp
>index 6c4d339..16c5057 100644
>--- a/modules/libpref/prefread.cpp
>+++ b/modules/libpref/prefread.cpp
>@@ -38,16 +38,17 @@ enum {
>     PREF_PARSE_UNTIL_EOL
> };
> 
> #define UTF16_ESC_NUM_DIGITS    4
> #define HEX_ESC_NUM_DIGITS      2
> #define BITS_PER_HEX_DIGIT      4
> 
> static const char kUserPref[] = "user_pref";
>+static const char kLockPref[] = "lockPref";
> static const char kPref[] = "pref";
> static const char kPrefSticky[] = "sticky_pref";
> static const char kTrue[] = "true";
> static const char kFalse[] = "false";
> 
> /**
>  * pref_GrowBuf
>  * 
>@@ -126,17 +127,17 @@ pref_DoCallback(PrefParseState *ps)
>         break;
>     case PREF_BOOL:
>         value.boolVal = (ps->vb == kTrue);
>         break;
>     default:
>         break;
>     }
>     (*ps->reader)(ps->closure, ps->lb, value, ps->vtype, ps->fdefault,
>-                  ps->fstickydefault);
>+                  ps->fstickydefault, ps->flock);
>     return true;
> }
> 
> void
> PREF_InitParseState(PrefParseState *ps, PrefReader reader, void *closure)
> {
>     memset(ps, 0, sizeof(*ps));
>     ps->reader = reader;
>@@ -186,29 +187,32 @@ PREF_ParseBuf(PrefParseState *ps, const char *buf, int bufLen)
>         /* initial state */
>         case PREF_PARSE_INIT:
>             if (ps->lbcur != ps->lb) { /* reset state */
>                 ps->lbcur = ps->lb;
>                 ps->vb    = nullptr;
>                 ps->vtype = PREF_INVALID;
>                 ps->fdefault = false;
>                 ps->fstickydefault = false;
>+                ps->flock = false;
>             }
>             switch (c) {
>             case '/':       /* begin comment block or line? */
>                 state = PREF_PARSE_COMMENT_MAYBE_START;
>                 break;
>             case '#':       /* accept shell style comments */
>                 state = PREF_PARSE_UNTIL_EOL;
>                 break;
>             case 'u':       /* indicating user_pref */
>             case 'p':       /* indicating pref */
>             case 's':       /* indicating sticky_pref */
>+            case 'l':       /* indicating lockPref */
>                 ps->smatch = (c == 'u' ? kUserPref :
>-                             (c == 's' ? kPrefSticky : kPref));
>+                             (c == 's' ? kPrefSticky :
>+                             (c == 'p' ? kPref : kLockPref)));
>                 ps->sindex = 1;
>                 ps->nextstate = PREF_PARSE_UNTIL_OPEN_PAREN;
>                 state = PREF_PARSE_MATCH_STRING;
>                 break;
>             /* else skip char */
>             }
>             break;
> 
>@@ -242,18 +246,20 @@ PREF_ParseBuf(PrefParseState *ps, const char *buf, int bufLen)
>             }
>             else
>                 *ps->lbcur++ = c;
>             break;
> 
>         /* name parsing */
>         case PREF_PARSE_UNTIL_NAME:
>             if (c == '\"' || c == '\'') {
>-                ps->fdefault = (ps->smatch == kPref || ps->smatch == kPrefSticky);
>+                ps->fdefault = (ps->smatch == kPref || ps->smatch == kPrefSticky
>+                                || ps->smatch == kLockPref);
>                 ps->fstickydefault = (ps->smatch == kPrefSticky);
>+                ps->flock = (ps->smatch == kLockPref);
>                 ps->quotechar = c;
>                 ps->nextstate = PREF_PARSE_UNTIL_COMMA; /* return here when done */
>                 state = PREF_PARSE_QUOTED_STRING;
>             }
>             else if (c == '/') {       /* allow embedded comment */
>                 ps->nextstate = state; /* return here when done with comment */
>                 state = PREF_PARSE_COMMENT_MAYBE_START;
>             }
>diff --git a/modules/libpref/prefread.h b/modules/libpref/prefread.h
>index 3c317ff..0c13057 100644
>--- a/modules/libpref/prefread.h
>+++ b/modules/libpref/prefread.h
>@@ -29,17 +29,18 @@ extern "C" {
>  * @param stickyPref
>  *        default preference marked as a "sticky" pref
>  */
> typedef void (*PrefReader)(void       *closure,
>                            const char *pref,
>                            PrefValue   val,
>                            PrefType    type,
>                            bool        defPref,
>-                           bool        stickyPref);
>+                           bool        stickyPref,
>+                           bool        lockPref);
> 
> /* structure fields are private */
> typedef struct PrefParseState {
>     PrefReader  reader;
>     void       *closure;
>     int         state;      /* PREF_PARSE_...                */
>     int         nextstate;  /* sometimes used...             */
>     const char *smatch;     /* string to match               */
>@@ -51,16 +52,17 @@ typedef struct PrefParseState {
>     char        quotechar;  /* char delimiter for quotations */
>     char       *lb;         /* line buffer (only allocation) */
>     char       *lbcur;      /* line buffer cursor            */
>     char       *lbend;      /* line buffer end               */
>     char       *vb;         /* value buffer (ptr into lb)    */
>     PrefType    vtype;      /* PREF_STRING,INT,BOOL          */
>     bool        fdefault;   /* true if (default) pref     */
>     bool        fstickydefault; /* true if (sticky) pref     */
>+    bool        flock;      /* true if pref to be locked     */
> } PrefParseState;
> 
> /**
>  * PREF_InitParseState
>  *
>  * Called to initialize a PrefParseState instance.
>  * 
>  * @param ps
>-- 
>2.4.0.2.g36460d1.dirty
>
Attachment #8613433 - Attachment is obsolete: true
Attachment #326061 - Attachment is obsolete: true
Attachment #347810 - Attachment is obsolete: true
Comment on attachment 8931547 [details]
Bug 440908 - Allow preference files to set locked prefs.

https://reviewboard.mozilla.org/r/202672/#review208008

As per our IRC discussion, I think this is a good feature, and the patch does a good job of implementing it. But before doing this I'd like to officially split the prefs file format in two -- one format for default prefs, and one for user prefs -- and then only support `locked_pref` in default prefs files. And I want to need to think about that for a bit, just to make sure it's a good idea.

::: modules/libpref/Preferences.cpp:238
(Diff revision 1)
>  enum
>  {
>    kPrefSetDefault = 1,
>    kPrefForceSet = 2,
>    kPrefSticky = 4,
> +  kPrefLocked = 8,

The patches in bug 1394578 are going to bitrot this again. Sorry :(

::: modules/libpref/Preferences.cpp:949
(Diff revision 1)
>    char* mLbEnd;           // line buffer end
>    char* mVb;              // value buffer (ptr into mLb)
>    Maybe<PrefType> mVtype; // pref value type
>    bool mIsDefault;        // true if (default) pref
>    bool mIsSticky;         // true if (sticky) pref
> +  bool mIsLocked;         // true if (locked) pref

It would be nice to replace these three bools with a single enum that has the following alternatives: Default, StickyDefault, LockedDefault, User. That would simplify some of the code below.

::: modules/libpref/test/unit/test_lockedprefs.js:20
(Diff revision 1)
> +}
> +
> +add_test(function notChangedFromAPI() {
> +  resetAndLoad(["data/testPrefLocked.js"]);
> +  Assert.strictEqual(ps.getBoolPref("testPref.unlocked.bool"), true);
> +  Assert.strictEqual(ps.getBoolPref("testPref.locked.bool"), false);

Keeping track of the true and false values here is tricky. If you changed it to an int you could make the "testPref.locked.int" use 100 and 101, and "testPref.unlocked.int" use 200 and 201, or something like that, and it would be a bit easier to read.

::: modules/libpref/test/unit/test_lockedprefs.js:24
(Diff revision 1)
> +  Assert.strictEqual(ps.getBoolPref("testPref.unlocked.bool"), true);
> +  Assert.strictEqual(ps.getBoolPref("testPref.locked.bool"), false);
> +
> +  ps.setBoolPref("testPref.unlocked.bool", false);
> +  Assert.ok(ps.prefHasUserValue("testPref.unlocked.bool"),
> +            "should be able to set an unlocked pref");

This string comment isn't quite right, because you can set a locked pref.

::: modules/libpref/test/unit/test_lockedprefs.js:29
(Diff revision 1)
> +            "should be able to set an unlocked pref");
> +  Assert.strictEqual(ps.getBoolPref("testPref.unlocked.bool"), false);
> +
> +  ps.setBoolPref("testPref.locked.bool", true);
> +  Assert.ok(ps.prefHasUserValue("testPref.locked.bool"),
> +            "somehow, the user value is still set");

This comment string is a bit weird too.
Attachment #8931547 - Flags: review?(n.nethercote)
This bug seems to be stalled 

Is there anything I may do to help get it advanced?
Flags: needinfo?(mh+mozilla)
The preferences code is being heavily refactored, and this needs to wait a bit for things to settle first. That being said, I do think the ideal timing for this would be to get it into 60. Nick, what do you think?
Flags: needinfo?(mh+mozilla) → needinfo?(n.nethercote)
Looking forward to see the patch landed as we use it at Fedora.
> Looking forward to see the patch landed as we use it at Fedora.

For what purpose? user.js shouldn't be used for anything mission critical at all.
@glandium

I see Comment #46 speaks of a FF 60 ESR release; but effort expended to a continuation '.js' amendments to configurations appears to conflict with the the '.json' configuration management direction outlined for 60 as well, at:

> https://wiki.mozilla.org/Firefox/EnterprisePolicies

Policies

The list of policies to support is still being defined, and is based on previous experience with what enterprises have asked in the past. Stay tuned for an official list of policies to be announced in the near term.

Some possibilities that are being discussed are:

    Disabling access to internal configuration features like about:config, about:addons, etc.
    Adding a set of bookmarks to the toolbar and the bookmarks menu
    Displaying the menu bar by default
    Disabling Telemetry
    Disabling features such as Pocket, Firefox Screenshots, Printing, Copy&Paste, etc.
    Whitelist and blocklist of domains to be allowed to be accessed
    Pre-populated permissions around cookies, storage, popups, plugins, etc.

-------

I wish a Statement of Roadmap were more clear -- I ran through the tracker bug on: EnterprisePolicies and it seems pretty far along
user.js was never intended to be an enterprise level feature for configuration of Firefox. I don't recommend using it for that.

For enterprise configuration, we have provided Autoconfig since day one, and we are working on a better solution involving JSON, GPO and possibly authors.

Our goal is to move away from the various hack solutions that folks have created in order to configure Firefox.

What specific customizations are you looking to do with Firefox? You can see the policies we are working on here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1428920
The ability to lock prefs at the .js level is not *only* for enterprise customization. Specifically, we have many "prefs" that are meant to allow e.g. per channel (release, beta, nightly) tweaks but are not meant for users to change. There are multiple such footguns that would be avoided by having firefox ship those as locked.
I was only referring to the use of user.js for enterprise. I do understand that it's worthwhile to have locking of prefs in JS file for Firefox purposes.
(In reply to Mike Hommey [:glandium] from comment #46)
> The preferences code is being heavily refactored, and this needs to wait a
> bit for things to settle first. That being said, I do think the ideal timing
> for this would be to get it into 60. Nick, what do you think?

If things go well with the prefs changes this might be possible in 60, it just depends how quickly the work goes.
Flags: needinfo?(n.nethercote)
Attachment #8931547 - Attachment is obsolete: true
Comment on attachment 8956309 [details]
Bug 440908 - Remove gIsAnyPrefLocked.

https://reviewboard.mozilla.org/r/225182/#review231210
Attachment #8956309 - Flags: review?(mh+mozilla) → review+
Comment on attachment 8956310 [details]
Bug 440908 - Add support for `sticky` and `locked` attributes to default prefs.

https://reviewboard.mozilla.org/r/225184/#review231212

::: modules/libpref/Preferences.cpp:3982
(Diff revision 1)
> -    Preferences::GetCString(kChannelPref, updateChannelPrefValue,
> -                            PrefValueKind::Default);
> +    Preferences::GetCString(
> +      kChannelPref, updateChannelPrefValue, PrefValueKind::Default);
>      releaseCandidateOnBeta = updateChannelPrefValue.EqualsLiteral("beta");
>    }
>  
>    if (!strcmp(NS_STRINGIFY(MOZ_UPDATE_CHANNEL), "nightly") ||
>        !strcmp(NS_STRINGIFY(MOZ_UPDATE_CHANNEL), "aurora") ||
> -      !strcmp(NS_STRINGIFY(MOZ_UPDATE_CHANNEL), "beta") ||
> +      !strcmp(NS_STRINGIFY(MOZ_UPDATE_CHANNEL), "beta") || developerBuild ||

clang-format changed its mind, I guess?

::: modules/libpref/parser/src/lib.rs:282
(Diff revision 1)
>  struct KeywordInfo {
>    string: &'static [u8],
>    token: Token,
>  }
>  
> -const KEYWORD_INFOS: &[KeywordInfo; 5] = &[
> +const KEYWORD_INFOS: &[KeywordInfo; 7] = &[

In passing, AFAIK, this could actually me [KeywordInfo; 7] (without the ref)
Attachment #8956310 - Flags: review?(mh+mozilla) → review+
Comment on attachment 8956311 [details]
Bug 440908 - Convert sticky prefs in default pref files to the new syntax.

https://reviewboard.mozilla.org/r/225186/#review231216
Attachment #8956311 - Flags: review?(mh+mozilla) → review+
> clang-format changed its mind, I guess?

No, chutten changed that code in bug 1435753. I generally run `./mach clang-format -p modules/libpref`. Perhaps I should just run `./mach clang-format` instead...
Assignee: mh+mozilla → n.nethercote
Depends on: 1562549
You need to log in before you can comment on or make changes to this bug.