[Done] More flexible anchors

[Dr. Evil]

So would this work?

Code: Select all

*||ad_type=pop||

! replaces:
*?ad_type=pop&*
*&ad_type=pop&*
*&ad_type=pop|

I think this would be useful anywhere, not only at the end of a filter... (Though the double pipe might not be the best choice for this if there are still enough letters available which have to be encoded in an uri.)

[Wladimir Palant]

So would this work?

Code: Select all

*||ad_type=pop||

! replaces:
*?ad_type=pop&*
*&ad_type=pop&*
*&ad_type=pop|

No, with the current definition || would be accepted at the end of the expression only. However, I do agree that this one probably cannot be called an anchor at all, it is a placeholder for a separator character (like * is a placeholder for any characters). Looking at the US keyboard layout, there aren't that many options. So maybe "^adtype=pop^", "||example.com^" and "||example.com/foo^"?

[Fox]

So maybe "^adtype=pop^", "||example.com^" and "||example.com/foo^"?

That sounds great.

[Ares2]

* Filter composer should be able to use flexible anchors (should that be the default for all suggestions?)

I don't think it should be default, many sites use a different subdomain for their ads and currently the third option (http://ads.example.com/*) is what you want to block then and not the whole site (||example.com/*).

"||example.com^"

That would be very nice for adservers.

[Wladimir Palant]

Ares2, the default suggestion would be "||ads.example.com/foo/" for "http://ads.example.com/foo/bar". I already thought about this and it should definitely keep the entire site name. Maybe one exception: for "http://www.example.com/foo/bar" it should drop "www." and suggest "||example.com/foo/".

[Adblock Plus Fan]

I don't think it should be default, many sites use a different subdomain for their ads and currently the third option (http://ads.example.com/*) is what you want to block then and not the whole site (||example.com/*).

In that situation I only see gain in ||ads.example.com/* becoming default.
Hopefully you agree?

* Filter composer should be able to use flexible anchors (should that be the default for all suggestions?)

There's one disadvantage I can think of if this is implemented by default, some filters might become too short to be optimized if you remove http:// with this flexible anchor.
Solution would perhaps be:
1) suggest flexible anchor by default
2) revert back from flexible anchor if 1) isn't optimized
3) suggest flexible anchor again if 2) isn't optimized
The filter composer would need to do a few extra calculations, but I think it would be worth it.

[Wladimir Palant]

@Fan: I wouldn't worry too much about that - the case where the user gets a very short domain name *and* wants to block everything from that domain should be very rare. In all the other cases the filter still will be long enough. So I don't think this special case is worth considering.

[Ares2]

Ares2, the default suggestion would be "||ads.example.com/foo/" for "http://ads.example.com/foo/bar".

OK, I thought "use flexible anchors" means actually using it. This way it doesn't make any difference to the current suggestions anyway (except if you drop "www" of course), so go for it.

[Adblock Plus Fan]

the case where the user gets a very short domain name *and* wants to block everything from that domain should be very rare.

I guess you're right, this will only happen extremely rarely.

I imagine it's mostly realistic for situations where the filterlist is already using up a lot of shortcuts for a domain without actually having the whole domain blocked. For example the way easylist handles doubleclick:

Code: Select all

.doubleclick.net/*;cue=pre;
.doubleclick.net/adi/
.doubleclick.net/adj/
.doubleclick.net/adx/
.doubleclick.net/pfadx/*;ord=
.doubleclick.net/pfadx/*.mtvi/
.doubleclick.net/pfadx/*.mtvi/
.g.doubleclick.
/ad.doubleclick.net/ad/*

There could be a theoretical shortut shortage for the user in the long run as doubleclick expands, but it's fine if the chance remains extremely low.

[Fox]

Ares2, the default suggestion would be "||ads.example.com/foo/" for "http://ads.example.com/foo/bar".

OK, I thought "use flexible anchors" means actually using it. This way it doesn't make any difference to the current suggestions anyway (except if you drop "www" of course), so go for it.

"||ads.example.com/foo/"

Blocks:
http://ads.example.com/foo/
https://ads.example.com/foo/
mms://ads.example.com/foo/

[Ares2]

"||ads.example.com/foo/"

Blocks:
http://ads.example.com/foo/
https://ads.example.com/foo/
mms://ads.example.com/foo/

Yeah, I know I should have said "almost", but these are very rare cases.


BTW, will ||example.com/ also block ht*p://foo.bar.example.com/1.gif (more than 1 subdomain)?

[Adblock Plus Fan]

BTW, will ||example.com/ also block ht*p://foo.bar.example.com/1.gif (more than 1 subdomain)?

Yep, it's covered by (?:[^\/]+\.)?

[Wladimir Palant]

I changed the meaning of the first "Accept pattern only:" checkbox - it would switch on both regular anchors and flexible anchors (its label changes from "at the beginning of the address" to "at the beginning of the domain name" then). But I didn't manage to come up with a proper interaction between this checkbox and suggestions that are meant to be used with flexible anchors - if the user unchecks "at the beginning of the domain name" a filter like "example.com/foo/" becomes a pretty bad one. So I ended up simply adding a fourth suggestion that would block the entire domain, e.g. "example.com^". The other three suggestions remain unchanged.

[Wladimir Palant]

Implemented separator placeholders: http://hg.mozdev.org/adblockplus/rev/16a506483471
Changed the filter added when you click "Disable on example.com" to "@@||example.com^$document": http://hg.mozdev.org/adblockplus/rev/82ecb07f16f0
Added "example.com^" as a suggestion in filter composer: http://hg.mozdev.org/adblockplus/rev/0a0dbe7677de and http://hg.mozdev.org/adblockplus/rev/d4b92461e3ac
Made sure minimal Adblock Plus version is set correctly when exporting filters: http://hg.mozdev.org/adblockplus/rev/1ce2815bbf89

Now it should really be done, development build coming in a few minutes.