New uBO linter

[gorhill]

I am seeing issues being opened in other projects on the basis of what the linter reports. I didn't create the linter as a tool to use to burden other projects with all errors reported by the linter.

Some errors are legitimate and should be reported to list maintainers. But the majority of errors I see highlighted by the linter are just uBO stumbling onto a filter syntax which is valid in other content blockers, but not in uBO. It's fine, uBO discards those filters it doesn't understand, but filter list authors shouldn't be burdened with these linter errors, they did nothing wrong.

It's normal that filter list authors may want to support more than one content blockers, and it's not an issue for uBO to deal with incompatible filter syntax from other content blockers.

Reporting filters which are invalid but should be in uBO is ok, but reporting filters which are not meant to be dealt with by uBO is not right, that is not the purpose of the linter.

If I keep seeing this sort of burdensome issues being open in external projects I will make the linter enabled only for filter list authors.

Mainly this comment is to use as public reference for people who use the linter as a tool to open burdesome GitHub issues, which are issues out of control of external projects.

[krystian3w]

What will the authorization system look like if I am the author/contributor/collaborator of the filter?

As me these are bad:

• A simple search in header/comments:

  ! team: krystian3w
  ! author: krystian3w

  • samples: https://github.com/FiltersHeroes/KAD/blob/7301225b3779af9002e7ef7f3995643c0ac4ba80/templates/KAD.template#L9-L10 (creator ≈ author, maintainer ≈ contributor/collaborator)

    https://github.com/MajkiIT/polish-ads-filter/blob/1ac61881321b8b42912612adffc9d155bd5d8b42/polish-adblock-filters/adblock.txt#L4 (Collaborators)

• basing it on the URL of the file - some project use organisation in URL instead nicknames to free/pro accounts
• also certainly this variable, which allows you to temporarily in the logger to add exceptions what disappears with the closure of the logger.

So, for me, something like a GPG key-encoded variable remains, so that the abused key generation period is more than 12 months.

In addition, it is important to remember that, for example, LibreWolf one external list added to the base of stock and active for all. Then the linter there can stay active as there is no checking of remote controlled resources (assets.json) in your repository.

[gwarser]

Why you want/need to be authorized?

[Nojuuu]

I think you would probably just have to set filterAuthorMode true in advanced settings?

[krystian3w]

Only the system of the "license key" type (without the option to generate it with a script or GPT bot) will allow to limit those few before withdrawing the function completely from the uBo code.

I assume that they will not know how to undo the deletion of commits and maintain their uBo fork.

[iam-py-test]

I don't understand why you think this feature needs to be restricted with a license key or authorization? I understand how people can misunderstand this feature and assume these "errors" are problems which need to be fixed by the maintainer, but in my opinion, the solution is just what @Nojuuu suggested.

[Nojuuu]

In many software, enabling developer mode is often just a simple click of a button somewhere in the settings, so I don't see why it should be more difficult in uBO.

[u-RraaLL]

I see the tooltip in linter says Invalid filter. How about changing it to Invalid or uBO incompatible filter ?

---

On another note, could you make linter loop when cycling through the results so we can go from the last to first one like we can in search?

---

Occasionally, the counter will misbehave showing less errors than it should (I think it mostly happens when deleting lines). Which means when removing errors the counter can go down to zero (hiding search arrows) while invalid filters are still there. When you go to them manually and remove/fix them the counter will go negative. When the counter reaches 0 again (e.g. by pasting an invalid/incompatible filter) the arrows will be hidden again. They work correctly even if the counter is off so I think it'd be better if they didn't disappear.

I know this is a minor issue, as the counter will be corrected on refresh, but I'm reporting in case this is an easy fix.

The issue is caused or at least can be easily reproduced by the use of an exclamation mark.

Example 1:

1. Have a valid filter, e.g. ||reddit.com^$doc
2. Paste a comment line at the end of that filter by mistake, e.g.

||reddit.com^$doc! test
||facebook.com^doc

3. Add new line after ! by mistake (yes, again), hit backspace.
4. Hit left arrow key, add new line. The counter shows Errors: -1.

Example 2:

1. Have a comment line e.g. !test.
2. Add a single character at the beginning e.g. ,. Hit enter. See 1 error.
3. Hit backspace. See Errors: -1. Hit backspace again. The error count remains the same.

[gorhill]

The linter will get better over time, it's a first iteration and for now I want to minimize changes in release candidate cycle. I have fixed the incorrect count when using backspace with gorhill/uBlock@f539f86.

[u-RraaLL]

// Invalid comment line

Should such a line not display an error?

[gorhill]

Yes it should. Will look into this next dev cycle.

[u-RraaLL]

@gorhill regarding your comment about inefficient procedural filters...

Could you perhaps add warnings to linter about inefficient filters? E.g.:

• div:has-text(...) <- any procedural on plain div
• span:has-text(...) <- any procedural on plain span
• *:has(*:has-text(...)) <- any procedural nested inside :has() on any element

Something along the lines of:

Warning: This filter matches inefficient syntax. Try choosing better selectors or get advice from experienced filter makers on r/uBlockOrigin.

[gorhill]

There should be no assumption that a filter is bad performance-wise solely based on examples you give. It also depends on the website on which they are meant to apply. The best approach is to actually measure their execution time when applying them -- maybe something I will investigate again for the element picker (I did in the past and got widely variable results so I dropped this).

[u-RraaLL]

Oh? These are the three types of "mistakes" I've seen people make most often over the years at uBO's subreddit. It's usually for big sites like fb or twitter where they would be inefficient. Maybe the message I suggested is too strong, considering some smaller sites where the effect wouldn't be as bad. Maybe something more like a hint for procedural filters?
I also didn't want the warning to show up as an error, just as a visual cue of a different color in the gutter with a tooltip, in case that's how you understood this.

Of course, checking efficiency in the picker would be a great tool for people crafting filters themselves. But that would not address people directly adding filters they've found online - in which case, some form of a linter hint could be helpful.

---

Kind of related, though not entirely. With the FF-native :has() coming in a month, would it be a good idea to have some visual cue in picker to distinguish between when it's applied natively and not?

Or how do you see making the distinction between the two? Is invalid (natively) :has() going to be automatically made procedural instead? Or will it fail and the user will need to force #$# syntax to switch to procedural?

[u-RraaLL]

Minor issue. uBO only detects errors inside the :style() operator for the first declaration. If at least one declaration is valid, no errors are detected (e.g. a missing :) in others. Forbidden characters/properties are working as expected.