440908 - Allow .js preference files to set locked prefs

Status: RESOLVED FIXED

(Core :: Preferences: Backend, defect)

Description

[Mike Hommey [:glandium]]

Attachment: patch

The attached patch allows to use lockPref() in any .js preference file (prefs.js, files in default/preferences...)

Comment 1

[Mike Hommey [:glandium]]

Attachment: patch

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.

Comment 2

[Benjamin Smedberg]

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 3

[Benjamin Smedberg]

Comment on attachment 326061 [details] [diff] [review]
patch

canceling review request until questions are answered

Comment 4

[Mike Hommey [:glandium]]

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

Comment 5

[Benjamin Smedberg]

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.

Comment 6

[Mike Hommey [:glandium]]

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.

Comment 7

[Benjamin Smedberg]

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.

Comment 8

[Mike Hommey [:glandium]]

Actually, AFAIK, an extension can already lock preferences...

Comment 9

[Benjamin Smedberg]

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.

Comment 10

[Mike Hommey [:glandium]]

As I said, extensions can already lock preferences...

Comment 11

[Reed Loden [:reed]]

Comment on attachment 326061 [details] [diff] [review]
patch

Re-requesting review due to glandium's overlooked comment.

Comment 12

[Benjamin Smedberg]

How can an extension lock preferences?

Comment 13

[Mike Hommey [:glandium]]

Attachment: extension locking a pref

This is one way i was thinking of for an extension to lock a preference. There are, I guess, many others.

Comment 15

[Benjamin Smedberg]

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.

Comment 16

[Mike Hommey [:glandium]]

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 17

[Mike Hommey [:glandium]]

Comment on attachment 326061 [details] [diff] [review]
patch

Re-requesting review per comment #16

Comment 18

[Benjamin Smedberg]

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

Comment 19

[Florian Maier]

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

Comment 20

[Mike Hommey [:glandium]]

Attachment: Allow .js preference files to set locked prefs with lockPref()

Refreshed after the PRBool/bool change.

Now, as bsmedberg won't review it, and dwitte is essentially not around anymore, who can review this?

Comment 21

[Mike Hommey [:glandium]]

Attachment: Allow .js preference files to set locked prefs with lockPref()

Sorry for the noise, just testing "hg bzexport". I'm still interested to know who could review this, though.

Comment 22

[Mike Kaply [:mkaply]]

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.

Comment 24

[Magnus Melin [:mkmelin]]

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

Comment 25

[Benjamin Smedberg]

No, at this point I don't think there is anyone who can own and review this.

Comment 26

[chris hofmann]

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.

Comment 27

[Mike Hommey [:glandium]]

Attachment: Allow .js preference files to set locked prefs with lockPref()

Refreshed after bug 1098343. Benjamin, would you like to review this, this time, considering comment 26?

Comment 28

[Mike Kaply [:mkaply]]

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

Comment 29

[Mike Hommey [:glandium]]

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

Comment 30

[Mike Kaply [:mkaply]]

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.

Comment 31

[Nathan Toone [:toonetown]]

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

Comment 32

[Mike Hommey [:glandium]]

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.

Comment 33

[Nathan Toone [:toonetown]]

:(

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.

Comment 34

[Mike Hommey [:glandium]]

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)

Comment 35

[(no longer active)]

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

[Benjamin Smedberg]

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.

Comment 37

[Nathan Toone [:toonetown]]

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

Comment 38

[Mike Hommey [:glandium]]

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

Comment 39

[Mike Kaply [:mkaply]]

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?

Comment 40

[Mike Hommey [:glandium]]

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

Comment 41

[Mike Kaply [:mkaply]]

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

[Mike Hommey [:glandium]]

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 <[e-mail]>
>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
>

Comment 43

[Mike Hommey [:glandium]]

Attachment: Bug 440908 - Allow preference files to set locked prefs.

Review commit: https://reviewboard.mozilla.org/r/202672/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/202672/

Comment 44

[Nicholas Nethercote [inactive]]

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.

Comment 45

[R P Herrold]

This bug seems to be stalled 

Is there anything I may do to help get it advanced?

Comment 46

[Mike Hommey [:glandium]]

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?

Comment 47

[Martin Stránský [:stransky] (ni? me)]

Looking forward to see the patch landed as we use it at Fedora.

Comment 48

[Mike Kaply [:mkaply]]

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

Comment 49

[R P Herrold]

@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

Comment 50

[Mike Kaply [:mkaply]]

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

Comment 51

[Mike Hommey [:glandium]]

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.

Comment 52

[Mike Kaply [:mkaply]]

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.

Comment 53

[Nicholas Nethercote [inactive]]

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

Comment 54

[Nicholas Nethercote [inactive]]

Attachment: Bug 440908 - Remove gIsAnyPrefLocked.

It optimizes Preferences::IsLocked(), but that function is called fewer than
200 times while starting the browser and opening a range of tabs.

Review commit: https://reviewboard.mozilla.org/r/225182/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/225182/

Comment 55

[Nicholas Nethercote [inactive]]

Attachment: Bug 440908 - Add support for `sticky` and `locked` attributes to default prefs.

Sticky prefs are already specifiable with `sticky_pref`, but this is a more
general attribute mechanism. The ability to specify a locked pref in the data
file is new.

The patch also adds nsIPrefService.readDefaultPrefsFromFile, to match the
existing nsIPrefService.readUserPrefsFromFile method, and converts a number of
the existing tests to use it.

Review commit: https://reviewboard.mozilla.org/r/225184/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/225184/

Comment 56

[Nicholas Nethercote [inactive]]

Attachment: Bug 440908 - Convert sticky prefs in default pref files to the new syntax.

Review commit: https://reviewboard.mozilla.org/r/225186/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/225186/

Comment 57

[Mike Hommey [:glandium]]

Comment on attachment 8956309 [details]
Bug 440908 - Remove gIsAnyPrefLocked.

https://reviewboard.mozilla.org/r/225182/#review231210

Comment 58

[Mike Hommey [:glandium]]

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)

Comment 59

[Mike Hommey [:glandium]]

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

Comment 60

[Nicholas Nethercote [inactive]]

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

Comment 61

[Nicholas Nethercote [inactive]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/edb57fbc6beac233b12486fa7d7381220339de0f
Bug 440908 - Remove gIsAnyPrefLocked. r=glandium

https://hg.mozilla.org/integration/mozilla-inbound/rev/b82802657783b6188e320ba966183ae1eedabf62
Bug 440908 - Add support for `sticky` and `locked` attributes to default prefs. r=glandium

https://hg.mozilla.org/integration/mozilla-inbound/rev/d1d9ef8f7c0ecdc6b9d8fa33b8b2a9238e0ad64f
Bug 440908 - Convert sticky prefs in default pref files to the new syntax. r=glandium

Comment 62

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/edb57fbc6bea
https://hg.mozilla.org/mozilla-central/rev/b82802657783
https://hg.mozilla.org/mozilla-central/rev/d1d9ef8f7c0e