Rule Syntax Deprecated

Question

Rule Syntax Deprecated

Grossdm opened this issue 6 years ago · 16 comments

Grossdm commented 6 years ago

Hello,
I noticed that you have a rule that uses ##script:contains(...) syntax.

This is deprecated.

The new syntax is ##^script:has-text(...).

BTW, I found you here after reading your uBlock issue.

Answer 1 · 2018-12-16T22:21:06.000Z

BTW, I did not know or intend for this issue to be listed on the uBlock issue page.

I apologize if that was impolite.

Answer 2 · 2019-01-21T16:58:38.000Z

Hi,

thanks very much for the feedback! sorry I didn't see this earlier.

As this list is primarily for personal consumption across all my devices, I'm less concerned with best-practice than usual. Note the lack of info header in the rules files, for instance.

However, after deprecation comes removal, so I appreciate your early warning that this feature will be removed soon.

Answer 3 · 2019-01-21T17:04:33.000Z

I've just been reading through the documentation to find an alternative way to implement my scrip:contains rules, and came across this:

Please note that with the introduction of HTML filtering, the script:contains(...) syntax is now deprecated and internally converted into an equivalent ##^script:has-text(...) HTML filter.

Although my syntax is deprecated, this means it should still work for me as a Firefox user in the future.

I'll change the relevant rules to reflect the equivalent syntax, but (lacking chrom(e|ium) support as mentioned in the doc page, there's not much else I can do.

Answer 4 · 2019-04-21T23:39:34.000Z

Demo to test where works as generic:

##script:contains(blockadblock) or ##^script:has-text(blockadblock)

?

Answer 5 · 2019-04-22T08:46:01.000Z

Since there are now two javascript libraries with that name, you can try their websites to test if this filter still works:

https://blockadblock.com/ (this is the product I was originally intending to block)
http://sitexw.fr/blockadblock/ (an open-source equivalent)

By the looks of things, this filter no longer does the intended job, because blockadblock.com are embedding the script directly into the page.

I haven't encountered any uses of this script in the wild for a while. Do you have a real site (and not its product page) that is broken by it?

Answer 6 · 2019-04-22T08:53:41.000Z

Relevant uBO wiki page

Answer 7 · 2019-04-22T10:09:13.000Z

A possible alternative to this rule is injecting the builtin scriplet for defusing BlockAdblock,

although I'm not sure how to replicate having the rule apply everywhere by default, like with ##^script:has-text.

Answer 8 · 2019-04-22T16:11:51.000Z

that is broken by it?

from my knowledge this is no works without domain / tld.

Answer 9 · 2019-04-23T15:24:36.000Z

Demo to test where works as generic:

##script:contains(blockadblock) or ##^script:has-text(blockadblock)

?

I'm sorry, on reflection I don't think I understand your original query. Could you rephrase that?

Answer 10 · 2019-04-23T15:40:05.000Z

If no add domain / TLD ("suffix") before this filter, so is ignored/discarded (but Nano Adblocker no mark as invalid with comment "why" - https://github.com/NanoAdblocker/NanoCore#notable-change).

Answer 11 · 2019-04-23T16:21:38.000Z

Are you telling me that:

Because I've not prefixed this filter rule with a TLD, it's marked as invalid by NanoAdblocker's Filter Linter?

If that's not right, try Google translating from another language. I'm sorry I'm having trouble understanding you! 🤷‍♂️

Answer 12 · 2019-04-23T16:27:51.000Z

Because I've not prefixed this filter rule with a TLD, it's marked as invalid by NanoAdblocker's Filter Linter?

Yes. Filter doesn't works, I tried with similar site, e.g.: https://dniwolne.eu

dniwolne.eu##script:contains(google_jobrunner)

dniwolne.eu##^script:has-text(google_jobrunner)

Works, but without domain - still see alert:

Prosimy o wyłączenie programów blokujących reklamy ...

means:

Please disable ad blocking programs ...

So this filter is no used in latest uBO / Nano Adblocker maybe works in 2014-2018 with bugs in old uBO code.

Answer 13 · 2019-04-23T17:15:54.000Z

OK, now I understand. I'll remove this filter rule now, because it no longer performs its intended purpose.

I didn't prefix it with a TLD in the first place, because I wanted it to work automatically, without me having to manually un-break each site.

Because this is no longer an option (this filter no longer works), I'll just resort to injecting the scriptlet I mentioned above whenever necessary.

Answer 14 · 2019-05-20T20:52:25.000Z

Has anyone tried to prefix the rule with *?

I use a filter with the "domain" as this wildcard:

! This hides the add to home screen button
! reddit.com/r/firefox/comments/90z662
*$csp=manifest-src 'none'

That vile button takes up precious real estate on a mobile browser.
I was overjoyed to find this filter suggested on Reddit. Unfortunately I was not able to find a way to donate to the author.

Answer 15 · 2019-05-20T21:01:23.000Z

*$csp= ... = so "normal" this is network filter, so can works on all websites.

Other story is create good csp filter:

e.g. bad in EasyList https://github.com/uBlockOrigin/uAssets/blob/df982907c5bcfc0eff8bed58096d423bb146954b/filters/unbreak.txt#L2372

Answer 16 · 2019-05-20T21:21:58.000Z

@krystian3w,
Could you please explain your suggestion further?
I did look at the commit that you referenced, but I didn't learn anything.
I did notice that every csp filter was for script-src, while the filter that I posted was for manifest-src.
Did you have any thoughts on how to improve my filter? I welcome any suggestions you may have.

Thanks, Doug