Adblock Plus and (a little) more

Adblock Plus 2.8.1 for Firefox released · 2016-10-28 14:37 by Wladimir Palant

Install Adblock Plus 2.8.1 for Firefox

Our Adblock Plus 2.8 release introduced a regression that went unnoticed for months in the development builds. Users who activated the please_kill_startup_performance preference were experiencing data loss: filters didn’t load completely. Also, importing custom filters was failing for large files. Both issues have the same root cause (issue 4576) and have been resolved in Adblock Plus 2.8.1. If your data is still incomplete after updating to Adblock Plus 2.8.1 please click the “Backup and Restore” button in Filter Preferences — one of the automatically created backups is certain to be correct.

Tags: adblock plus releases

Comment [10]

1. vastymedoisa · 2016-10-28 18:55 · #

   Hi, its normal that after upgradiung to 2.8 (and 2.8.1) I see a very small “Search” field?
   http://postimg.org/image/z9qgq9×0r/
   thanks.

   Reply from Wladimir Palant:

   It’s an issue with the Italian translation, it seems to be rather lengthy. I’ll somehow need to communicate to translators that these messages should be short…

2. vastymedoisa · 2016-10-28 18:59 · #

   here the link

3. Joe Pistachio · 2016-10-28 19:39 · #

   Is it normal that from version 2.8, Adblock Plus now blocks items on “chrome://” pages, with no way to whitelist such pages?

4. vastymedoisa · 2016-10-29 01:03 · #

   Hi, thanks for your reply. I guess that the italian word is short: “Trova” ;)

   Reply from Wladimir Palant:

   No, it’s about the messages that show up if the search is wrapped or the filter isn’t found.

5. Joe Pistachio · 2016-11-05 21:11 · #

   The same conflict for “chrome://” addresses goes for “moz-extension://” URLs.

   Example: moz-extension://f80c536d-04e6-4200-b205-3a32e0948ec3/redirector.html — from the Redirector add-on; when using the export feature, if you have for example filters like ##[href*=“ads”], you must manually exclude each one of them using the ID of the add-on: ~f80c536d-04e6-4200-b205-3a32e0948ec3##[href*=“ads”]

   Reply from Wladimir Palant:

   Actually, we don’t have an exception for moz-extension:// yet – we should add one. Element hiding affecting chrome:// pages on the other hand is unexpected.

6. Joe Pistachio · 2016-11-06 10:01 · #

   This doesn’t seem to affect chrome:// pages internal to Firefox (e.g. “chrome://browser/content/aboutDialog.xul”), but rather ones added by other add-ons.

   For example, it currently affects pages cached using the Update Scanner add-on (URLs are of the form “chrome://updatescan/”).
   This behavior didn’t occur prior to version 2.8.
   The “~updatescan” exclude rule works, but this has to be done for each affected filter, as I haven’t yet found a way to totally whitelist said pages.

   And for, I guess, the same reason as the “moz-extension://” issue (no exclusion rule), other pages from other add-ons are affected as well.
   Like the options page of the Redirect Control add-on (resource://redirectcontrol-at-hjgwmvya/data/options-page.html).

   Reply from Wladimir Palant:

   Thank you for the information, I will have a look.

   Reply from Wladimir Palant:

   There you go: https://issues.adblockplus.org/ticket/4624, https://issues.adblockplus.org/ticket/4625

7. Joe Pistachio · 2016-11-09 13:53 · #

   Thanks. :)

8. Christopher Denney · 2016-11-15 20:52 · #

   No longer works with version 37.0.1 of Firefox

   Reply from Wladimir Palant:

   It sure doesn’t, won’t even install there – Firefox 38 or higher is required.

9. Christopher Denney · 2016-11-15 21:09 · #

   Never mind, it appears my Firefox had some kind of spasm, it restarted with a “new” version (37.0.1) and has run several more updates, subsequently, finally settling on 50.0. all is good. :/

10. gregory · 2016-11-24 20:14 · #

    ghh

Commenting is closed for this article.