Opened on 01/30/2017 at 04:05:42 PM

Closed on 08/29/2019 at 05:43:52 PM

#4851 closed defect (rejected)

Redirect filter list comment not ignored if same address

Reported by: Assignee:
Priority: Unknown Milestone:
Module: Core Keywords: closed-in-favor-of-gitlab
Cc: greiner, sergz Blocked By:
Blocking: Platform: Chrome
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):


One of our users reports:

Syntax "! Redirect" of AdBlock Plus filter is not correctly implemented.

"This comment is ignored if the new address is the same as the current address, meaning that it can be used to enforce the "canonical" address of the filter list."

What actually happened in AdBlock is it seems to stuck in the loop for a while, quickly realized it, but returned an error instead of just ignore this line and continue reading the rest.

He originally reported this in AdBlock 3.6.0 for Chrome beta. He reported on January 22 that it's still happening, in both the beta and stable releases.

According to our dev (Brent Montrose):

I find it difficult to believe that the ABP Core code wouldn't handling redirects correctly, so it maybe the user's misinterpreting the documentation, etc. But you should probably open a ABP ticket / issue.

I'll get more information about the error he's seeing. In the meantime, does this sound like a bug or a misreading of the filter guide?

Attachments (0)

Change History (8)

comment:1 Changed on 01/30/2017 at 04:06:27 PM by

Note to self: This is for reference

comment:2 Changed on 01/30/2017 at 05:27:26 PM by greiner

  • Cc trev greiner added
  • Component changed from Unknown to Core
  • Summary changed from "!Redirect" to Redirect filter list comment not ignored if same address

After having a quick look at the code I couldn't find where the redirect is supposed to be ignored if it's the same address. I'll keep looking and I'll also investigate whether or not this is a regression.

In the meantime Wladimir might have some further background info on the intended behavior of that filter list comment so I added him to CC.

comment:3 Changed on 01/30/2017 at 05:48:59 PM by greiner

It looks like it's a regression that's caused by the refactoring of the synchronizer logic in 2013. It removed an if-statement which appears to have been responsible for enforcing what's mentioned in the documentation as well as another if-statement which does a similar check.

Note that based on our automated tests, a redirection loop is supposed to result in an error so we should probably update the online documentation to reflect that rather than reintroducing unnecessary behavior.

Last edited on 01/30/2017 at 06:37:59 PM by greiner

comment:4 Changed on 02/08/2017 at 02:37:02 AM by

By the way, dunno if it helps, but the error the user is getting is "Failed, download failure."

His custom filter file is here:

comment:5 Changed on 02/09/2017 at 06:48:30 PM by

comment:6 Changed on 12/21/2017 at 11:27:49 AM by fhd

  • Cc trev removed

comment:7 Changed on 01/04/2018 at 01:25:52 PM by sergz

  • Cc sergz added

comment:8 Changed on 08/29/2019 at 05:43:52 PM by sebastian

  • Keywords closed-in-favor-of-gitlab added
  • Resolution set to rejected
  • Status changed from new to closed

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the new issue tracker.

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 (none).
Note: See TracTickets for help on using tickets.