interesting observation:
it did some grep in the profile directory and found that user.js might be the source that extensions.blocklist.enabled automatically changes its value to true after each browser restart.
Therefor I set user.js->user_pref("extensions.blocklist.enabled", false);. Since then I did 2 restarts and each time extensions.blocklist.enabled has the correct value which is false.
I'm now lurking if something changes, and if so, Ill notice you 4 sure.
Basilisk updated Topic is solved
Moderator: Basilisk-Dev
Re: Basilisk updated
That is the design of user.js -- unless you want to have specific preferences always set to certain values, you should not be using user.js because that is exactly what it does.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: Basilisk updated
I never edited user.js before. Therefor basil must have set all variables of it to the default values, overriding the values set manually by about:config each restart.
Anyhow. I removed all the urls of user.js as well as about:config, including all the telemetry urls. Up to now it appears to be stable. No blocklist troubles anymore.
Finally I wrote some cronjob checking extensions.blocklist.enabled for the true value each hour, sending a email to me, and automatically set blocklist.enabled back to false by the good ole sed.
Anyhow. I removed all the urls of user.js as well as about:config, including all the telemetry urls. Up to now it appears to be stable. No blocklist troubles anymore.
Finally I wrote some cronjob checking extensions.blocklist.enabled for the true value each hour, sending a email to me, and automatically set blocklist.enabled back to false by the good ole sed.
Last edited by dodona on 2018-01-01, 21:39, edited 1 time in total.
-
- Moon Magic practitioner
- Posts: 2986
- Joined: 2015-09-26, 04:51
- Location: U.S.
Re: Basilisk updated
dodona wrote:I never edited user.js before.
The user.js doesn't exist by default (except in the portable version of PM, which to my knowledge is Windows-only) - It *should* only exist if the user creates it.
Re: Basilisk updated
now after 36 hours of stable running incl. several restarts for me the case is closed. After eliminating the user.js problem everything is fine beside the reader problem.
Thanks for the support!
Thanks for the support!
Re: Basilisk updated
plain theories doesn't help.coffeebreak wrote:dodona wrote:I never edited user.js before.
The user.js doesn't exist by default (except in the portable version of PM, which to my knowledge is Windows-only) - It *should* only exist if the user creates it.
I have no idea where the user.js came, and especially, why it had all the disturbing blocklist related settings.
Anyway its gone and basil works fine.
Re: Basilisk updated
I hate to say it, but I still have problems with add-ons blocking on Linux (Basilisk build 20180105015013, clean profile, default settings). Unfortunately the corresponding ticket on GitHub was closed as resolved and locked, so I forced to report it here.
And, as I already wrote, this is not about warnings and most likely not about blocklist itself (regardless of the error messages). It seems there is something fundamentally wrong with Basilisk on Linux (see also the problem with Devtools).
And, as I already wrote, this is not about warnings and most likely not about blocklist itself (regardless of the error messages). It seems there is something fundamentally wrong with Basilisk on Linux (see also the problem with Devtools).