** Bug watch added: Mozilla Bugzilla #976334
https://bugzilla.mozilla.org/show_bug.cgi?id=976334
** Bug watch added: Mozilla Bugzilla #1428920
https://bugzilla.mozilla.org/show_bug.cgi?id=1428920
--
You received this bug notification because you are a member of Desktop
Packages, which is s
(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
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 Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.laun
Comment on attachment 8956309
Bug 440908 - Remove gIsAnyPrefLocked.
https://reviewboard.mozilla.org/r/225182/#review231210
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/541951
Title:
https://hg.mozilla.org/mozilla-central/rev/edb57fbc6bea
https://hg.mozilla.org/mozilla-central/rev/b82802657783
https://hg.mozilla.org/mozilla-central/rev/d1d9ef8f7c0e
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
htt
Comment on attachment 8613433
Allow .js preference files to set locked prefs with lockPref()
>From b8015e0754742650a4877de9ebe7d6db2671970d Mon Sep 17 00:00:00 2001
>From: Mike Hommey
>Date: Sat, 21 Jun 2008 02:48:46 +0200
>Subject: [PATCH] Allow .js preference files to set locked prefs with
> lo
Looking forward to see the patch landed as we use it at Fedora.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/541951
Title:
Firefox 3.6 does not honour lockPref
Status in Mozilla Fi
(In reply to Benjamin Smedberg [:bsmedberg] from comment #36)
> Comment on attachment 8613433
> 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
(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
Comment on attachment 8931547
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 s
Created attachment 8956310
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 nsI
Comment on attachment 8613433
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 th
(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?
--
You received this bug notification because you are a member
Created attachment 8956309
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 revi
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
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.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/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 Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad
Comment on attachment 8956311
Bug 440908 - Convert sticky prefs in default pref files to the new syntax.
https://reviewboard.mozilla.org/r/225186/#review231216
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bu
>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)
--
You received this bug notification because you are a member of Desktop
:(
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 straightfo
(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 java
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 use
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` attrib
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
Comment on attachment 8956310
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,
> -
@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
Polic
Created attachment 8956311
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/
--
You received this bug notification because you are a me
> 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...
--
You received this bug notification because you are a member of Desktop
Packages, which i
This bug seems to be stalled
Is there anything I may do to help get it advanced?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/541951
Title:
Firefox 3.6 does not honour lockPref
St
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?
--
You received this bug notification because you are a member of Desktop
Packages,
(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 supp
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 Desktop
Packages, which is subscribed to fi
(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)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to f
Created attachment 8931547
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/
--
You received this bug notification because you are a member of Desktop
Pa
(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 relat
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 affec
Created attachment 8613433
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?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscrib
** Bug watch removed: Mozilla Bugzilla #984012
https://bugzilla.mozilla.org/show_bug.cgi?id=984012
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/541951
Title:
Firefox 3.6 does not
** Changed in: firefox
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/541951
Title:
Firefox 3.6 does not honour lockPref
Status in Mozilla
** Bug watch added: Mozilla Bugzilla #984012
https://bugzilla.mozilla.org/show_bug.cgi?id=984012
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/541951
Title:
Firefox 3.6 does not h
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_securit
No, at this point I don't think there is anyone who can own and review
this.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/541951
Title:
Firefox 3.6 does not honour lockPref
Status
(In reply to Benjamin Smedberg [:bsmedberg] (Away 24-25 October) from comment
#18)
> Comment on attachment 326061
> 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 c
*** Bug 788481 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/541951
Title:
Firefox 3.6 does not honour lockPref
Status in The Mozilla
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
Created attachment 576542
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.
--
You received this bug notification because you are a member of Desktop
Packages, which is subsc
Created attachment 572068
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?
--
You received this bug notification because you are a member o
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/thund
48 matches
Mail list logo
