Opened on 11/08/2017 at 10:47:24 PM

Closed on 11/10/2017 at 10:08:11 AM

Last modified on 11/29/2017 at 01:35:52 PM

#6010 closed defect (fixed)

Filter list blocked by ABP 3

Reported by: mapx Assignee: trev
Priority: P2 Milestone: Adblock-Plus-3.0.2-for-Firefox
Module: Platform Keywords:
Cc: trev, sebastian, mjethani, kzar Blocked By:
Blocking: Platform: Firefox
Ready: yes Confidential: no
Tester: Ross Verified working: yes
Review URL(s):

Description (last modified by trev)


FF 57

How to reproduce

  • add this filter _bg
  • go to
  • click subscribe bulgarian list (having this address )

Observed behaviour

  • in the filter lists section I get Failed, download failure

Expected behaviour

The list should be correctly downloaded / added to ABP (as in ABP legacy)

Reported here:

What to change

webRequest in Firefox will give us an originUrl property that allows recognizing internal requests. We should ignore anything where originUrl starts with chrome:// or moz-extension://. No such property on Chrome, recognizing internal requests doesn't seem possible there.

Attachments (0)

Change History (11)

comment:1 Changed on 11/08/2017 at 10:47:48 PM by mapx

  • Description modified (diff)

comment:2 Changed on 11/09/2017 at 09:21:12 AM by trev

  • Cc greiner removed
  • Component changed from Adblock-Plus-for-Firefox to Platform

I can confirm that filter list downloads are subject to our filter rules both in Firefox and Chrome. I guess that this is a side-effect of #5042.

comment:3 Changed on 11/09/2017 at 10:39:47 AM by kzar

  • Priority changed from Unknown to P2
  • Ready set

comment:4 Changed on 11/09/2017 at 04:13:32 PM by trev

  • Description modified (diff)
  • Owner set to trev

comment:5 Changed on 11/09/2017 at 04:17:44 PM by trev

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

comment:6 Changed on 11/10/2017 at 10:07:38 AM by abpbot

comment:7 Changed on 11/10/2017 at 10:08:11 AM by trev

  • Milestone set to Adblock-Plus-for-Chrome-Opera-Firefox-next
  • Platform changed from Unknown / Cross platform to Firefox
  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:8 Changed on 11/10/2017 at 06:39:58 PM by mapx

The webRequest API only exposes requests that the extension has permission to see,
given its host permissions. Moreover, only the following schemes are accessible: 
http://, https://, ftp://, file://, ws:// (since Chrome 58), wss:// (since Chrome 58),
or chrome-extension://


Is it possible (for chrome) to use chrome-extension:// to identify the origin of the request ?

comment:9 Changed on 11/10/2017 at 06:44:54 PM by trev

Chrome doesn't expose the origin of the request. In other words: no, not possible.

comment:10 Changed on 11/23/2017 at 02:13:55 PM by Ross

Fixed. Haven't checked fix in Firefox 50 due to #5971.

Firefox 57 / Windows 10

comment:11 Changed on 11/29/2017 at 01:35:52 PM by Ross

  • Tester changed from Unknown to Ross
  • Verified working set

Fixed in Firefox. Re-tested with _ar list as several of the easylist files seem to have been renamed (ex: "bulgarian_list").

Still blocks request in Chrome/Opera, but as I understand from the above that is currently expected behaviour.

Firefox 51 / 57 / Windows 7
Chrome 49 / 62 / Windows 7
Opera 36 / 48 / Windows 7

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from trev.
Note: See TracTickets for help on using tickets.