Opened on 05/11/2015 at 04:12:23 PM

Closed on 05/19/2015 at 04:22:02 PM

Last modified on 06/04/2015 at 09:12:36 PM

#2503 closed defect (fixed)

Inconsistent behavior: $document flag implied for exception rules with protocol included

Reported by: passbrains Assignee: trev
Priority: P2 Milestone: Adblock-Plus-2.6.10-for-Firefox
Module: Core Keywords:
Cc: trev, sebastian Blocked By:
Blocking: Platform: Chrome
Ready: yes Confidential: no
Tester: Verified working: no
Review URL(s):

Description (last modified by trev)

Adapted from


Windows + 8.1 64bit + maxthon + English

How to reproduce

  1. open the browser and go to a website such as
  1. click the icon ABP
  1. choose Custom filters or Adblock Plus options
  1. go to Add your own filters
  1. enter a filter i.e. @@
  1. Click Done and reload the page.
  1. Note the result in Maxthon ( ABP icon is still enabled and blocking some items)
  1. Open a Chrome browser and enter the same filter .
  1. Note the result in Chrome ( ABP icon is disabled and not blocking items.)

Observed behaviour

The result in Maxthon is different from that in Chrome.

Expected behaviour

The result in Maxthon shall be the same as in Chrome.


We still have legacy code implying $document filter option for exception rules that have a protocol. That backwards compatibility code predates filter options.

What to change

Drop this backwards compatibility code, the format for document-wide exception rules has been @@||^$document for at least five years now.

Attachments (1)

5162_1429345509_filter-exception-rule.doc (1.4 MB) - added by passbrains on 05/11/2015 at 04:12:29 PM.

Download all attachments as: .zip

Change History (13)

Changed on 05/11/2015 at 04:12:29 PM by passbrains

comment:1 Changed on 05/11/2015 at 04:24:11 PM by vickyyu

  • Description modified (diff)
  • Priority changed from Unknown to P2

comment:2 Changed on 05/11/2015 at 06:08:32 PM by mapx

  • Description modified (diff)

comment:3 Changed on 05/18/2015 at 01:15:25 PM by arthur

  • Description modified (diff)

comment:4 Changed on 05/18/2015 at 01:17:25 PM by arthur

  • Cc trev added

I'm not sure if that is a bug in Maxthon, I rather think it's not correct behaviour in Chrome.

Wladimir, what do you think?

comment:5 Changed on 05/18/2015 at 03:42:46 PM by trev

  • Cc sebastian added
  • Component changed from Unknown to Platform

Yes, this seems to be an Adblock Plus/Chrome bug - @@ doesn't apply to documents, consequently it shouldn't whitelist I cannot see the problem immediately, isPageWhitelisted() does check for DOCUMENT flag correctly.

comment:6 Changed on 05/18/2015 at 03:44:04 PM by trev

  • Platform changed from Maxthon to Chrome

comment:7 Changed on 05/18/2015 at 04:28:44 PM by sebastian

  • Component changed from Platform to Core

Seems like following code in RegExpFilter.fromText() is causing this behavior:

  if (!blocking && (contentType == null || (contentType & RegExpFilter.typeMap.DOCUMENT)) &&
      (!options || options.indexOf("DOCUMENT") < 0) && !/^\|?[\w\-]+:/.test(text))
    // Exception filters shouldn't apply to pages by default unless they start with a protocol name
    if (contentType == null)
      contentType = RegExpFilter.prototype.contentType;
    contentType &= ~RegExpFilter.typeMap.DOCUMENT;

So this seems to be the intended behavior. But I wonder why it doesn't work in Firefox.

comment:8 Changed on 05/18/2015 at 05:28:47 PM by trev

  • Description modified (diff)
  • Ready set
  • Summary changed from Some filter ( exception rule ) is not working the same as in Chrome to Inconsistent behavior: $document flag implied for exception rules with protocol included

You are right, Filter.fromText("@@").matches("", "DOCUMENT", "", "false", null) returns true both in Firefox and Chrome. This is legacy code predating filter options, we should remove it.

It actually works the same in Firefox - my bad, looks like I tested on

comment:9 Changed on 05/18/2015 at 05:30:14 PM by trev

  • Owner set to trev

comment:10 Changed on 05/18/2015 at 05:52:26 PM by trev

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

comment:11 Changed on 05/19/2015 at 04:22:02 PM by trev

  • Milestone set to Adblock-Plus-for-Firefox-next
  • Resolution set to fixed
  • Status changed from reviewing to closed


This only changes the behavior for Firefox, the change will be added to Chrome later with a dependency update.

comment:12 Changed on 06/04/2015 at 09:12:36 PM by sebastian

For reference, this change seems to break notifications in the current devbuild, see #2641.

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.