Nano Linter issues mega thread

[jspenguin2017]

Filter Linter

Show warning if:

• [ ] Too many or too few arguments are passed in for a script snippet
• [ ] Filter is platform specific and current platform does not support it
• [ ] A script snippet injection rule only have negated domain (it will be converted to an exception rule)
• [ ] A filter will match word boundary but the boundary character is not explicitly given
• [ ] A common mistake is detected

Common mistakes:

• ||example.com^$generichide - Forgot @@ or important It is quite rare that someone want to use important on generichide, chances are he forgot @@. Detection logic: If a filter has generhichide but not important and is not an exception filter, then dispatch a warning.
• /example-path/ - Forgot trailing *
• /example-path/im - https://github.com/gorhill/uBlock/issues/3372 When matching part of a path, trailing wildcard is required, otherwise it becomes a RegExp rule. Detection logic: If a RegExp rule only contains letters, numbers, -, _, and ., then dispatch a warning.
• |example.com^ - Missed one | Can happen when copying filter, didn't select the whole line. Detection logic: For start anchor, if what is anchored does not include protocol, dispatch a warning.
• ||example.com - Forgot ^ Although the filter works, it is usually a mistake as it can match example.communicate.example.org. Detection logic: If a filter has host name anchor but no ^ nor : nor /, dispatch a warning.
• example.blogspot.*##element - Wildcard matching half of public suffix Filter will not work as expected. Detection logic: Could be difficult to implement.

Whitelist Linter

Show warning if:

• [ ] RegExp is used but that is unlikely to be the intent of the user

[jspenguin2017]

@ameshkov I'm not sure if this works in Adguard, but it's rejected by uBO (and Nano) and looks kind of weird. The scope operator doesn't point to anything, and immediately followed by :match-css. Is that intended?

Also, shouldn't this be #$#?

[ameshkov]

@jspenguin2017

The scope operator doesn't point to anything, and immediately followed by :match-css. Is that intended?

Yes, this is a valid pseudo-class usage. @gorhill, looks like a bug to me.

Also, shouldn't this be #$#?

Absolutely, thx for pointing this out!

[gorhill]

Yes, this is a valid pseudo-class usage. @gorhill, looks like a bug to me.

You need to use a *: *:matches-css(...). Pseudo operators are meant to mimick what could be a valid CSS selector, and without a prefix this wouldn't work even for valid CSS selectors. Example: .headeliner > :not(...) is not a valid selector, or assuming :has is implemented by browser vendors, .headeliner > :has(...) wouldn't be valid selector. .headeliner > *:not(...) and .headeliner > *:has(...) are however valid.

[ameshkov]

Example: .headeliner > :not(...) is not a valid selector

It is a valid selector:

[gorhill]

Ok, well, today-I-learned. I could have just tried it at the console... I will need to fix in uBO.

[jspenguin2017]

@ameshkov So the * is implicit? Then it would be a duplicate of the rule below?

[ameshkov]

@ameshkov So the * is implicit?

Yes, it is.

Then it would be a duplicate of the rule below?

As I understand, it's not.

In the rule below it means that there is an intermediate element between .page-form and :matches-css.

[jspenguin2017]

If I understood right:

• elem > :op(...) and elem > *:op(...) means apply the operator op to immediate children of elem
• elem > * :op(...) means apply the operator op to any (grand)children of any immediate children of elem
• elem :op(...) means apply the operator op to any (grand)children of elem

[grenzor]

Some Linter issues:

1) ||example.com^$~document discards the filter and gives a cannot be negated error, but document can be negated and the filter should be valid

2) @||example.com^ no error is given but filter is missing a @ at the start

3) ||example.com^,domain=example2.com no error is given but it's an invalid filter

4) ||example.com^$third-party,$image accidental use of $ for image makes it invalid

5) x||example.com^ becomes invalid filter due to x, usually due to some typo or accidental copying

6) example.blogspot.*##element error should be given whenever trying to match partial public suffix. Might also be applicable to other static filter syntax

7) ||example.com^$third-party,~image,image looks like image block takes precedence over negated. Not sure if some error could be given for this kind of accidental double syntax

[jspenguin2017]

@grenzor The linter is always right when it comes to showing errors since it uses the exact same parsing engine. If it shows error, then the filter is rejected, if it does not show error, then the filter is accepted, although how will the filter behave is another question.

By design, the linter will never show error if the filter is accepted, but I do agree warnings should be shown for some of these cases. I'll work on that later.

I think these should generate warning:

• @||example.com^
• example.blogspot.*##element
• ||example.com^$third-party,~image,image

The error in ||example.com^,domain=example2.com and ||example.com^$third-party,$image are pretty obvious from syntax highlighting, so no extra linter warning is needed. Also, I think x||example.com^ is really unlikely to happen.

[grenzor]

The error in ||example.com^,domain=example2.com and ||example.com^$third-party,$image are pretty obvious from syntax highlighting

They may be easy to spot if you have a few filters, but for someone with 100s/1000s of their own filters it is not easy at all. It's easier for the user to scroll down and just look at the sidebar for an icon of error or warning than manually checking each line's color syntaxing.

[jspenguin2017]

@grenzor I think you should be writing one filter at a time, and not 1000 then test together. Beside, even if the filter doesn't contain obvious mistake, it doesn't mean it'll work.

[grenzor]

I agree, but my use case was someone with already written filters in uBO who then imported them into Nano.

[jspenguin2017]

@grenzor You should still have validated each filter when you wrote them to make sure they actually work.

[jspenguin2017]

Is this clear enough? Or I should still dispatch a linter warning?

[grenzor]

Showing a linter warning will be better imo.

[jspenguin2017]

@ameshkov FYI, syntax errors in the spyware filter:

gopro.com#$#body[class^="smartling-] { padding-top: 60px!important; }
xtreme.ws##.topBorder > table[width="100%"][height="205"]body > #top

First one missing other double-quote, second one is invalid selector.

[ameshkov]

@jspenguin2017 thank you, we'll fix them soon!

[jspenguin2017]

• @@||example.com^generichide - Forgot $ Pretty obvious from highlighting It is quite rare that ^ is used just to match /, 9 out of 10 times it's a mistake. Detection logic: If a filter has one ^ and no $, and ^ is not at the very end, then insert $ right after ^, if the filter is still (or still seems) valid, then dispatch a warning.
• !#incluuuude - Misspelled preprocessor (need to investigate how preprocessor is handled for My filters) Preprocessors will be highlighted as keywords Preprocessor are like comments, but has special meaning when spelled correctly. Detection logic: If a line starts with ! #, then dispatch a warning (extra space). Otherwise, if a line starts with !# but is not a valid preprocessor directive, dispatch a warning.

[jspenguin2017]

Need to investigate how the redirect feature works with RegExp rules. With recent change (https://github.com/uBlockOrigin/uBlock-issues/issues/977), the redirect portion of RegExp rules is no longer rejected.

Update: Moved to a new issue: https://github.com/NanoAdblocker/NanoCore/issues/352