The logger removes whitespace in selector

[Yuki2718]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

The logger removes whitespece of ##.a, .b, .c, .d, .e, .f, .g and displays as ##.a,.b,.c,.d,.e,.f,.g, so if I copied the rule from the logger, no match in actual filters. IMO the logger should display filters as are.

A specific URL where the issue occurs.

linksfly.me/demo

Steps to Reproduce

Will be obvious if you visit the URL

Expected behavior

The logger preserves the form of actual filters exactly.

Actual behavior

Not

uBO version

1.50.1b16

Browser name and version

Chrome 114.0.5735.199

Operating System and version

Windows 10

[krystian3w]

Normal for 6-12 months.

If you must disable these cosmetic filter (e.g. @gmarcher, and @realodix sick/ill to fix at origin), then the best copy from viewer of problematic list (e.g. Indonesia/Malaysia list where can be compressed many filters by comma) to add fix compatible with ABP and AdGuard (e.g. copied fastly to EasyList "English").

[gorhill]

I can create a working exception to crewbase.net##.a, .b, .c, .d, .e, .f, .g with either #@#.a,.b,.c,.d,.e,.f,.g or #@#.a, .b, .c, .d, .e, .f, .g.

I copied the rule from the logger, no match in actual filters

You mean you manually search for the filter in the list?

The reason the cosmetic filter is changed is that it is normalized in order to make sure that duplicates of properly found and discarded by uBO. Removing normalization would be a step backward.

Related: #620

[krystian3w]

But now paste these exceptions to ABP and AdGuard parsers, can mark as no match without unlock visibility element.

[Yuki2718]

You mean you manually search for the filter in the list?

Yes, copied from the log and searched in text file.

The reason the cosmetic filter is changed is that it is normalized in order to make sure that duplicates of properly found and discarded by uBO. Removing normalization would be a step backward.

Okay, then. It's not too serious.

[garry-ut99]

The logger removes whitespece of ##.a, .b, .c, .d, .e, .f, .g and displays as ##.a,.b,.c,.d,.e,.f,.g, so if I copied the rule from the logger, no match in actual filters.

It removes also ? from #?# ABP selectors, and shows as ## : #2475 which no match in actual filters + is invalid when used without ?: #2349 (comment)

By the way: #332

[gorhill]

By the way: #332

Using CSSTree library made it possible to normalize cosmetic filters, this was not possible back then at the time of this issue.

[garry-ut99]

I've decided to not open a new issue for a very similiar issue I've found which might be very related to the current issue and might have the same/similiar root, steps to reproduce (my config: Firefox/Opera + uBO 1.55.1b0) :

• enable POL regional lists in uBO
• open uBO logger
• visit www.bolec.info (not bolec.info which mistakenly isn't covered in filters because of unnecessary www. in the filters)
• notice in the logger that 2 filters are displayed in a distorted manner
  ( https://github.com/MajkiIT/polish-ads-filter/blob/36d7b634e3266b119acc8e59363470ef0d947fe4/polish-adblock-filters/adblock.txt#L3946-L3947 )
  the both filters work fine (they hide ads as expected), but there are a couple of visual glitches/breakages in the logger :
  • in the logger
    • (1) the ending part of both filters is moved to another column, and as a result text from the other columns on the right is moved to another columns as well, which also makes some text unreadable
  • in a popup with details :
    • (2) there is not only white characters are missing in a filter, (which I understand is not an issue because they are compressed), but the issue is that all the other characters on the right are missing as well)
    • (3) another problem is that reverse-lookup fails and it says the filter couldn't be found in any of existing filters lists
    • (4) the next problem is that whitelisting temporarily a filter via #@# doesn't work
  • also notice that the white characters in the affected filters which seem to cause troubles don't seem to be neither a space nor a tab, I'm not sure what is it, I only know they were copy pasted directly from Firefox browser inspector to My Filters, then copy-pasted from My Filters to POL filter list via GitHub in Firefox

[gorhill]

There is a tab character in the filter, uBO should mark this as an error:

www.bolec.info##[style="color: #ccc; font-size: 0.60rem;	"]

[garry-ut99]

Also, to be clear, this tab character is already present in the source code of the page, it's the site owner to be asked/blamed why he put it in his site.
Then it was copy&pasted from browser DOM inspector to uBO Picker, then to My Filters pane, then to a filter list, and neither browser nor uBO, throwed any warnings/errors - they are to be asked/blamed why (as for uBO - a bug)

---

uBO should mark this as an error

By the way, I wonder why uBO can't accept/parse/handle it given that:

• filters with a tab works fine (hide ads)
• site owners use tab characters in their source code
• internet browsers accept/handle/parse tab characters without errors/warnings/breakages
• uBO accepts/handles/parses already filters with many spaces without errors/warnings/breakages

Maybe because it's hard to handle them in uBO Logger.

---

Also one more thing I've noticed regarding commenting filters in My Filters pane,
I'm not sure whether it's a bug or not how a filter with a tab is being commented,
in a comparision to a second filter which contains 4 spaces,
it seems a tab is somehow visually compressed, but why: