Add :upward support

[AdamWr]

In uBlock Origin :upward() will be a synonim for :nth-ancestor, so I think it would be a good idea to supports it too.

More details - https://github.com/gorhill/uBlock/commit/72bb70056843024b1a31fe1ab9c90bd4e8260ba2

[slavaleleka]

Although "upward" is based directly on Xpath, I've found that number-based "upward" entries can be converted into pre-existing AdGuard/ABP syntax with ease. E.g. example.org##.element:upward(2) → example.org#?#:-abp-has(> > .element)

[AdamWr]

Positive number >= 1 and < 256, distance from the currently selected node.

If I understand correctly, rule like this: example.org#?#a:upward(0) or this: example.org#?#a:upward(256) should be treated as invalid, but it seems that currently the first one (example.org#?#a:upward(0)) works the same as: example.org#?#a:upward(1)

Link - http://example.org/

[AdamWr]

Limited to work properly only at the end of selector, except of pseudo-class :remove().

What is the reason of this limitation? I mean that in third party filters there are few rules like this #?#selector:upward(1) + anotherSelector, so these rules will not work.

For example in Swedish filter:

tidningen.nu##span:has-text(/^Annons$/):upward(1) + .textwidget
viafree.se##.vjs-playing:upward(1) ~ .no-autoplay-overlay

https://github.com/AdguardTeam/FiltersRegistry/blob/6cce7c92672856220f256e85a26a2494196e35c3/filters/ThirdParty/filter_243_FrellwitSwedish/diff.txt#L200

[ameshkov]

@slavaleleka the question makes perfect sense, what's the reason for this limitation?

[ameshkov]

Actually, this won't be easy to handle at least until we ditch Sizzle. Let's live with this limitation for now.