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 to
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:
ht
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
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 Ubuntu.
> 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.
https://bugs.launchpad.net/bugs/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 supp
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.
https://bugs.launchpad.net/bugs/6
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
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
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 Ubuntu.
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
> 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.
https://bugs.launchpad.net/bugs/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 affec
(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
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
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.
https://bugs.launchpad.net/bugs/5
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
pref.browser.homepage.di
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
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
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:
https:
20 matches
Mail list logo