Procedural cosmetic features inconsistant

[Joebugg]

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 YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
• 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

Matches-prop fails to trigger when expected

Has/has-text/contains all work when text exists. I tested this with another site (works everywhere?). Matches-prop sometimes fails to trigger even if the source HTML has the properties (tested to eliminate loading issues). I noticed this issue while trying to make a filter for when specific values occur. The fact that it works sometimes is very frustrating.

I got a bit confused splitting this up/rewriting to fit within the different sections. Sorry if it's a bit redundant or non sequitur due to structure changes.

A specific URL where the issue occurs.

https://www.bing.com/images?FORM=Z9LH

Steps to Reproduce

I did check the documentation on PCF's and tested some of them.
I added uBO on a Firefox installation (on another computer) with other extensions disabled for process of elimination.
I tried other sites.

I tested these patterns on Bing.com:

1. ##.mimg:matches-prop(width) Filters out all thumbnails since they all have a style property.
2. ##.mimg:matches-prop('width') Filters out all thumbnails since they all have a style property.
3. ##.ming:matches-prop(data-bm) Ignored but should work like Need help with blocking #1.
4. ##.mimg:matches-prop(width=236) Works

Expected behavior

Scenario #3 should trigger it.

If the HTML source contains the property values, they should work with matches-prop.

Actual behavior

#3 seems to indicate that all values after an image tag's src URLs (or displayed text?) are ignored by the parser, entirely? I think it contradicts the documentation, or at the least I didn't see any such warning.

They don't work on all pages or sites. I need to test this more, with different tags. I feel fairly confident that it works for img up until the src URL. The Picker tool was very handy writing the specific paths, BTW!

uBO version

1.65.0

Browser name and version

Firefox 133 and 141

Operating System and version

Windows 10 and 11

[Joebugg]

I have no idea why it says "Need help with blocking". I did not write that.

[gorhill]

Seems like you are confusing "property" with "attribute". You do not need procedural operators to match attributes, it's natively part of CSS syntax:

• ##.mimg[width]
• ##.ming[data-bm]
• ##.mimg[width="236"]

[Joebugg]

So matches-attr and matches-prop are different I got, but I misunderstood which I was dealing with. My knowledge of what an attribute is heavily influenced by DOM Inspector and cursory glances at Mozilla.org. I thought it meant stuff like fonts, hidden/visible, or dragging/selection allowed.
Thank you! I wonder if I should write a quick guide with questions like this. It feels like it would be a common mistake.

[stephenhawk8054]

If you mean adblock syntaxes, there are documentations at ABP and Adguard: https://github.com/gorhill/uBlock/wiki/Static-filter-syntax