Nano Linter issues mega thread about nanocore

[gorhill]

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

[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

[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.

[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:

[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.

[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.

[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 (uBlockOrigin/uBlock-issues#977), the redirect portion of RegExp rules is no longer rejected.

Update: Moved to a new issue: #352