blocklist.xml - at what point is the new file loaded?
Hi
Just to clarify:
-Is the blocklist.xml only loaded when Firefox is started up?
-If the blocklist.xml file changes whilst the browser is still open (i.e. there is an active session), the changes will only be realised upon closing and starting the browser again?
We are testing managing our own blocklist internally on six workstations.
thanks David
Toate răspunsurile (4)
hello david, the blocklist will be updated on a fixed interval once a day - the changes will be applied to the browser immediately during the running session. if you want to test the behaviour in more detail, you can press ctrl+shift+j in order to open the browser console & enter this into the bottom line:
Components.classes['@mozilla.org/extensions/blocklist;1'].getService(Components.interfaces.nsITimerCallback).notify(null);
this should trigger a manual update of the blocklist file (despite throwing an undefined-error message)...
Hi philipp
Thanks for the swift response. One of the users/workstations (RHEL6 with home dir on NFS) appears to have loaded our config fine (it knows to fetch the blocklist from an internal server) but unlike the rest it does not seem to be fetching it. The file date is Oct 2013.
The lock and .parentlock files go back to September 2013 and I don't think this user closes FF before leaving for the day. I've had a look at the logs on our web server (serving up the blocklist.xml) but can't see anything. Our config is set to fetch it once per day from this server.
The user has said he thinks that FF has crashed in this time, but I'm not convinved FF has ever been fully closed in this time. It sounds like it should of worked even with an ongoing browser session though.
For the other 5 users (I'm one) it seems to be working. It fetches the file from our server and is applied. The blocklist.xml is standard, we've not changed anything, we just want to be able to serve it internally and release it after going through the changes, so it does not affect ongoing experiments (this is what the workstations are used for), which often need JS and such to view cameras.
David
can you try to trigger the update on the affected machine manually once as described above, and see if this is updating the timestamp of the blocklist.xml file in the profile folder. if this doesn't work either, you could try to delete the blocklist file and repeat the process afterwards - maybe it has some form of write-protection...
There are extensions.blocklist.* prefs that define how blocklisting works.
The lock and .parentlock files are only updated when Firefox starts, but Firefox should still fetch a new blocklist.xml file according to extensions.blocklist.interval and the extensions.blocklist.itemURL prefs.
On Linux it is probably only blocking older Java versions that matters.