Sykje yn Support

Mij stipescams. Wy sille jo nea freegje in telefoannûmer te beljen, der in sms nei ta te stjoeren of persoanlike gegevens te dielen. Meld fertochte aktiviteit mei de opsje ‘Misbrûk melde’.

Mear ynfo

Dizze konversaasje is argivearre. Stel in nije fraach as jo help nedich hawwe.

blocklist.xml - at what point is the new file loaded?

  • 4 antwurd
  • 1 hat dit probleem
  • 43 werjeftes
  • Lêste antwurd fan cor-el

more options

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

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

Alle antwurden (4)

more options

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)...

more options

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

more options

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...

more options

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.