Closed
Bug 1466849
Opened 6 years ago
Closed 6 years ago
defaultPref not working in autoconfig
Categories
(Core :: Preferences: Backend, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: firefox, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20180322140748
Steps to reproduce:
I was just testing the new ESR 60 and was setting some autoconfig values (like https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig ).
Every pref worked, so I've set the pref level, for example to lockPref and defaultPref.
Actual results:
While lockPref and pref worked fine, defaultPref was not. To be precise: nothing happened. Whether the changes where applied, nor did something happen in about:config.
Expected results:
Usually, the standard gets overwritten with this, but is still changeable.
I've tested this also with the latest Nightly, which still has the problem. Besides, I've tested FF 57, where it still works. And no, I don't use a distribution.ini.
So the error exist since somewhere between FF 57 an 60.0.
It would be good if this would be fixed in the 60.x ESR, because this potentially destroys parts of the configuration in companies (and I don't want to change the config of my company in order to roll out FF 60 ESR ;P ).
Comment 1•6 years ago
|
||
(In reply to Confix from comment #0)
> While lockPref and pref worked fine, defaultPref was not.
What is the exact line that had no effect?
Component: Untriaged → Preferences: Backend
Product: Firefox → Core
(In reply to Gingerbread Man from comment #1)
> What is the exact line that had no effect?
Well, a .cfg file looks like this:
> // Show Tabname in window
> defaultPref("browser.tabs.drawInTitlebar", false);
> // Deactivate password safe
> defaultPref("signon.rememberSignons", false);
> // deaktivate experiments
> lockPref("experiments.enabled", false);
> // Show Download button
> pref("browser.download.autohideButton", false);
Everything with defaultPref() isn't working anymore, while it works fine with lockPref() and pref().
Comment 3•6 years ago
|
||
(In reply to Confix from comment #0)
> I've tested FF 57, where it still works.
(In reply to Confix from comment #2)
> > // Show Tabname in window
> > defaultPref("browser.tabs.drawInTitlebar", false);
> > // Deactivate password safe
> > defaultPref("signon.rememberSignons", false);
I can't get this to work in Firefox 57. It does however work in Firefox 52.8.0esr. I don't know how to go about regression testing something that requires files to be copied into the installation folder.
Mike, you confirmed bug 786875. Maybe you can have a look at this one as well.
Flags: needinfo?(mozilla)
Comment 4•6 years ago
|
||
Do you have a distribution.ini file by chance? (In the distribution directory)
Flags: needinfo?(mozilla)
(In reply to Mike Kaply [:mkaply] from comment #4)
> Do you have a distribution.ini file by chance? (In the distribution
> directory)
Nope, I don't.
Comment 6•6 years ago
|
||
I just tested with your config file snippet on ESR and the defaultPrefs work for me.
I assume these are just a part of your cfg file?
My guess is that there is an error with one of the earlier preferences and part of the file isn't getting read?
Did you try with just a single defaultPref?
Weird. Yes, they are part of my .cfg file.
I also thought the same like you, but other (not default) prefs at the bottom of the file are working, but neither the defaultPrefs at the top nor the ones at the bottom are working. I have around 20 defaultPrefs in my .cfg.
However, I can't guarantee that there are no errors in the defaultPrefs. However, this error did also occour as I was only using the following lines in the cfg:
defaultPref("browser.newtabpage.activity-stream.section.highlights.includePocket", false);
pref("browser.newtabpage.activity-stream.feeds.section.topstories", false);
Comment 8•6 years ago
|
||
The activity stream pref is not working because they are explicitly setting their own preference as default which overrides what you set in Autoconfig.
You would need to lock that pref or use a user value.
Are you only seeing this problem with activity stream prefs?
(In reply to Mike Kaply [:mkaply] from comment #8)
Okay, this explains something. Testing with a small file with a few other defaultPrefs works like it should, while putting my standard (big) file leads to the described problem. So there probably is an error somewhere in my cfg. I will check the whole file for the root of the problem.
Thank you for your help!
Reporter | ||
Comment 10•6 years ago
|
||
Okay, I've found my problem. Besides the point Mike explained above with the not working pref with the activity stream, I've found the part of my .cfg whithout the defaultPref works.
It's code which brings back the default profile functionality that we're using and is pretty usefull, as we're importing some stuff to the users profile.
The code is available here: https://mike.kaply.com/2016/05/24/default-profile-directory-doesnt-work-in-firefox-46/
@Mike: I'm sorry to bother you there, but do you have an idea whether this is a problem which should/could be fixed in the AutoConfig file or in Firefox?
Flags: needinfo?(mozilla)
Comment 11•6 years ago
|
||
I'm curious what files you still need to put in the default profile?
I'm wondering about policies for these things (or a default profile policy).
I'll look into why that snippet of code doesn't work, but it will definitely be ESR only starting with Firefox 62.
Flags: needinfo?(mozilla)
Reporter | ||
Comment 12•6 years ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #11)
> I'm curious what files you still need to put in the default profile?
>
> I'm wondering about policies for these things (or a default profile policy).
We have some certificates in a cert8.db, as we ran into some issues with some internal certificates for https.
> I'll look into why that snippet of code doesn't work, but it will definitely
> be ESR only starting with Firefox 62.
I'm sorry, how do you mean that? Is something for that implemented into ESR (or in ESRs above 62)?
Comment 13•6 years ago
|
||
> We have some certificates in a cert8.db, as we ran into some issues with some internal certificates for https.
Are you running Windows? If so, are you aware of the preference to use added Windows certs?
I'm also going to add cert installation support to the policy manager.
> I'm sorry, how do you mean that? Is something for that implemented into ESR (or in ESRs above 62)?
I mean that starting with Firefox 62 rapid release, you won't be able to do anything like this in AutoConfig anymore. You will only be able to do it in the ESR. See bug 1455601.
Reporter | ||
Comment 14•6 years ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #13)
> Are you running Windows? If so, are you aware of the preference to use added
> Windows certs?
Yes, I am aware. I weren't responsible for software distribution at time this was done, but I remember something wasn't working correctly after we distributed the affected certs with Windows certs. However, we should check if this still is needed.
Before, we also distributed things like the userChrome.css to hide things like sync buttons, which is something we won't need anymore with the new policy engine. <3
> I'm also going to add cert installation support to the policy manager.
That's great to hear, thank you!
> I mean that starting with Firefox 62 rapid release, you won't be able to do
> anything like this in AutoConfig anymore. You will only be able to do it in
> the ESR. See bug 1455601.
Okay, thanks for the explonation! :)
Reporter | ||
Comment 15•6 years ago
|
||
I think this bug can be closed. The bug I reported doesn't exist and the mentioned problem is very specific and not relevant.
Thank you all for helping me <3 and sorry that I took your time because of insufficient testing of me. /o\
Comment 16•6 years ago
|
||
I just ran a quick check and my copy profile code is working for me (although cert8.db needs to be changed to cert9.db for Firefox 60).
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 17•6 years ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #16)
> I just ran a quick check and my copy profile code is working for me
Well, the code does what it should do. However, if I use it in my firefox.cfg for Firefox 60 ESR, the defaultPrefs inside the firefox.cfg aren't working anymore.
> (although cert8.db needs to be changed to cert9.db for Firefox 60).
Oh, thanks for hint!
Comment 18•6 years ago
|
||
> Well, the code does what it should do. However, if I use it in my firefox.cfg for Firefox 60 ESR, the defaultPrefs inside the firefox.cfg aren't working anymore.
Can you give me your fill firefox.cfg so I can test? I can't recreate piecemeal.
Email to mkaply at mozilla DOT com
If not, I understand.
Comment 19•6 years ago
|
||
So I have no explanation for this, but I at least know how to workaround it.
The line:
const {classes: Cc, interfaces: Ci, utils: Cu} = Components;
MUST be at the the beginning of the file (before the calls to defaultPref).
Everything else can be after.
If you change it to a let or var, it works fine, but as a const, it must be before the defaultPref lines.
I'm going to needinfo kmaglione just because I'm curious what's going on here, but I'm not sure it's worth fixing.
It might have something to do with strict mode?
Kris:
Is there some requirement that const must be before other code?
Flags: needinfo?(kmaglione+bmo)
Comment 20•6 years ago
|
||
It's a temporal dead zone issue. If the two scripts get loaded into the same scope, the `const` declaration creates a lexical binding for Cc and friends that can't be accessed until the `const` line is executed.
In any case, that line is completely unnecessary. Those bindings are created by default.
Flags: needinfo?(kmaglione+bmo)
You need to log in
before you can comment on or make changes to this bug.
Description
•