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

[passbrains]

Adapted from ​https://www.passbrains.com/dashboard/view-ticket.php?ticket_no=MAX-90

Environment

Windows + 8.1 64bit + maxthon + English

How to reproduce

1. open the browser and go to a website such as ​http://www.amazon.com/

2. click the icon ABP

3. choose Custom filters or Adblock Plus options

4. go to Add your own filters

5. enter a filter i.e. @@http://www.amazon.com/

6. Click Done and reload the page.

7. Note the result in Maxthon ( ABP icon is still enabled and blocking some items)

8. Open a Chrome browser and enter the same filter .

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

Background

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 @@||example.com^$document for at least five years now.

[arthur]

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?

[trev]

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

[sebastian]

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.

[trev]

You are right, Filter.fromText("@@http://www.amazon.com/").matches("http://www.amazon.com/", "DOCUMENT", "amazon.com", "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 amazon.de.

[trev]

Fixed:

​https://hg.adblockplus.org/adblockplus/rev/cc3f3887226a
​https://hg.adblockplus.org/adblockplustests/rev/40ab9cba8260

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

[sebastian]

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