[Bug 541951]

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,

[Bug 623844]

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,

[Bug 221265]

There are three additional preferences that when set and locked disable those buttons. It's not tied to the locking of the homepage: http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/main.xul#76 pref.browser.homepage.disable_button.current_page

[Bug 541951]

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() -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 541951]

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

[Bug 541951]

> 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 541951]

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

[Bug 541951]

(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

[Bug 541951]

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

[Bug 541951]

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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 623844]

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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 623844]

> 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 623844]

(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

[Bug 623844]

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

[Bug 623844]

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() -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 623844]

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

[Bug 623844]

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

[Bug 1854363]

This broke LDAP autoconfig. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1854363 Title: [upstream] ReferenceError: processLDAPValues is not defined To manage notifications about this bug go to:

[Bug 47751]

This doesn't happen with our new Marquee implementation. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/47751 Title: Dos problem with marquee tag To manage notifications about this bug go

[Bug 1877038]

This is also affecting Amazon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1877038 Title: [upstream] Firefox lacks FIDO2 support with Yubikeys To manage notifications about this bug go to: